% 0:09:23

D3: In principle, there should be a toolbar up here <*hovers blank area in GUI, closes
    application*> I’ll show you how what it looked like in the old calendar.

D4: Yeah, also show me what it can do already and what it should be able to do.

% 0:09:37

D3: Yes, I'll better show you first where (!...!) where we're going here.
    <*opens IDE again*>
    Just need to check, how these menu items worked, right, (#Calendar#),
    ok, wasn't there, (#CalendarWeek#), <*opens configuration of an ExtensionPoint*>
    right (#CalendarTestView#), and then, the old one was, right (##CalendarView##), right. 
    <*changes the configuration of an ExtensionPoint*>

% 0:10:11 

D4: Is this still an Eclipse View, or what? (No.)

D3: <*shrugs, looks at D4 smiling*>

D4: <*snorts*>

D3: <laughing> I really don’t a have clue regarding ExtensionPoints and stuff.
    I don’t get along with it. I mean, I can’t give you great information here.

D4: <*clicks ball pen, stares at screen*>

% 0:10:26

% both wait for the application to start

% 0:10:59

D4: You know, I just read in this book, you could do it like this, when (!...!) could you
    open Eclipse again?

D3: <*navigates in to calender view in application, an error message is shown; closes the error message and switches to IDE*>

D4: That you get Contributions like these, and when you activate the calendar, they are inserted.
    But I don't know whether there is a toolbar planned at all?

D3: Can't tell you. I've only been here for three months.
    <*switches to application*>

D4: <laughs> But where should it go? Here, or what?

D3: I thought so, right, it should got here. <*hovers narrow bar above calendar*>
    And actually, I don't know why it does not
    <*clicks around, error message appears*> (!...!) What's this error anyway?

D4: (#ClassCastException#)

D3: (#Cannot be cast to CalendarTest#) I see. <*closes error message*> probably
    <*closes application, switches to IDE, into configuration of the ExtensionPoint*> 
    (#CalendarView#)

D4: How do these navigations thingies work? These are Actions, right?

D3: Mhm.

D4: Are those Actions? Where do they appear?

D3: Well, they are processed by this class <*selects class name of one Action*>
    and then it calls the according method. I mean, there is a (!...!) what's it called?
    <*opens Package Explorer*> nope, not here, but (!...!)
    <*navigates to a method*> right, but it's not the one (!...!) just a moment
    <*continues search*>

D4: Well, it has to implement an interface right?

% 0:12:52 

D3: Yes, it does. <*opens a file*> (#CalnderTestView#)
    <*places cursor into file in line with 'LicenseKey' and scrolls down immediately*>

D4: <chuckles> (#LicenseKey#)?

D3: Exactly, and these are called <*selects three methods*> and from here it goes on
    <*selects single line*> to the respective class. I mean, in this case into the 
    TestCalendar <*scrolls up again, 'LicenseKey' is visible again*> 
    (#viewpart#) there it is, the calendar.
    Alright, now we already closed it.

D4: Mh, LicenseValidator is from the component, isn’t it?

D3: Yes, correct.

D4: Ok.

% 0:13:21 

D3: The component was purchased at some point, and it uses some 'setLicenseKey'. You'll see
    that a lot around here. Almost every componen wants to get its license key.

D4: What? Do you have to copy it, or what?

D3: What do you mean, 'copy'? It's a String, basically (!!...!!)

D4: I mean, when you create a new class, you have to do this everytime (!...!)

D3: In principle, (!...!) yes, we can Google it quickly <laughs> <*starts fulltext search in 
    IDE*> here, for instance, the MonthDateArea wants it and (!...!) wait, that's it?
    Ok, I figured there were more components.

D4: And for every component you have to set the same license key?

D3: Erm, I thought as much. But that might be outdated already. Let me look again.
    <*scrolls*> OK, then it appears to have changed. Alright, that it's only the one component.
    Would have been weird if every component had that.
    Don't know, what is that anyway? A DateAreaBean? <*hovers variable, tooltip appears*> 
    (#DateAreaBean#), yes.
    (..) Ok, so, where were we? <*sees stacktrace at the bottom of the screen*>
    The exception, right.
    <*reads in stacktrace*>
    (#Cannot be cast to CalendarTestView#) I see,
    (#AbstractOpenCalendarView#), we have to change it here as well, into CalendarView
    <*changes statement, error message appears*>.

% 0:15:02

D3: <*open details of error message (,,,,)*> Hm?
    Checkstyle doesn’t work (,,,)
    <*closes error message*> OK, I’d say: Get lost, Checkstyle! <laughs>

D4: <laughs>

% 0:15:15

D3: <*tries to start application, error message appears*> Let's see, we've got a ParseError now.

D4: You have to <*points on screen*> that one you have to, too.

D3: Mhm.

D4: Here, it still says ‘Test’.

D3: Ah! <*changes code*> But it should not have been the issue (!...!) <*different error message 
    appears*> It was. Cool, alright.

D4: Run ‘Organize Imports’, then it's gone.

D3: Should do it automatically on saving. Yes.

D4: Did you configure it that way?

D3: On my computer, yes. Don't know how it's done here. But I guess, too.

D4: Because by default, it's not configured.

D3: <*error message appears whilet trying to save*> Hm?

D4: <annoyed> What's that now?

D3: What is he complaining about? He doesn't even build! Now it's another error. I see.

D4: <laughs> OK.

D3: Hell no, I won't turn that whole thing inside out. I'll show you elsewhere.

D4: But what is it (!...!)

D3: <*undos code changes*> We'll take a look at the toolbar for the Follow-Ups. It would take 
    ages to change all that now.

D4: Did you already change it on your machine, or what?

D3: Well, this is the old version I just restored, the old calendar. And now we use 
    (##CalendarTestView##), ok. I'll show to you in the Follow-Up section, I guess the toolbar
    is already in there.

D4: But that one is still an Eclipse view, right?

D3: Mhm.

D4: It's derived from this ExtensionPoint, or it fulfills this ExtensionPoint.

D3: Mhm. It's alright that way. Here it's CalendarTestView again.

D4: But your view is the whole Kalendar, or what?

D3: Yes.

D4: And why no editor? Ah, you dumped the editors altogether around here, right?

D3: We, I work completely separated from the actual product.
    <*opens source code*> This is from some Panel and that's all AWT already.
    The way I started (!...!) there are demos for this (~) calendar.
    I chose the demo that closest resembled our calendar, copy-pasted it, and then
    adapted it bit by bit.
    Problem was, in the beginning, I had no idea about Java and had to start somehow.

D4: Ah, you did not do any Java before?

D3: Nope, total newbie regarding Java. That's why all this code is totally worthless.
    If you see how many lines we've got already (!...!)

D4: God methods and God classes, am I right?

D3: That's (!...!) yeah, 1917 [lines], about time to refactor.
    <*switches to application*> So, Follow-Ups.
    Although we did see it in Position Billing as well.

% 0:18:17
    
D3: In general, a toolbar like this one. <*hovers toolbar in Follow-Up module*> So they 
    put it up there, it seems.

D4: Okay, and that's now a Toolbar or a Coolbar or similar, and that's your own widgets
    in there?

D3: Erm, I'd say: Yes. But I am not sure, because I've never done this before.
    We have to take a look at how it's implemented in the Follow-Up section.

D4: But, shouldn’t it be the goal to always have these thingies up here? <*points to
    buttons in the toolbar*>

D3: Yes, exactly.

D4: But then <*points to screen*> for the calendar, it’s (!!...!!)

D3: Yeah, that was nonsense what I told you before <*switches to calendar view*>

D4: Then it should be up there <*points to screen*>, right?

D3: We don’t put it here in this narrow bar <*hovers narrow space in calendar view*>,
    but up there, too <*hovers space above calendar view*>

% 0:18:57 

% 1:30:49

D4: Do you know about OSGi class loading?

D3: Class-what? Not really, no.

D4: Should I tell you?

D3: Sure.

D4: [...] Each bundle [...] has its own ClassLoader which can only load classes from other
    bundles if [...] the other bundle from where you want to get the class does export the
    package of the class and if your own bundle explicitly imports.
    You always have these manifest files [...] there you can do Import-Package [...] to
    say that you want that package.

D3: M-hm.

D4: [...] normally, you should always do Import-Package, <laughs> here it’s always
    Require-Bundle. You set the logical name of the bundle you want to import and
    depend explicitly on this bundle. You can not say, I remove this bundle and swap it
    with another with the same package for OSGi to use that one. [...] That’s why
    Import-Package is usually nicer. [...]

% 1:35:15