View source for Dev Meeting Log 20120309

Below is the log of our developer IRC chat on Friday night/Saturday 
morning. In attendance were: Connor (cpmeister), Drew, Eric (maredudd), James, Stefan (Zaister), and Tom (thpr).

== Summary ==
* UI Architecture Walkthrough
* Other Business

== Actions ==

* Label architecture diagram with the package names (Tom)
* Schedule new meeting for the other 2 major topics (Tom/James)
* 

== Transcript ==

<small>(10:05 AM) [Arch_SB]thpr:</small> So welcome all to the Code/Arch team meeting.<br />
<small>(10:05 AM) [Arch_SB]thpr:</small> We had three topics from the list<br />
<small>(10:06 AM) [Arch_SB]thpr:</small> - New UI update / structure for the team (James/Connor)<br />
<small>(10:06 AM) [Arch_SB]thpr:</small> - Facet status / restructure / key principles of the design (see notes from the _dev list to provide a start of the background here - Tom)<br />
<small>(10:06 AM) [Arch_SB]thpr:</small> - Future of PCG creation/parsing (Tom)<br />
<small>(10:06 AM) [Arch_SB]thpr:</small> Then we can do open topics if there is anything additional<br />
<small>(10:06 AM) [Arch_SB]thpr:</small> Questions before we have James/Connor go?<br />
<small>(10:06 AM) James[Code_SB]:</small> Sounds good to me<br />
<small>(10:07 AM) [Arch_SB]thpr:</small> ok, off to you James<br />
<small>(10:07 AM) James[Code_SB]:</small> Connor would you prefer to present on the arch changes? I'm happy either way<br />
<small>(10:07 AM) devonjones_ [~devon@ip65-46-72-146.z72-46-65.customer.algx.net] entered the room.</small><br />
<small>(10:08 AM) James[Code_SB]:</small> Hi Devon<br />
<small>(10:08 AM) cpmeister:</small> hey, the last one<br />
<small>(10:08 AM) devonjones_:</small> hiya<br />
<small>(10:08 AM) [Arch_SB]thpr:</small> Hey Devon, we're just getting started<br />
<small>(10:08 AM) devonjones_:</small> cool<br />
<small>(10:09 AM) [Arch_SB]thpr:</small> Your floor Connor<br />

=== UI Architecture Walkthrough ===

<small>(10:09 AM) cpmeister:</small> where would you like me to start? The UI facade layer? the new startup system? new property persistence?<br />
<small>(10:09 AM) James[Code_SB]:</small> Maybe start with the UI facade structure <br />
<small>(10:09 AM) [Arch_SB]thpr:</small> let's start with the UI, since that was the project<br />
<small>(10:09 AM) cpmeister:</small> k<br />

==== UI Facade Structure ====

