Dev Meeting Log 20090429

Below is the log of our developer IRC chat In attendance were: James (james), Andrew (nuance), Connor (cpmeister) Drew, and Tom (thpr).

Summary

• Move of _dev list to Yahoo (from SourceForge)
• UI redesign update
• Requirements for UI mockup

Transcript

[12:11] [Code_SB]james: So, lets start
[12:11] [Code_SB]james: The agenda (such as it is) is
[12:11] [Code_SB]james: 1. Moving the dev list to yahoo 2. UI redesign update 3. Architectural requirements for the UI mockup 4. Other projects for the next release (yes that's a clal fro people's pet projects too) 5. Anything else anyone wants to raise
[12:11] [Code_SB]james: Anyone want to add or remove from that?
[12:12] [code]nuance: nope
[12:12] [Arch_SB]thpr: looks good to me
[12:12] [Code_SB]james: 1. Moving the dev list to yahoo
[12:13] [Code_SB]james: For purposes of higher visibility and easier access, there has been the suggestion that the code list should be moved from SF to Yahoo
[12:13] [code]nuance: Don't see the point, especially if we're moving to our own server at some point
[12:13] [Arch_SB]thpr: I don't think we should trust that we're moving to our own server soon
[12:13] [Code_SB]james: That's not happening any time soon
[12:13] [code]nuance: no strong preference either way, it's open to everyoine anyway
[12:14] [Arch_SB]thpr: I think being on Yahoo! would be a lower barrier to entry for people to listen in IF we make the effort to fire things across the list first
[12:14] [Arch_SB]thpr: Actually, as best I can tell, -devel isn't open to anyone outside the members of the PCGen project on SourceForge
[12:14] [Arch_SB]thpr: which means people who might want to lurk can't listen in
[12:14] [code]nuance: ah right, in that case movong might be good
[12:15] [Arch_SB]thpr: the downside is that we "lose" our archives
[12:15] [Arch_SB]thpr: in the sense that they are in a different place
[12:15] [Arch_SB]thpr: not sure how much that matters, but it's one piece of the equation
[12:16] [Code_SB]james: afk for a sec - work call
[12:17] cpmeister: I don't mind either way
[12:17] [Code_SB]james: back
[12:17] [Arch_SB]thpr: Another option is to make the list public, but leave it on SourceForge
[12:17] [Arch_SB]thpr: if you go to http://sourceforge.net/mail/?group_id=25576 when you're not logged in
[12:17] [Arch_SB]thpr: there are public lists (such as our commits)
[12:17] [Arch_SB]thpr: that don't require you be a member of our project
[12:18] [Arch_SB]thpr: the one comment I'd make about converting to an open list is it opens up the archives
[12:18] [Arch_SB]thpr: and I'm not sure whether there are conversations in there from before my time that are, well, interesting
[12:18] [Arch_SB]thpr: and might not deserve the light of day
[12:18] [Arch_SB]thpr: which reminds me I need to hide the -arch list on SF...
[12:18] [code]nuance: Hmm, I'm slightly wary of make formerly private lists public, for that reason
[12:19] [code]nuance: A new list somewhere else avoids that.
[12:19] [Code_SB]james: Yeah - I don't expect there is anything too sensitive, but I don't want to do an audit so I'd agree - lreave it private
[12:20] [Code_SB]james: We can link back from Yahoo to the SF list
[12:20] [Code_SB]james: and those interested can join and read it
[12:20] [Code_SB]james: but it keeps google out :)
[12:20] [Arch_SB]thpr: :)
[12:20] [code]nuance: private list keeps it out of google, which limits the expoure a lot
[12:21] [code]nuance: I should read before hitting enter
[12:21] [Arch_SB]thpr: no worries, you're on 3AM lag, so you're good :)
[12:22] [Code_SB]james: ok, so that sounds like a decision
[12:22] [code]nuance: Sounds to me like you have no objections
[12:22] [code]nuance: Doh!
[12:23] [Code_SB]james: I'll create the list later in the week and send out notiifcations
[12:23] [Code_SB]james: I wonder if we can make the old list read only
[12:23] [Arch_SB]thpr: I'll try to check
[12:23] [Arch_SB]thpr: I'm logged in right now
[12:23] [code]nuance: Wouldn't do that for a while
[12:24] [Code_SB]james: good point Andrew
[12:24] [Code_SB]james: 2. UI redesign update
[12:24] [Code_SB]james: Connor, did you want to do that one please?
[12:24] cpmeister: sounds like my cue
[12:24] [Code_SB]james: :)
[12:25] cpmeister: right now as it stands the UI development is on hiatus
[12:25] [Code_SB]james: BTW: I'll post a copy of the log to the devel list afterwards
[12:25] cpmeister: this is largly due to the wall of code that I have encountered with regards to the Facade API
[12:26] cpmeister: so far I have been creating that facade with the intent creating it myself, but there are too many factors that I am unaware of that prevent me from continuing
[12:26] [Code_SB]james: Fair enough
[12:26] [Arch_SB]thpr: Can we be specific on articulating the challenges you're facing
[12:27] [Arch_SB]thpr: by starting a Wiki page with them or something to that effect?
[12:27] cpmeister: thus, I have been refraining from UI work until the Facades are completed
[12:27] cpmeister: yeah, that would be a good start
[12:27] [Arch_SB]thpr: I think if we can do that, then we do a few things
[12:27] [Arch_SB]thpr: first it gets it "down on paper" so things don't get lost
[12:28] [Arch_SB]thpr: second, you can document as you run into things, and move elsewhere, and othere (myself, etc.) can fill in behind you to re-enable your progress
[12:28] [Arch_SB]thpr: also, if things come up repeatedly, I might be able to say "condition X just create a method getX" and I'll implement it later
[12:29] cpmeister: the major issues I have encountered are the structural design, and the intents that go along with it. Which ones are appropriates, and which ones would have to be put on hold for a while
[12:29] cpmeister: the prereq interfaces, the show/hide models, are just a few of the things I can think of
[12:30] [Arch_SB]thpr: ok, one small tangent here
[12:30] [Arch_SB]thpr: James, are we free to make major changes in the Trunk now?
[12:32] [Code_SB]james: Yes I think we can do that now
[12:32] [Arch_SB]thpr: ok
[12:32] [Arch_SB]thpr: So I think there are a few things to do
[12:32] [Code_SB]james: Ther ewill be 5.16.1 work, but I am going to trim that down to a much smaller list of things that really have a user impact and can be solved without major headaches
[12:32] [Arch_SB]thpr: First would be to start being specific on documenting your challenges on the Wiki
[12:33] [Arch_SB]thpr: second is to pick something where we can implement where I'd like to get to in 5.16
[12:33] [Arch_SB]thpr: and which would enable the UI work
[12:33] [Arch_SB]thpr: like starting with Languages, for example
[12:33] [Arch_SB]thpr: err, I didn't mean 5.16
[12:34] [Arch_SB]thpr: habit... meant where we get to in the next major release
[12:34] [Code_SB]james: Lets call it 5.18 for ease of reference until a decision is made
[12:34] [Arch_SB]thpr: k
[12:34] [Code_SB]james: Don;t forget thqt our first target for the UI is demo app that people can play with and give feedback
[12:35] cpmeister: I not sure what the demo capabilities would be without deciding on the facade api first
[12:36] [Code_SB]james: Yes I think that facade will be an integral part of it
[12:36] [Arch_SB]thpr: can you just define the first pass API
[12:36] [Arch_SB]thpr: we may have to change it, but we have to nail down something first
[12:36] [Arch_SB]thpr: and then adapt
[12:37] [Arch_SB]thpr: just create methods for whatever you need
[12:37] [Arch_SB]thpr: getHands
[12:37] [Arch_SB]thpr: getFeet
[12:37] [Arch_SB]thpr: etc.
[12:37] [Code_SB]james: That's about the only way it could work that I can see - otherwise we end up spending forever
[12:37] [Arch_SB]thpr: we can always inline stuff late in the release
[12:38] [Arch_SB]thpr: I should be able to tell pretty quickly if we get into any major areas where assumptions are wildly different
[12:38] cpmeister: k
[12:38] [Arch_SB]thpr: there will always be minor stuff to work around, just like there are a few nasty hacks in 5.16 when the token/loader system got grafted on
[12:38] [Code_SB]james: Should we be considering a prototype approach? Do the minimum necessary to give users a feel for how it would operate ?
[12:38] [Arch_SB]thpr: I think so
[12:39] [Arch_SB]thpr: the facades should be interfaces
[12:39] [Arch_SB]thpr: so we can create mock objects
[12:39] [Arch_SB]thpr: vs. trying to interact with a real core
[12:39] cpmeister: I was sort of hoping that it would interact with the real core, just not neccessarily all of it
[12:39] [Code_SB]james: Well, I;d start with mock objects - they cna be used for unit tests then too
[12:40] [Code_SB]james: and then we can migrate to the real core
[12:40] cpmeister: ah, good point
[12:40] [Code_SB]james: That way the UI work doesn;t get held up by core and vice versa
[12:41] [Arch_SB]thpr: agree, that sounds like a good idea
[12:41] [Arch_SB]thpr: that way I won't be a gate on Connor
[12:41] cpmeister: I just wanted a general consensus on the facade api, because if left to my own devices, I'm pretty sure I would create something vastly different than what the core could handle
[12:42] [Arch_SB]thpr: take a pass at it
[12:42] [Arch_SB]thpr: but don't implement the whole thing in a weekend
[12:42] [Code_SB]james: :)
[12:42] [Arch_SB]thpr: unless you're *really* bored
[12:42] [Arch_SB]thpr: and let us take a glance at it
[12:42] [Code_SB]james: A strawman is always a good discussion starter
[12:46] [Arch_SB]thpr: I think we actually covered #2 and #3 in that discussion
[12:46] cpmeister: well, those topics were pretty similar
[12:46] [Code_SB]james: Yeah I think so
[12:46] [Code_SB]james: I see three tasks there
[12:47] [Code_SB]james: 1. Create a starting Facade (and discussion form the rest of arch and code as needed)
[12:47] [Code_SB]james: 2. Link up the UI to the facade
[12:47] [Code_SB]james: 3. Create mock objects to implement the facade
[12:47] [Code_SB]james: and at the end of that we should have a demo app
[12:47] cpmeister: 2&3 could be done simultaniously
[12:48] [Code_SB]james: Yep
[12:48] [Code_SB]james: Does that sound right to everyone?
[12:48] [Arch_SB]thpr: y
[12:48] [code]nuance: yep
[12:49] cpmeister: what's next then?
[12:49] [Code_SB]james: Not quite so fast sorry :)
[12:49] [code]nuance: 5.18 scope iirc
[12:49] [Code_SB]james: Some timeframes would be good here if we can
[12:49] [Code_SB]james: Connor, amny thoughts on how long you would like to spend on #1?
[12:50] cpmeister: well, if you are giving me free reign on the first pass, I'd say only a few weeks
[12:50] cpmeister: well, not next week, I have midterms
[12:51] [Code_SB]james: Yes those are more important!
[12:52] cpmeister: sometime after that I suppose
[12:52] [Code_SB]james: So we are porbably looking at Sat May 16 or so?
[12:53] cpmeister: actually, I've pretty much finished the first pass...I just need to make minor adjustments for the prereq stuff
[12:54] [Code_SB]james: Is it in code or would you prefer to start on a wiki page?
[12:54] [Arch_SB]thpr: what about the facades, though
[12:54] cpmeister: hmm, for the mock UI, does the data loader UI stuff even need to be implemented?
[12:54] [Arch_SB]thpr: I'm confused on what is finished
[12:54] [Code_SB]james: Well, it would just say loaded :)
[12:55] [Arch_SB]thpr: I'd worry much more about use during character build vs. load
[12:56] cpmeister: just a sec, I'm checking what my code currently looks like
[13:01] cpmeister: yeah, with the exception of popup choosers, prereqs, the first pass can be considered finished in pcgen.core.facade from the sandbox
[13:03] cpmeister: it should be enough to demo the basic tab functions, but not much else
[13:04] cpmeister: oh...I just remembered, the new UI uses the character sheet as a main backdrop for the tabed information, I'm not sure what should be done about rendering the character previous for that
[13:04] cpmeister: *previous->preview
[13:05] [Arch_SB]thpr: I'm not sure what you mean by "not sure what should be done about rendering the character previous for that"
[13:06] cpmeister: from what I know, the rendering of the character sheet is done through xml files, so you might have to create new ones for the the mock
[13:07] [Arch_SB]thpr: So you're using the fancy red & yellow character sheet
[13:07] [Arch_SB]thpr: not the blue and white one
[13:08] cpmeister: thats not the issue, the ExportHandler can only handle PlayerCharacter objects, not PlayerCharacterFacade objects
[13:09] [Code_SB]james: We could always build one for transition purposes
[13:09] [Arch_SB]thpr: I think we'll have to
[13:10] [Code_SB]james: So a getPC mehtod on nthe facade that passes back a PlayerCharacter object purely for output purposes
[13:12] [Code_SB]james: I can handle that as part of the mock stuff
[13:12] cpmeister: k
[13:13] [Code_SB]james: Just to confirm though you are using the newer browser based preview rather than the older one with the tabs down the left hand side
[13:13] cpmeister: yes
[13:14] [Code_SB]james: The former is configurable while the second is hardcoded to 35e
[13:14] [Code_SB]james: Cool
[13:15] [Code_SB]james: ok, so #1 is largely done, leaving the way for #2 and #3. #3 is now creatijng mock objects to implement the pcgen.core.facade
[13:16] [Code_SB]james: I'll look over that on the weekend to get an idea of scale
[13:17] [Code_SB]james: afk for work issue
[13:19] [code]nuance: I'm going to mention this one lat time.
[13:23] [Code_SB]james: back, sort of
[13:23] [Code_SB]james: What's up Andrew?
[13:25] [code]nuance: I think the new char sheet has an off by one error somewhere
[13:26] [Code_SB]james: Yeah I recall you mentioned that
[13:26] *** [Admin]Drew has joined #pcgen.
[13:26] [Code_SB]james: Did a tracker get raised for that?
[13:26] [Code_SB]james: Oh hi Andrew!
[13:27] [Admin]Drew: Hi, don't mind me, just observing. :)
[13:27] [Code_SB]james: Andrew I'll note that one down to get dealt with - I may hassle you for an example character though :)
[13:28] [Code_SB]james: So, we should probably keep moving
[13:28] [Code_SB]james: 4. Other projects for the next release (yes that's a call for people's pet projects too)
[13:28] [Code_SB]james: So, basically what does the code team want to propose for the next release?
[13:28] [code]nuance: I keep mentioning it and peeps keep going "O rly?"
[13:32] [Code_SB]james: Some things that have been mentioned: UI, LST editors, CDOM, output engine replacement (Velocity/freemarker)
[13:32] [Code_SB]james: any others?
[13:34] [Code_SB]james: I'm assuming that Tom is focussed on CDOM and Connor on UI. Andrew anything you want to work on there or otherwise?
[13:38] [Code_SB]james: k, I'll take that as the main focus will be UI and CDOM, which admittedly is plenty to do. If anyone wants to add anything to that, just post to the dev list.
[13:39] [Code_SB]james: 5. Anything else anyone wants to raise
[13:40] [Code_SB]james: I'm assuming that everyone has raised what they want to at this stage
[13:40] [Code_SB]james: So unless there are objections I'll declare the meeting closed
[13:42] [Arch_SB]thpr: sounds good to me
[13:42] [code]nuance: I have an 18th level wizard, when I use the char sheet all the numbers of his charged items turn up on the wrong line
[13:43] *** [code]nuance has signed off IRC ("leaving").
[13:43] * [Code_SB]james bangs gavel