Dev Meeting Log 20140627

Developers Present:

Tom Parker (Arch SB)
James Dempsey (Code SB)
Connor Petty (Code UI specialist)
Andrew Maitland (Content Observer)

Discussion Summary:

Tom explained the Current Arch Demo's and ideas he had and how he wanted to implement the changes slowly (FACT/FACTSET/EQVar Demo/Freemarker Patch Demo)
James and Tom discussed Eclipse pushing Java 7 code into the programming, and will officially change to Java 7 6.5+
Connor explained the UI Facade and other layers to Tom

RAW LOG

[17:00] <Tom[Arch]> I think we'll wait a moment as James should be joining
[17:01] <Tom[Arch]> Connor have you looked at either the FACT proposal or looked at the EqVarDemo branch?
[17:01] <cpmeister> I have not looked at the fact proposal yet, but I did look at the EqVarDemo branch.
[17:03] <@AndrewAAM> http://wiki.pcgen.org/FACT_Token
[17:03] <@AndrewAAM> http://wiki.pcgen.org/FACTSET_Token
[17:03] <cpmeister> I can't say I know enough about what the EqVarDemo was trying to accomplish to give much of an opinion about it though.
[17:04] <@AndrewAAM> EQVar takes the formula system and allows you to use it in containers that don't interact with outside containers
[17:04] <Tom[Arch]> variables with namespaces, in effect
[17:04] <@AndrewAAM> That's the dirty summary, Tom can explain it better.
[17:04] <Tom[Arch]> where each piece of equipment ends up being a separate container/namespace
[17:05] <Tom[Arch]> I think we'll start and we can catch James up
[17:05] <cpmeister> fine with me
[17:06] <Tom[Arch]> So as context, we currently have the facades, which you (Connor) just moved to pcgen.facade, which interact with the UI and the core. There is some additional separation needed from the core, but that's the theory anyway
[17:06] <Tom[Arch]> Right now, we also have facades that have fixed methods, things like getLegs or whatever
[17:07] <Tom[Arch]> those are on the RaceFacade, et al
[17:07] *** James[Code_SB] has joined #pcgen
[17:07] <cpmeister> Hi James
[17:07] <Tom[Arch]> The challenge going forward is that the core is getting more and more generic
[17:07] <Tom[Arch]> Hi James
[17:07] <@AndrewAAM> (Hi James - Sent you the previous)
[17:08] <James[Code_SB]> Morning
[17:08] <Tom[Arch]> So - for example - the Deity's symbol will be something the core knows nothing about
[17:08] <Tom[Arch]> Right now it has a StringKey.HOLY_ITEM, but even that will go away
[17:08] <James[Code_SB]> Thanks for that
[17:08] <Tom[Arch]> as will the individual load token
[17:08] <Tom[Arch]> FACT will entirely hold the content
[17:09] <Tom[Arch]> So all the Core will know is that a Deity has a characterisitc called "Symbol" that is "Star" or whatever
[17:09] <Tom[Arch]> So eventually the facades need to be able to translate to the UI the appropriate items
[17:09] <Tom[Arch]> and I'd suggest that be in a way that keeps the facades reusable across game modes (so they think generically as well)
[17:09] <Tom[Arch]> Then only at the final UI (in whatever layer it is - we'll get to that later) knows it needs the "Symbol" Fact
[17:10] <Tom[Arch]> too high level or good enough?
[17:10] <Tom[Arch]> We can do a walkthrough if you would like
[17:10] <cpmeister> I'm understanding it so far.
[17:11] <James[Code_SB]> That makes sense to me
[17:11] <Tom[Arch]> So that handles things that are about an object. Symbol, Title, whatever. Things that don't change about an object
[17:11] <Tom[Arch]> Doesn't cover PC characteristics like Hands
[17:11] <Tom[Arch]> and obviously doesn't cover lists.... though there is a close cousin for that , FACTLIST
[17:11] <Tom[Arch]> ERrr FACTSET
[17:11] <Tom[Arch]> sorry
[17:12] <Tom[Arch]> Similar theory, but you get a Set of items back rather than one
[17:12] <Tom[Arch]> So things like components on a spell
[17:13] <Tom[Arch]> or descriptors on a spell
[17:13] <Tom[Arch]> would be FACTSET
[17:13] <Tom[Arch]> (note they can be objects not just strings in both FACT and FACTSET)
[17:13] <Tom[Arch]> There will be a "database" of sorts where you can go "ask" "What is a Symbol" and it will tell you String.class
[17:14] <Tom[Arch]> likely relevant for you (Connor) in terms of formatting
[17:14] <cpmeister> indeed
[17:15] <Tom[Arch]> I'm working on building a demo for FACT so folks can look at the code. I'm about half done
[17:15] <Tom[Arch]> That will facilitate seeing how it works in practice
[17:15] <Tom[Arch]> By the way, I'm expecting those to be 6.5
[17:15] <Tom[Arch]> So after we branch, I'd like to get them in relatively quick
[17:16] <Tom[Arch]> That being said, the transition gets tricky, and is part of why we are here
[17:16] <Tom[Arch]> let's use Deity's Symbol for a moment
[17:16] <Tom[Arch]> Right now, it's triggered by the SYMBOL token, and the UI eventually pulls (through the facade) StringKey.HOLY_ITEM
[17:16] <Tom[Arch]> (as to why the token and StringKey are mismatched - not sure)
[17:17] <Tom[Arch]> If we swap to FACT, we end up being in the position of needing to swap the UI
[17:17] <Tom[Arch]> but that leaves us in the risk mode of having to swap all the data at once OR having some mechanism for saying "old or new"
[17:18] <Tom[Arch]> given that swap all at once is effectively ripping out the token for all users, I think we need to at least consider having a control mechanism for pulling from both places
[17:18] <Tom[Arch]> that make sense to everyone?
[17:19] <cpmeister> So far yes, do the facts in any way interact with variables?
[17:20] <Tom[Arch]> immediately, no. Longer term, yes, but probably transparent to you
[17:20] <Tom[Arch]> Here would be one example:
[17:21] <Tom[Arch]> MODIFY:SomeVar|SOLVE|value()+if("Star"==fact(deity(),"Symbol"),1,0)
[17:21] <Tom[Arch]> Please note that is COMPLETELY contrived
[17:21] <Tom[Arch]> and I'm not sure we'd really do much that way
[17:21] <Tom[Arch]> but the point is that there will likely be some ability in a formula to test a fact
[17:23] <Tom[Arch]> good?
[17:23] <cpmeister> good
[17:23] <Tom[Arch]> ok
[17:23] <Tom[Arch]> So roughly the same challenge exists for Variables (either EqVars or global vars in the new variable system)
[17:24] <Tom[Arch]> Today we do CRITRANGE as a token, but that too can go away in favor of an EqMod
[17:24] <Tom[Arch]> so we end up with a variable CritRange that needs to be swapped into the UI (though this is likely an item just for Preview, thus you are insulated from it)
[17:24] <Tom[Arch]> But on a "global" basis, the issue would happen with LEGS for example
[17:25] <Tom[Arch]> going from fetching from the LegsFacet to having a variable "Legs"
[17:25] <Tom[Arch]> so we should also be trying to insulate from the facets as their structure/existence will change
[17:26] <Tom[Arch]> The next trick is a Var isn't only a Number.class
[17:26] <James[Code_SB]> critrange is definitely in the info for equipment and may be a column too so it is a good example
[17:26] <Tom[Arch]> ok
[17:26] <Tom[Arch]> we'll have to do the conversion very slowly to ensure both that
[17:27] <Tom[Arch]> a) We get a flag somewhere in the UI controls (per game mode)
[17:27] <Tom[Arch]> b) We can ensure we get the appropriate info to the data team as to what the calculation was in the code
[17:27] <Tom[Arch]> I've already stressed with Andrew this is going to have to be slow and steady, one at a time
[17:27] * @AndrewAAM waves
[17:27] <Tom[Arch]> If we try to rush this will be an epic train wreck
[17:28] <Tom[Arch]> ok, back to not only a number
[17:28] <Tom[Arch]> same rules as Fact, there is a database that can tell you what it is, so Legs would return Number.class
[17:29] <Tom[Arch]> Note we are using Number.class not Double or Float or Integer, as we do "arbitrary precision" arithmetic
[17:29] <Tom[Arch]> where "arbitrary" here means "Integer if we can"
[17:29] <Tom[Arch]> we dont' drop into BigDecimal or anything like that
[17:29] <Tom[Arch]> that way 2-1 is always 1 not .999999999
[17:30] <Tom[Arch]> So we can also do things like "Point" as a type. In the case of the EqVarDemo it's actually a custom class GridPoint
[17:30] <Tom[Arch]> it is used to store what is today FACE
[17:30] <Tom[Arch]> and that is actually "hard coded" in the token as a demo of both global variables in the new system as well as being able to modify a non-Number in the variable system
[17:31] <Tom[Arch]> There isn't any reason why a variable couldn't be a String as well if there is a character-wide item that we need as a single fact (*cough* Region *cough*)
[17:31] <Tom[Arch]> I shouldn't say fact
[17:31] <Tom[Arch]> too confusing
[17:31] <Tom[Arch]> Character wide characteristic
[17:32] <Tom[Arch]> any questions?
[17:33] <Tom[Arch]> seem fairly straightforward to deal with?
[17:33] <James[Code_SB]> I wouldn't go quite that far :)
[17:33] <Tom[Arch]> LOL
[17:34] <James[Code_SB]> I think you've noted some interesting challenges for the UI - this is really driving the move away from a d20 focussed UI, much as the output system is going the same way
[17:34] *** cpmeister has quit IRC: Changing host
[17:34] *** cpmeister has joined #pcgen
[17:34] <Tom[Arch]> it is
[17:35] <Tom[Arch]> but at the end of the day the UI still has a tie to the game mode
[17:35] <Tom[Arch]> so we may end up with panes being named and defined in the game mode or some such
[17:35] <James[Code_SB]> and it changes the 'perspective' of PCGen quite a lot - a good thing but a change in mind set
[17:35] <James[Code_SB]> indeed
[17:35] <Tom[Arch]> My big point here is hoping we make the facades generic and only have to work with the UI
[17:35] <James[Code_SB]> They are to a minor extent now, but I know the data team would like to have a lot more control
[17:35] <James[Code_SB]> right
[17:35] <Tom[Arch]> and at that, I think it will only be a portion of the UI
[17:36] <Tom[Arch]> but that's for Connor to explain more. (Hopefully we get to the UI layers today as well as I'd like to understand that)
[17:36] <James[Code_SB]> whereas now, the facades are where a lot of messy game knowledge lives
[17:36] <Tom[Arch]> yea, some of that we can clean up with this, some is harder
[17:37] <cpmeister> I think if we want to keep the facades intact in any reasonable way there might need to be different facade implementations for each game mode
[17:37] <Tom[Arch]> that's part of why I asked for a selection deep dive on user experience
[17:37] <Tom[Arch]> What would bind them to a game mode?
[17:38] <cpmeister> I imagine the end goal is for facts to become completely arbitrary but only consistent within game modes
[17:38] <Tom[Arch]> correct
[17:39] <cpmeister> So the facades implementations that depend on facts cannot be relied upon to work for all game modes
[17:39] <Tom[Arch]> It depends on the design
[17:39] <Tom[Arch]> Let's use Symbol as the example
[17:40] <Tom[Arch]> If you make DeityFacade have a getSymbol() then yes, you're stuck to the game mode
[17:40] <Tom[Arch]> I'm not sure that's how I would do it
[17:40] <Tom[Arch]> if you have public T getFact(String s, Class<T> cl)
[17:40] <Tom[Arch]> there is no tie to the game mode
[17:40] <Tom[Arch]> and the only tie is the place where the info is presented/what knows it is displaying a String (or whatever)
[17:41] <Tom[Arch]> it localizes the game mode knowledge
[17:41] <cpmeister> But there IS a tie to a fact name. :)
[17:41] <Tom[Arch]> eventually there HAS to be
[17:41] <Tom[Arch]> of course
[17:41] <Tom[Arch]> but I would put that in the code that constructs the UI
[17:41] <Tom[Arch]> since by its nature it has to be game mode specific already
[17:42] <Tom[Arch]> because you have to have a field to show it and set the field location et al
[17:42] <Tom[Arch]> might as well set the fact name there too
[17:43] <Tom[Arch]> Maybe this is a good point for you to explain the layers of the UI
[17:43] <Tom[Arch]> that way we all have that context
[17:43] <cpmeister> What purpose would the facade layer serve if the facades cannot be tied to the facts?
[17:44] <cpmeister> (I'll get to the UI layers in a moment)
[17:44] <Tom[Arch]> in the case of facts, very little
[17:44] <Tom[Arch]> in the case of vars, lists and other things, insulating you from facades
[17:44] <Tom[Arch]> Have you looked at the output demo I posted to JIRA?
[17:45] <cpmeister> Unfortunately no, I've been preoccupied with real life the past few weeks
[17:46] <Tom[Arch]> no problem. That may be an interesting thing to look at
[17:46] <cpmeister> Could you send me a link?
[17:46] <Tom[Arch]> http://jira.pcgen.org/browse/CODE-2619
[17:46] <Tom[Arch]> it's a very generic facade (bordering on a shim) between the core and FreeMarker
[17:47] <Tom[Arch]> I would view the UI facade acting in a similar way
[17:47] <Tom[Arch]> and the patch is no longer Java7 specific (thanks for pointing that out James, I completely missed that I used a J7 feature)
[17:48] <James[Code_SB]> Eclipse just quietly does it for you I've noticed recently
[17:48] <James[Code_SB]> and it is rather nice
[17:48] <Tom[Arch]> very convenient, we just eventually need to decide to drop J6 officially rather than do it accidentally
[17:49] <Tom[Arch]> but that's quite a tangent
[17:49] <Tom[Arch]> Perhaps time for UI layers? ... and you can look at the Output system later Connor. This was as much to be informative vs trying to settle everything in one shot
[17:49] <James[Code_SB]> Yeah I'd like 6.4 to be the last Java 6 compatible release - it is getting too hard to maintain compatibility now
[17:50] <cpmeister> sure thing Tom
[17:50] <cpmeister> Basically the UI is separated into a views and models
[17:51] <cpmeister> The views are the swing UI components that render to the screen and the models are the data that populates the components
[17:52] <cpmeister> I've maintained a strict separation between these two layers such that only the models handle CharacterFacade instances
[17:53] <cpmeister> Everytime a character is created and shown to the screen the UI models are created and listeners attached to the character
[17:54] <cpmeister> Each character has its own set of models and each model is explicitly installed and uninstalled from the views
[17:56] <cpmeister> (sorry, just a sec)
[17:59] <cpmeister> One advantage of explicitly installing and uninstalling models is that switching between character can be made very fast.
[18:00] <cpmeister> The UI currently switches models in tabs an arbitrary order to make tab switching appear faster
[18:01] <Tom[Arch]> below character model, how do things work for single objects like Deity or Race
[18:01] <Tom[Arch]> and how does it work for info on those things?
[18:02] <cpmeister> Could you clarify?
[18:02] <Tom[Arch]> Let's stay at Deity for a moment
[18:03] <Tom[Arch]> So CharacterFacade can give you...an ItemFacade or some such
[18:03] <Tom[Arch]> that is the model?
[18:03] <Tom[Arch]> ItemFacade<DeityFacade> specifically I think?
[18:03] <Tom[Arch]> (assuming I have the first class right)
[18:03] <James[Code_SB]> Two targets to consider here - the deity the character has selected and the list of all deities
[18:03] <Tom[Arch]> yes, I'm on the PC info at the moment
[18:04] <Tom[Arch]> the latter being game mode info, but yes, good point that there are two deity related items
[18:05] <James[Code_SB]> public ReferenceFacade<DeityFacade> getDeityRef()
[18:05] <Tom[Arch]> so ReferenceFacade not ItemFacade
[18:05] <James[Code_SB]> yep
[18:05] <Tom[Arch]> k ty
[18:05] <Tom[Arch]> but that is effectively a model?
[18:05] <James[Code_SB]> which allows the UI to be notified when it changes and not have to poll
[18:05] <Tom[Arch]> which is loaded into some view (field) somewhere presumably
[18:06] <Tom[Arch]> right, so the CharacterFacade owns it as writeable, and shares a readable version to the view
[18:06] <James[Code_SB]> yes
[18:06] <cpmeister> The models mearly serve as the adapter classes for the facades.
[18:07] <James[Code_SB]> Not sure I follow Connor
[18:07] <cpmeister> Most all of the model logic is delegated to the facade layer
[18:07] <Tom[Arch]> not sure I'm following
[18:07] <Tom[Arch]> is the ReferenceFacade a model in this case?
[18:07] <cpmeister> :/
[18:07] <cpmeister> referencefacade is part of the facade layer
[18:08] <cpmeister> The models attach listeners to the reference facades and propagate events to the views
[18:08] <Tom[Arch]> so in showing the actively selected deity by a PC what is the model
[18:09] <Tom[Arch]> looking at CharacterComboBoxModel
[18:09] <Tom[Arch]> (found one)
[18:09] <cpmeister> the model would listen to the ReferenceFacade<DeityFacade> and change the contents of the UI's diety field when an event occurs
[18:10] *** ckwalsh has quit IRC: Read error: Connection reset by peer
[18:11] <cpmeister> Since the views are event based, the only task the models have is to implement a swing model propogate events through the swing layer
[18:11] <cpmeister> *and propogate
[18:11] <Tom[Arch]> So because the view in this case is a picklist, we need to have a model that combines both the game mode info (all Deities) with the PC info (the ReferenceFacade we were talking about), so that is why the *facades shouldn't be models themselves
[18:11] <cpmeister> correct
[18:12] <Tom[Arch]> the referencefacade is the underlying container for the PC, which the model listens to et al to be event based and the view draws stuff
[18:12] <cpmeister> bingo
[18:12] <Tom[Arch]> model or facade owns sorting when you have a list?
[18:13] <cpmeister> the views own the sorting
[18:13] <cpmeister> sometimes we use a sorted list facade instead
[18:13] <cpmeister> it depends on the situation
[18:14] <cpmeister> when displaying a strict list of items, the sorting would occur in a delgating list facade.
[18:14] <Tom[Arch]> when you say view owns the sorting, does the view actually tell the model what to do and the model actually has the data?
[18:15] <Tom[Arch]> or does the model then tell the facade to sort as well?
[18:15] <Tom[Arch]> or does the view have a separate list from the model?
[18:15] <cpmeister> For tables, swing models are internally wrapped in another swing model so that sorting can be handled transparently to the original model
[18:16] <Tom[Arch]> so the facades and the model are both basically unaware of display
[18:16] <cpmeister> for tables yes
[18:16] <Tom[Arch]> meaning sorting of the display in this case
[18:16] <Tom[Arch]> for non-dynamic stuff like a picklist you would use the sorted facade?
[18:16] <cpmeister> yes
[18:16] <Tom[Arch]> ok
[18:17] <cpmeister> unless we display the picklist with a table, in which case no
[18:17] <cpmeister> though we could sort the data before handing it to the table but that becomes useless redundancy
[18:17] <Tom[Arch]> right, you'll display race different ways in two places since you have the picklist on the general screen which is controlled by a sorted list, but once in the table on the Race tab, the Race tab needs to dominate
[18:17] <Tom[Arch]> that's actually good because it keeps the picklist from having to fight with the Race Tab
[18:18] <cpmeister> making sense?
[18:18] <Tom[Arch]> yes
[18:19] <Tom[Arch]> so on the sorting discussion we had it's really tables where we can't (shouldn't) help
[18:19] <cpmeister> yes
[18:19] <Tom[Arch]> but the static lists are potentially reusable (give or take whether it makes sense to really share)
[18:20] <cpmeister> for the most part yes, but if the static list needs to be displayed outside of a table it will likely be wrapped in a sorting list facade by the model
[18:20] <Tom[Arch]> for now that's sensible - defensive programming and all that
[18:21] <Tom[Arch]> need a lot more polishing in many places to break that assumption
[18:21] <cpmeister> any other questions? I need to take off soon.
[18:22] <Tom[Arch]> I need to run as well, already 6 min past when I should have left :/
[18:22] <Tom[Arch]> I think I'm good for now
[18:22] <Tom[Arch]> thanks for the discussion
[18:22] <cpmeister> no problem :)
[18:23] <James[Code_SB]> Thanks have a good evening guys
[18:23] <Tom[Arch]> thanks all
[18:23] <cpmeister> have a nice day everyone!

END OF LOG

Dev Meeting Log 20140627

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Start

Teams

Community

Strategic Development

Misc

Tools