<small>(10:10 AM) cpmeister:</small> the new UI is built upon the new facade layer to enforce separation between the UI and the core<br />
<small>(10:10 AM) cpmeister:</small> I'm sure everyone knows that<br />
<small>(10:11 AM) cpmeister:</small> but extreme care has gone into making sure that the core is reference ONLY through these facades<br />
<small>(10:12 AM) cpmeister:</small> at this point, it is very easy to swap out the current UI for any other<br />
<small>(10:13 AM) cpmeister:</small> a main boon to the facade layer is it's event dispatch system which automatically triggers listeners for changes within the facades<br />
<small>(10:13 AM) devonjones_:</small> so the facades facilitate both retrieving information as well as applying changes?<br />
<small>(10:13 AM) James[Code_SB]:</small> Yes<br />
<small>(10:14 AM) [Arch_SB]thpr:</small> So help on what automatic means here...<br />
<small>(10:14 AM) [Arch_SB]thpr:</small> Is there a system polling the core which then triggers events so the UI is actually interrupt driven?<br />
<small>(10:14 AM) James[Code_SB]:</small> The facade layer generally presents a dynamic list of current items which the UI will subscribe to and thus be notified when any changes happen<br />
<small>(10:14 AM) devonjones_:</small> are the facades capable of outputting any piece of data that can also be accessed via export tokens?<br />
<small>(10:15 AM) devonjones_:</small> or is it a subset?<br />
<small>(10:15 AM) James[Code_SB]:</small> So you might have a list of applied templates which the facade maintains and when this is changed an event is fired and if the UI is listening it can react to the change<br />
<small>(10:15 AM) James[Code_SB]:</small> The facade covers a subset<br />
<small>(10:16 AM) [Arch_SB]thpr:</small> So anything (anything displayed anyway) that can be changed in the core eventually fires an event, even if the only way to know about the change would be to poll the core?<br />
<small>(10:16 AM) James[Code_SB]:</small> Yes<br />
<small>(10:17 AM) James[Code_SB]:</small> Connor, maybe this is a good time to cover references?<br />
<small>(10:17 AM) [Arch_SB]thpr:</small> So a global poll is done after every change<br />
<small>(10:17 AM) [Arch_SB]thpr:</small> ?<br />
<small>(10:17 AM) cpmeister:</small> sure James<br />
<small>(10:17 AM) cpmeister:</small> right now there are a few classes which form the base of the event/listener system<br />
<small>(10:18 AM) cpmeister:</small> one of them is the ReferenceFacade, which simply holds a reference to an object and the UI can attach listeners to it when the reference changes<br />
<small>(10:18 AM) [Arch_SB]thpr:</small> That would be for something like Race? (which the PC can have only one)?<br />
<small>(10:18 AM) cpmeister:</small> indeed<br />
<small>(10:19 AM) cpmeister:</small> its up to the facade layer implementation to make sure that these references stay up to date when changes in the core occur<br />
<small>(10:20 AM) James[Code_SB]:</small> One important feature is that the reference detects if the set is change and only fires events when a change happens<br />
<small>(10:20 AM) [Arch_SB]thpr:</small> Does the facade assume it's the only master?<br />
<small>(10:20 AM) James[Code_SB]:</small> Yes<br />
<small>(10:21 AM) [Arch_SB]thpr:</small> So if you change something secretly, all bets are off<br />
<small>(10:21 AM) James[Code_SB]:</small> Yep<br />
<small>(10:21 AM) [Arch_SB]thpr:</small> In effect, you can capture the state with the set calls on the way into the core and fire the event after the core finishes, without having to poll the core<br />
<small>(10:21 AM) James[Code_SB]:</small> Yes<br />
<small>(10:21 AM) [Arch_SB]thpr:</small> for something like Race anyway<br />
<small>(10:21 AM) [Arch_SB]thpr:</small> ok<br />
<small>(10:21 AM) devonjones_:</small> say i want to listen from something that is a statistic that is derived.  Say the attack bonus with a weapon, or a variable.  Can I set a listener against a derived value like that?<br />
<small>(10:22 AM) James[Code_SB]:</small> but sideffects need amangement, so a lot gets scanned after a change of race or class<br />
<small>(10:22 AM) [Arch_SB]thpr:</small> which is kind of the global poll I was referring to after a change<br />
<small>(10:22 AM) James[Code_SB]:</small> That's right<br />
<small>(10:22 AM) [Arch_SB]thpr:</small> ok<br />
<small>(10:23 AM) James[Code_SB]:</small> I'd really like to move the facade itself towards listening to the facets, but we can cover that later<br />
<small>(10:23 AM) [Arch_SB]thpr:</small> Yea, we<br />
<small>(10:23 AM) [Arch_SB]thpr:</small> will come to that discussion<br />
<small>(10:23 AM) James[Code_SB]:</small> @Devon, currently no, but the structure would help you if you wanted to do that<br />
<small>(10:23 AM) [Arch_SB]thpr: @Devon:</small> For BONUSes, the core will actually let you do that<br />
<small>(10:23 AM) devonjones_:</small> cool<br />
<small>(10:24 AM) [Arch_SB]thpr:</small> (check out BonusChangeFacet)<br />
<small>(10:25 AM) [Arch_SB]thpr:</small> anyway, sorry, I was off topic talking about the core, back to Connor<br />
<small>(10:25 AM) cpmeister:</small> are we done discussing the ReferenceFacade?<br />
<small>(10:25 AM) [Arch_SB]thpr:</small> I am for now<br />
<small>(10:25 AM) devonjones_:</small> I don't have any other questions, not sure for others<br />
<small>(10:26 AM) James[Code_SB]:</small> all good<br />
<small>(10:26 AM) cpmeister:</small> k, on to the ListFacades<br />
<small>(10:27 AM) cpmeister:</small> these are basically a list upon which changes can be listened to<br />
<small>(10:27 AM) cpmeister:</small> right now it covers simple adding and deleting of single elements<br />
<small>(10:27 AM) [Arch_SB]thpr:</small> The phrasing of which leads me to ask... do we ever believe we need something more?<br />
<small>(10:28 AM) cpmeister:</small> if more than one element changes in a single call then a third type of event is dispatched telling listeners that the list should be rechecked from scratch<br />
<small>(10:28 AM) cpmeister:</small> @tom for the most part no<br />
<small>(10:29 AM) James[Code_SB]:</small> I think we do have another case we need to expand them to cover which is where data attached to an item in the list changes<br />
<small>(10:29 AM) cpmeister:</small> but there can be time when single changes would not be the most efficient, such as languages changes when a race is selected<br />
<small>(10:29 AM) cpmeister:</small> yes, that situation needs to be addressed<br />
<small>(10:30 AM) [Arch_SB]thpr:</small> So we probably need a similar situation on the base ReferenceFacade too James?<br />
<small>(10:30 AM) cpmeister:</small> for now this usually has been handled on a per list basis, but the behavior is common enough that a general solution needs to be found<br />
<small>(10:32 AM) cpmeister:</small> for example, a ListFacade containing ReferenceFacades<br />
<small>(10:32 AM) cpmeister:</small> trying to listen to the internal reference facades becomes difficult especially when references can be added or removed from the list<br />
<small>(10:32 AM) devonjones_:</small> perhaps if a Facade is added, ListFacade can detect that it subclasses Facade and automatically subscribe?<br />
<small>(10:33 AM) devonjones_:</small> and unsubscribe upon removal<br />
<small>(10:33 AM) [Arch_SB]thpr:</small> I'm trying to figure out what is meant by "somethign is attached to an item"... does that mean like RACE was granted another LANGAUTO because someone pulled up the LST editor?<br />
<small>(10:33 AM) James[Code_SB]:</small> No, think about abilities<br />
<small>(10:33 AM) James[Code_SB]:</small> and mult support<br />
<small>(10:34 AM) [Arch_SB]thpr:</small> OH, associations<br />
<small>(10:34 AM) James[Code_SB]:</small> So if a choice changes I;d like to get a changed event'<br />
<small>(10:34 AM) James[Code_SB]:</small> yep<br />
<small>(10:34 AM) [Arch_SB]thpr:</small> got it<br />
<small>(10:34 AM) [Arch_SB]thpr:</small> So in that case, I'm not sure I'd  go down the path of having something delve into the contents of the list<br />
<small>(10:35 AM) [Arch_SB]thpr:</small> The core has the same problem of being able to detect those types of changes<br />
<small>(10:35 AM) [Arch_SB]thpr:</small> And I didn't want to have to write a whole slew of code to special case Ability... in fact I somewhat refused to do that because it makes everything really weird by having to cast, pull out category, and all that junk<br />
<small>(10:35 AM) [Arch_SB]thpr:</small> The core has two methods of thinking about Abilities.<br />
<small>(10:36 AM) [Arch_SB]thpr:</small> One is the base abilities (Martial Weapon Proficiency, Dodge, etc.)<br />
<small>(10:36 AM) [Arch_SB]thpr:</small> Another is each Ability with a single association.<br />
<small>(10:36 AM) [Arch_SB]thpr: That way if you only want to know the abilities (because you're responding to add TEMPLATE:</small> things it would have granted you pay attention to the former<br />
<small>(10:36 AM) [Arch_SB]thpr:</small> If you are based on a BONUS with a %LIST inside it, then you pay attention to the latter<br />
<small>(10:37 AM) [Arch_SB]thpr: it prevents treating Ability as a special case due to MULT:</small>YES and we may want to adopt something similar for the UI<br />
<small>(10:37 AM) [Arch_SB]thpr:</small> So the core in the former case is passing around Ability objects, in the latter a CategorizedAbilitySelection<br />
<small>(10:38 AM) [Arch_SB]thpr:</small> That way, there is no casting or having to check for a Category only when you get Ability - it's all in 1 package<br />
<small>(10:38 AM) James[Code_SB]:</small> To be honest I thik that's too low a level of detail for the UI<br />
<small>(10:39 AM) James[Code_SB]:</small> Effectively what it is interested in is "fields on this row may have changed, refresh the data for it"<br />
<small>(10:39 AM) James[Code_SB]:</small> There is no real concern that it is an ability, or an association etc<br />
<small>(10:39 AM) [Arch_SB]thpr:</small> True, but the new UI forced some special casing on Ability back into the core, which I think needs a good think through<br />
<small>(10:40 AM) [Arch_SB]thpr:</small> of why that had to happen<br />
<small>(10:40 AM) James[Code_SB]:</small> Sure<br />
<small>(10:40 AM) James[Code_SB]:</small> Happy to delve into that with you some time<br />
<small>(10:41 AM) [Arch_SB]thpr:</small> k, that one's on the shelf for later, go on Connor<br />
<small>(10:41 AM) cpmeister:</small> is there anything else you can think of thats Facade related? James?<br />
<small>(10:42 AM) James[Code_SB]:</small> No, I think we've covered it pretty well<br />

==== Threading ====

<small>(10:42 AM) [Arch_SB]thpr:</small> We've had a few threading issues come up in the last few weeks, so at some point I'd like to understand how many threads are in the UI (or at least the assumptions it makes about threading) and what it assumes about the core's ability to handle queries or sets from multiple threads<br />
<small>(10:42 AM) [Arch_SB]thpr:</small> not sure if that's best handled now or not<br />
<small>(10:43 AM) cpmeister:</small> for now it is just 2 types of  threads, the UI event thread and the export sheet threads<br />
<small>(10:43 AM) [Arch_SB]thpr:</small> Specifically, some changes made to MovementFacet indicated a read is happening in a thread concurrently to a write in another thread (since a variable triggered an NPE and it's never null when exiting any method<br />
<small>(10:44 AM) James[Code_SB]:</small> Just quickly, there are really only two main threads - the swing worker and the character sheet thread<br />
<small>(10:44 AM) [Arch_SB]thpr:</small> and both can call the facade?<br />
<small>(10:44 AM) James[Code_SB]:</small> no<br />
<small>(10:45 AM) James[Code_SB]:</small> The character sheet thread will use the export system via the facade <br />
<small>(10:45 AM) cpmeister:</small> there is also another thread on the summay tab for the html character info<br />
<small>(10:46 AM) James[Code_SB]:</small> Yes so potentially multiple export threads running is the worst case<br />
<small>(10:46 AM) James[Code_SB]:</small> and sadly export currently forces an update of the character<br />
<small>(10:46 AM) James[Code_SB]:</small> Which I suspect is where some of the issue comes from<br />
<small>(10:46 AM) [Arch_SB]thpr:</small> ok.  And since we still clone PC and that forces resets we can end up with one read thread and one write thread.  ok.  good to know<br />
<small>(10:47 AM) cpmeister:</small> well, one write thread and multiple read threads<br />
<small>(10:47 AM) [Arch_SB]thpr:</small> That may take some thinking and work to make the core resiliant to that (wasn't designed for it)<br />
<small>(10:47 AM) James[Code_SB]:</small> You'd think  but have a lok at pcgen.io.ExportHandler.write(PlayerCharacter, BufferedWriter)<br />
<small>(10:47 AM) [Arch_SB]thpr:</small> k<br />
<small>(10:49 AM) cpmeister:</small> any other issues?<br />
<small>(10:49 AM) [Arch_SB]thpr:</small> not at the moment<br />
<small>(10:50 AM) cpmeister:</small> so, startup system or property persistence system next?<br />
<small>(10:50 AM) [Arch_SB]thpr:</small> startup is good<br />
<small>(10:50 AM) cpmeister:</small> k<br />

==== Startup ====

<small>(10:51 AM) cpmeister:</small> the startup system has been greatly revised and has been moved into its own package (pcgen.system)<br />
<small>(10:51 AM) cpmeister:</small> the main entry point is Main.java which contains a highly simplified startup process<br />
<small>(10:52 AM) cpmeister:</small> so of the major changes are in the handling of plugin and dataset loading<br />
<small>(10:53 AM) cpmeister:</small> these all extend a new class PCGenTask which allow for its implementations to notify listeners when the task progress has changed<br />
<small>(10:53 AM) devonjones_:</small> I would really like us to consider persisting memory from the last run of all the rules so that we can have a much quicker startup to the point of being able to modify a character<br />
<small>(10:54 AM) cpmeister:</small> for the game mode and campaign loading this has required the creating of a new loader classes which monitor the progress of the loads<br />
<small>(10:54 AM) [Arch_SB]thpr:</small> So there is still 1 entry point for both UI and non-UI?<br />
<small>(10:54 AM) devonjones_:</small> (just noting since it's startup related)<br />
<small>(10:54 AM) cpmeister:</small> yes<br />
<small>(10:54 AM) [Arch_SB]thpr: @Devon:</small> That is something we want to look at, just hasn't had someone to do it<br />
<small>(10:55 AM) cpmeister: @Tom:</small> yes those are both in the Main.java<br />
<small>(10:55 AM) [Arch_SB]thpr:</small> and we need to hash out what is done automatically vs. cached, how you trigger reloads, that type of stuff<br />
<small>(10:56 AM) cpmeister:</small> no work has been put into that kind of system yet<br />
<small>(10:56 AM) cpmeister:</small> but it is definitely worth discussing<br />
<small>(10:57 AM) James[Code_SB]: Probably off tiopic just for now though :</small>)<br />
<small>(10:</small>57 AM) Maredudd [~maredudd@12.139.146.131] entered the room.<br />
<small>(10:57 AM) cpmeister:</small> anyhow, the new game mode and campaign loaders have made the old PersistenceManager obsolete<br />
<small>(10:58 AM) cpmeister:</small> unfortunately, we can't uncouple PersistenceManager since it is still used as a static container for the currently selected sources<br />
<small>(10:58 AM) [Arch_SB]thpr:</small> ok, wait, so pcgen.persistence is basically deprecated?<br />
<small>(10:58 AM) cpmeister:</small> no, just PersistenceManager<br />
<small>(10:59 AM) [Arch_SB]thpr:</small> ah, ok, so just the container for LstSystemLoader.  thanks<br />
<small>(10:</small>59 AM) Maredudd left the room.<br />
<small>(10:59 AM) cpmeister:</small> well, the new loaders are composed of code copied from the LstSystemLoader, so the LstSystemLoader is also deprecated<br />
<small>(11:00 AM) [Arch_SB]thpr:</small> ok<br />
<small>(11:00 AM) cpmeister:</small> the loading process is the same, but the code has just moved<br />
<small>(11:01 AM) Maredudd [~maredudd@12.139.146.131] entered the room.</small><br />
<small>(11:01 AM) [Arch_SB]thpr:</small> I see, so CampaignFileLoader and SourceFileLoader at this point<br />
<small>(11:01 AM) [Arch_SB]thpr:</small> and GameModeFileLoader<br />
<small>(11:01 AM) cpmeister:</small> yes<br />
<small>(11:01 AM) [Arch_SB]thpr:</small> that's nice, LstSystemLoader was big anyway<br />
<small>(11:02 AM) cpmeister: :</small>)<br />
<small>(11:02 AM) James[Code_SB]:</small> @Connor, speaking of tasks, I was thinking it might be good to move character load into a task so it gets a progress bar like source loading<br />
<small>(11:03 AM) [Admin_SB]Andrew:</small> 2nd the motion<br />
<small>(11:03 AM) [Arch_SB]thpr:</small> So tasks are progress listeners?  Do they do anything else?<br />
<small>(11:03 AM) [Admin_SB]Andrew:</small> :)<br />
<small>(11:03 AM) cpmeister:</small> @Tom: no, not really. Just set them up and execute them<br />
<small>(11:03 AM) [Arch_SB]thpr:</small> k<br />
<small>(11:04 AM) cpmeister:</small> I'm not sure that making character loading a task would be worth while since the process is generally very fast<br />
<small>(11:05 AM) devonjones_:</small> @James I agree, the abuse character loading subjects the interface to really makes the software look bad<br />
<small>(11:06 AM) cpmeister:</small> I'm not sure about other people's systems but mine usually creates a character in less than a second<br />
<small>(11:07 AM) James[Code_SB]:</small> For higher level or comple characters it can take a little bit longer for me<br />
<small>(11:08 AM) James[Code_SB]:</small> Enough to notice the pause and sometimes wonder if the request is being processed<br />
<small>(11:08 AM) devonjones_:</small> so to be fair, I'm still using 5.17.8 on my main system<br />
<small>(11:08 AM) devonjones_:</small> but it takes like 10-20 seconds<br />
<small>(11:08 AM) devonjones_:</small> maybe more<br />
<small>(11:08 AM) devonjones_:</small> 7th level character<br />
<small>(11:08 AM) [Admin_SB]Andrew:</small> 20-30 seconds, my characters are complex<br />
<small>(11:08 AM) cpmeister:</small> ah, I see where the load times can blow up then<br />
<small>(11:08 AM) devonjones_:</small> if the new UI has fixed that I havn't verified it with my actual characters<br />
<small>(11:09 AM) [Admin_SB]Andrew:</small> @devon - my load times are against the trunk<br />
<small>(11:09 AM) devonjones_:</small> loading and saving both lock up the UI, and honestly it's unplesant<br />
<small>(11:09 AM) devonjones_:</small> it should totally be on it's own thread<br />
<small>(11:09 AM) cpmeister:</small> very well, lets try to move character loading into a task then<br />
<small>(11:09 AM) devonjones_:</small> saving as well.....<br />
<small>(11:10 AM) devonjones_:</small> it could just be one persistence thread<br />
<small>(11:10 AM) cpmeister:</small> there could be problems with using multiple threads though<br />
<small>(11:10 AM) James[Code_SB]:</small> Sorry for taking things off topic again<br />
<small>(11:11 AM) Zaister:</small> loading feels faster with the new UI, but still noticeable<br />
<small>(11:11 AM) cpmeister:</small> what if the user changes the character while it is saving?<br />
<small>(11:11 AM) [Arch_SB]thpr:</small> Let's just FREQ the request and keep going.  Andrew can you capture that one?<br />
<small>(11:11 AM) [Admin_SB]Andrew:</small> Sure<br />
<small>(11:11 AM) [Arch_SB]thpr:</small> let's hash out the potential issues and design offline<br />
<small>(11:11 AM) cpmeister:</small> k<br />
<small>(11:11 AM) James[Code_SB]:</small> @Andrew I'm happy to create that one<br />
<small>(11:12 AM) cpmeister:</small> James, is there anything else you can think of that is startup related?<br />
<small>(11:13 AM) James[Code_SB]:</small> New command line stuff including PDF output, but its pretty stright forward<br />
<small>(11:13 AM) cpmeister:</small> any other questions?<br />
<small>(11:13 AM) James[Code_SB]:</small> So I think we've covered that topic well<br />
<small>(11:14 AM) [Arch_SB]thpr:</small> I have one other non-preference UI question<br />
<small>(11:14 AM) [Arch_SB]thpr:</small> but not sure where it fits<br />
<small>(11:14 AM) cpmeister:</small> shoot<br />
<small>(11:15 AM) [Arch_SB]thpr:</small> actually, forget it, too much in the weeds for the present - let's go on to persistence<br />

==== Property Persistence ====

<small>(11:15 AM) cpmeister:</small> onto property persistence<br />
<small>(11:16 AM) cpmeister:</small> the new code has the addition of the PropertyContext classes<br />
<small>(11:16 AM) cpmeister:</small> these serve as general hashmaps maping strings to string derived values<br />
<small>(11:17 AM) cpmeister:</small> eventually they will serve as a replacement for the SettingsHandler class which has grown much too large<br />
<small>(11:17 AM) cpmeister:</small> the PropertyContexts are each stored in their own file<br />
<small>(11:18 AM) cpmeister:</small> right now we have one for general preferences, one for UI preferences, and another for legacy preferences (SettingsHandler)<br />
<small>(11:18 AM) [Arch_SB]thpr:</small> In effect, we have modularized the preferences?<br />
<small>(11:18 AM) cpmeister:</small> correct<br />
<small>(11:19 AM) cpmeister:</small> but PropertyContexts have other features as well<br />
<small>(11:19 AM) [Arch_SB]thpr:</small> So occasionally we end up asking people to delete pcgen.ini, does this impact that?<br />
<small>(11:19 AM) [Arch_SB]thpr:</small> is there more to delete now?<br />
<small>(11:19 AM) cpmeister:</small> yes and no<br />
<small>(11:20 AM) cpmeister:</small> as it was before, the use can simply delete the folder containing the files to start preferences from scratch<br />
<small>(11:20 AM) cpmeister:</small> so no real added work there<br />
<small>(11:20 AM) [Arch_SB]thpr:</small> k<br />
<small>(11:21 AM) cpmeister:</small> but since it is modularized the we would have to identify where an offending property is stored before we could ask the user delete the file<br />
<small>(11:21 AM) [Arch_SB]thpr:</small> right ok<br />
<small>(11:22 AM) cpmeister:</small> anyway, the PropertyContext have 2 additional features, one is that they can be listened to<br />
<small>(11:22 AM) cpmeister:</small> anywhere in the code a listener can be attached to a PropertyContext to track changes in specific properties<br />
<small>(11:22 AM) cpmeister:</small> or even all properties<br />
<small>(11:23 AM) cpmeister:</small> so far this feature hasn't been utilized very much but it exists for flexibility<br />
<small>(11:23 AM) cpmeister:</small> the second feature is that within a PropertyContext a child context can be created<br />
<small>(11:24 AM) cpmeister:</small> this allows for a set of properties to be isolated without having to create a new file for them<br />
<small>(11:24 AM) cpmeister:</small> in general this works by adding a prefix to all the child properties that are stored in the parent context<br />
<small>(11:24 AM) devonjones_:</small> is there a way we could implement this /without/ requiring the user to delete the ini files anymore?<br />
<small>(11:25 AM) cpmeister:</small> that all depends on how well property checking is performed<br />
<small>(11:26 AM) cpmeister:</small> the only reason the issue of deleting arises is that somewhere in the code it doesn't do checks to make sure that the property value is valid<br />
<small>(11:26 AM) [Arch_SB]thpr:</small> Hopefully it's only in a dire problem you even ask them to do it<br />
<small>(11:26 AM) devonjones_:</small> if we are going to compete with commercial vendors, that kind of UI thing needs to b e considered<br />
<small>(11:26 AM) devonjones_:</small> as it stands, I have a strong tendency to keep a seperate copy of PCGen for every campaign<br />
<small>(11:27 AM) devonjones_:</small> which is fine for me, but can't really be expected of average users<br />
<small>(11:28 AM) [Arch_SB]thpr:</small> So are you thinking we need a button that auto deletes the files, or a lot more testing on loading/saving prefs or both?<br />
<small>(11:28 AM) cpmeister:</small> oh, I forgot to mention the startup property context, config.ini<br />
<small>(11:28 AM) cpmeister:</small> this file contains all of the startup information for pcgen<br />
<small>(11:28 AM) James[Code_SB]:</small> I think a factory reset option somewhere would be handy<br />
<small>(11:28 AM) cpmeister:</small> namely the location of all the directories<br />
<small>(11:28 AM) devonjones_:</small> I think we need a pref scheme that lets us remove suspect preferences<br />
<small>(11:28 AM) cpmeister:</small> if this file is deleted pcgen essentially returns to factory defaults<br />
<small>(11:28 AM) devonjones_:</small> perhaps a string on a per setting basis that lets is identify the code version that wrote it<br />
<small>(11:29 AM) devonjones_:</small> s/is/us/<br />
<small>(11:29 AM) cpmeister:</small> that is asuming you to point the new config into the same directories as the old one<br />
<small>(11:29 AM) cpmeister:</small> *asuming you don't<br />
<small>(11:29 AM) [Arch_SB]thpr:</small> I think we need to capture that requirement and take it to the lists to flesh out what it means needs to be done<br />
<small>(11:29 AM) [Arch_SB]thpr:</small> Not sure we're going to want to hammer through it here<br />
<small>(11:30 AM) devonjones_:</small> that's fair<br />
<small>(11:30 AM) [Arch_SB]thpr:</small> So a question on the properties<br />
<small>(11:31 AM) [Arch_SB]thpr:</small> SettingsHandler tended to be very setBlah and getBlah focused.  By the description, you are using more of a HashMap concept, where the key is known by the caller vs. using a separate method.  Is there a list of those keys we are storing somewhere so folks know where to look?<br />
<small>(11:32 AM) cpmeister:</small> for preferences, these keys are stored in custom subclasses of PropertyContext<br />
<small>(11:32 AM) cpmeister:</small> like in PCGenSettings.java for instance<br />
<small>(11:</small>32 AM) ***[Admin_SB]Andrew is away from keyboard<br />
<small>(11:32 AM) [Arch_SB]thpr:</small> ok<br />
<small>(11:33 AM) cpmeister:</small> but for arbitrary properties, like UI column locations these is no requirement for the keys to be known externally<br />
<small>(11:34 AM) cpmeister:</small> any other questions?<br />
<small>(11:34 AM) [Arch_SB]thpr:</small> not at the moment<br />
<small>(11:35 AM) James[Code_SB]:</small> none here<br />
<small>(11:35 AM) devonjones_:</small> same<br />
<small>(11:35 AM) cpmeister:</small> I think that covers the changes from the new UI, onto facets?<br />
<small>(11:36 AM) [Arch_SB]thpr:</small> Just as a note I need to noodle on the preferences / settings thing.  May come back to that in a future meeting on next steps there before we do a full conversion from SettingsHandler<br />
<small>(11:37 AM) [Arch_SB]thpr:</small> Also want to note the conversation (I think from the lists) that indicated the game mode info currently in SettingsHandler doesn't belong there and wouldn't get moved into the property system - it needs a new, appropriate home (that can handle more than one being loaded)<br />
<small>(11:37 AM) James[Code_SB]:</small> As I work on things I'm dragging setting out from SettingsHandler and into the new system<br />
<small>(11:37 AM) [Arch_SB]thpr:</small> (just to keep all those thoughts in one place)<br />
<small>(11:37 AM) cpmeister:</small> oh, I guess there is one last thing I could mention about the property contexts<br />
<small>(11:38 AM) cpmeister:</small> the old SettingsHandler had a two layers of persistence<br />
<small>(11:38 AM) cpmeister:</small> one was local variables and the second layer was the internal hashmap<br />
<small>(11:38 AM) cpmeister:</small> the new property system only has a single layer, the hashmap layer<br />
<small>(11:38 AM) cpmeister:</small>  not sure what problems this might cause but thought it was worth mentioning<br />
<small>(11:39 AM) [Arch_SB]thpr:</small> k<br />
<small>(11:40 AM) cpmeister:</small> I think thats it from me<br />
<small>(11:40 AM) [Arch_SB]thpr:</small> Anything else on the new UI project?<br />
<small>(11:41 AM) [Arch_SB]thpr:</small> We generally hold these to 2 hours, so I'm not sure we want to delve into either of the other 2 major topics due to time risk.  Any objections to deferring those to another meeting?<br />

==== UI Delegate ====

<small>(11:41 AM) James[Code_SB]:</small> Oh the uidelegate would be useful to mention<br />
<small>(11:41 AM) cpmeister:</small> ah yes, the UIDelegate<br />
<small>(11:41 AM) James[Code_SB]:</small> The facade sometimes needs to ask the uiser things or let the user know of issues<br />
<small>(11:42 AM) James[Code_SB]:</small> To avoid it coding in swing dependancies etc it gets passed a UIDelegate via which it can interact with whatever UI is in place<br />
<small>(11:42 AM) James[Code_SB]:</small> This is currently assuming dialogs, but it would interesting to see how this worked on a mobile device for instance<br />
<small>(11:43 AM) James[Code_SB]:</small> The uidelegate in the case of the new UI is the main PCGen frame, which implemnts the appropriate interface<br />
<small>(11:44 AM) James[Code_SB]:</small> any questions on that one?<br />
<small>(11:44 AM) [Arch_SB]thpr:</small> So theoretically, those methods on UIDelegate are called from the Facade?<br />
<small>(11:44 AM) [Arch_SB]thpr:</small> So a "you need to do X event" coming out of the core goes through that part of the Facade in order to get the answer returned to the core?<br />
<small>(11:44 AM) James[Code_SB]:</small> That's the intent<br />
<small>(11:44 AM) [Arch_SB]thpr:</small> which gives the core a way to call the Facade/UI without having a swing dependency<br />
<small>(11:45 AM) James[Code_SB]:</small> I have yet to subvert the choosers for instance to use that system but it is on my todo list (damn is that list long too)<br />
<small>(11:45 AM) [Arch_SB]thpr:</small> (hopefully obvious that the code may not LITERALLY work that way in the method calls, but by intent)<br />
<small>(11:45 AM) devonjones_:</small> so at least with android, if I'm understanding it, it actually fits reasonably well.  The API does a lot to keep 'real work' separated from UI.<br />
<small>(11:45 AM) devonjones_:</small> probably on android I would fire an intent when I say the dialog request<br />
<small>(11:46 AM) devonjones_:</small> s/say/saw/<br />
<small>(11:46 AM) James[Code_SB]:</small> cool, so it sounds like it could work<br />
<small>(11:46 AM) cpmeister:</small> @Devon, IIRC android doesn't do a very good job of supporting modal dialogs<br />
<small>(11:47 AM) devonjones_:</small> it depends on your app design<br />
<small>(11:47 AM) devonjones_:</small> it does have a modal dialog<br />
<small>(11:48 AM) cpmeister:</small> its not modal in the same sense as it is in Swing<br />
<small>(11:48 AM) devonjones_:</small> I suspect, based on this conversation, I would probably need to make the pcgen core into it's own activity<br />
<small>(11:49 AM) cpmeister:</small> well, I think we might be getting a bit off topic<br />
<small>(11:49 AM) devonjones_:</small> this is true<br />
<small>(11:49 AM) cpmeister:</small> lets save the conversation for later<br />
<small>(11:49 AM) devonjones_:</small> yes, very<br />
<small>(11:49 AM) [Arch_SB]thpr:</small> ok, any last questions on the UI?<br />
<small>(11:49 AM) James[Code_SB]:</small> None here :P<br />


=== Other Business ===

<small>(11:50 AM) [Arch_SB]thpr:</small> Any objections to scheduling a new meeting for the other 2 major topics? (we'll find time with a thread on _dev)<br />
<small>(11:50 AM) devonjones_:</small> none here<br />
<small>(11:50 AM) James[Code_SB]:</small> No that should be fine<br />
<small>(11:50 AM) cpmeister:</small> none here<br />
<small>(11:50 AM) Zaister:</small> ok with me<br />
<small>(11:50 AM) James[Code_SB]:</small> I'll post this meeting chat to the wiki so we can refer people to it for a description of the UI architecture<br />
<small>(11:50 AM) [Arch_SB]thpr:</small> Any open topics folks want to hit in the last 10 min?<br />
<small>(11:51 AM) devonjones_:</small> yes<br />
<small>(11:51 AM) devonjones_: so the architecture at http:</small>//wiki.pcgen.org/Architecture<br />
<small>(11:51 AM) devonjones_:</small> I would like to propose that we move to every box in that being it's own jar<br />
<small>(11:52 AM) devonjones_:</small> I think it has a lot of benefits for the existing app<br />
<small>(11:52 AM) James[Code_SB]:</small> I can't say I am overly keen on that idea<br />
<small>(11:52 AM) cpmeister:</small> me neither<br />
<small>(11:52 AM) devonjones_:</small> it gives us a way to enforce the the arch borders<br />
<small>(11:52 AM) devonjones_:</small> to ensure that nothing from one box is calling into another box<br />
<small>(11:53 AM) James[Code_SB]:</small> I thinik they should be packages but having different jars makes user startup harder and install problems harder to diagnose<br />
<small>(11:53 AM) devonjones_:</small> it also makes  interfacing with pcgen outside of the existing app much easier, as you can use the ones you nee<br />
<small>(11:53 AM) devonjones_:</small> need<br />
<small>(11:53 AM) [Arch_SB]thpr:</small> I think it would be good to note - either way - that some of them are still inexorably linked at the moment<br />
<small>(11:53 AM) devonjones_:</small> we already have a large number of jars<br />
<small>(11:54 AM) James[Code_SB]:</small> I don't think that sort of static analysis should drive the ditrbution<br />
<small>(11:54 AM) devonjones_: @Tom:</small> right,  moving to this woudl help us idntigy where the code is breaking arch<br />
<small>(11:54 AM) James[Code_SB]:</small> Yes, but they are quite different and cause enoguh headaches<br />
<small>(11:54 AM) devonjones_:</small> god, my typing is sucking, sorry<br />
<small>(11:55 AM) devonjones_:</small> so to be clear, I am angling towards being able to make an android app, and I want to be forward with that<br />
<small>(11:55 AM) [Arch_SB]thpr:</small> So just thinking about this a bit - right now  are we at a point where a non-UI call can operate without ever trying to load a UI class?<br />
<small>(11:56 AM) devonjones_:</small> and one of the big problems is that in it's one jar state, frankly it's simply not possible<br />
<small>(11:56 AM) [Arch_SB]thpr:</small> That would have broken in the old UI<br />
<small>(11:56 AM) cpmeister:</small> for the most part yes, but there are still some linkages in the core to the old UI which have not been resolved<br />
<small>(11:56 AM) James[Code_SB]:</small> but are on the agenda<br />
<small>(11:56 AM) cpmeister:</small> but from what I can tell most all the linkages from the new UI to the core have been eliminated<br />
<small>(11:57 AM) [Arch_SB]thpr:</small> ok<br />
<small>(11:57 AM) James[Code_SB]:</small> @Connor I think we might still have some work in the sources dialog - I thikn the facade needs to be expanded there<br />
<small>(11:58 AM) devonjones_:</small> my gut is that without splitting a goal of splitting things, we can't actually enforce strict arch borders<br />
<small>(11:58 AM) James[Code_SB]:</small> As a suggestion, a first, uncontrovertial stage for this topic would be being able to label each box with a package name<br />
<small>(11:58 AM) [Arch_SB]thpr:</small> We should try creating a JAR without the UI and runnign it through to get a PDF and see if we can pull it off in a headless fashion<br />
<small>(11:58 AM) devonjones_:</small> and I think if we manage to get those strict borders into place, it has high value for the existing project<br />
<small>(11:58 AM) devonjones_: @James:</small> very reasonable start<br />
<small>(12:00 PM) [Arch_SB]thpr:</small> ok, so I'll try to dig up that figure and label it with the package names<br />
<small>(12:00 PM) James[Code_SB]:</small> Cool<br />
<small>(12:00 PM) [Arch_SB]thpr:</small> and we'll start there<br />
<small>(12:00 PM) [Arch_SB]thpr:</small> I think tehre are 2 projects out of this though.  One is I can identify what classes / behaviors are violating the package names they should be in<br />
<small>(12:00 PM) James[Code_SB]:</small> and we should go the other way and add package docs to point each package back to the arch layers<br />
<small>(12:01 PM) [Arch_SB]thpr:</small> and the other is my comment about seeing if we can get a headless mode running to produce a PDF to "prove" we have the UI detached.  Obviously this may be scheduled for a future date once some additional work is done, but I think we should have that as a target.  that make sense?<br />
<small>(12:01 PM) cpmeister:</small> makes sense<br />
<small>(12:02 PM) devonjones_:</small> yes, and that gets me much closer to my goal<br />
<small>(12:02 PM) devonjones_:</small> so as a more restrained approach<br />
<small>(12:02 PM) [Arch_SB]thpr:</small> ok, we're past 8.  Any last comments on this before we close?<br />
<small>(12:02 PM) devonjones_:</small> I would at least like to propose an ant target that produces a jar that can produce PDFs and has no swing links<br />
<small>(12:03 PM) James[Code_SB]:</small> None here<br />
<small>(12:03 PM) devonjones_:</small> ok, I can hold that question until next meeting<br />
<small>(12:03 PM) devonjones_:</small> so retracted for now<br />
<small>(12:03 PM) [Arch_SB]thpr:</small> I think there is work to do before we can get to that anyway<br />
<small>(12:03 PM) devonjones_:</small> oh, clearly<br />
<small>(12:03 PM) [Arch_SB]thpr:</small> from what I can tell from James' and Connor's comments<br />
<small>(12:03 PM) devonjones_:</small> I'm purely talking goals<br />
<small>(12:04 PM) James[Code_SB]:</small> I'd be surprised if there was a to left to do there - I think it is reasonably close<br />
<small>(12:04 PM) [Arch_SB]thpr:</small> ok, thanks everyone for attending, [swipes Andrew's gavel and bangs, then hands it back]<br />