--- Log opened Fri Sep 07 00:00:03 2012
00:52 < mcallan> n8 c, i'm off
01:16 < conseo> me, too
12:04 < conseo> mcallan: i have hacked something together which prints the bites in the talktrack. i have played around with different CellList<BiteJS> hacks, but GWT has hardcoded <div> for row rendering which gives a vertical layout.
12:05 < conseo> the Template class in CellList is private as is the static field TEMPLATE, so i cannot change the rendering easily that way. i might be able to hack div to show horizontally, but i thought it would be better to ask you how to approach the view
12:06 < conseo> you have done some quite impressive work with all the gwt code, i am still trying to catch up on how the ui roughly works
13:13 < conseo> it works with <div> and css: { position: relative; float: left }
13:30 < conseo> mcallan: which symbol should i use for the elements?
14:45 < mcallan> conseo: re symbol, i would use the simplest possible thing, and not spend *any* time making it pretty, not till i had a good mockup
14:45 < conseo> ok, i use braces for now
14:46 < mcallan> re layout, cell list sounds wrong ...
14:47 < mcallan> i would play with a simple html/css mockup page (layout only, not pretty stuff) to see what works best ...
14:49 < mcallan> sounds like all you want is something like <img/><img/><img/>.  the default css 'display' property of inline does all the work
14:51 < mcallan> (i never think in terms of gwt layout.  i always think of html, then i find the equiv in gwt)
14:53 < mcallan> (to prevent wrapping, you can use css white-space and overflow properties)
14:55 < mcallan> (it might not be possible to get it to grow from the right side with overflow going out the left side, unless you use new css3 styling.  the default flow is left to right, and it's nearly impossible to change in css2)
14:57 < conseo> ok
15:00 < conseo> celllist seemed appealing (from the model side), so we are mainly talking about the view, right?  because i still need access to the images when the list is updated (more bites fetched)
15:01 < conseo> or is this even too much abstraction for the view already?
15:02 < mcallan> you definitely need a good modeling under the view, and controllers too for things like selections.  that's not too much abstraction, it's essential.  if gwt has suitable contructs for model (or view), then it could save time to use them
15:03 < conseo> ok, good, because i am still new to ui stuff
15:04 < conseo> i have done a bit of qt layout coding and web pages, but nothing nearly as sophisticated as the VoteTrack layout coding
15:09 < mcallan> #1 is the mode/view architecture.  if you can stack two track views on stage sharing a single model, then the arch is good
15:10 < mcallan> #2 is event handling.  it's hard to code cleanly without extensive use of event/listener patterns
15:11 < mcallan> (i mean publish/subscribe patter)
15:21 < mcallan> conseo: maybe your track can live under s/gwt/stage/talk, "discussion related props for the stage"
15:24 < conseo> ok, set in package-info
15:24 < conseo> mcallan: ideally the feed and the track could share the model
15:25 < conseo> can they share their instance of the model or will i need to add a lot of eventhandlers then?
15:26 < conseo> (do you have a vnc client btw.?)
15:34 < conseo> mcallan: is a div element around the img a problem? can i access the img chield objects in a list way as well?
15:38 < mcallan> no vnc.  i think feed as such has no future (any more than maps), so i would not attempt to integrate it
15:39 < mcallan> why u need vnc?
15:40 < mcallan> i said <img/>, but if you use char symbols (for now) they would be <span>.  same layout behaviour...
15:41 < mcallan> so typically <div> <img/> <img/> ... </div> right?
15:42 < mcallan> that's the view, in a nutshell
15:49 < conseo> ok, so i have to reimplement CellList to use <img> tags
15:50 < conseo> i don't need vnc, it would just allow to quickly share a problem
15:54 < mcallan> if CellList is appropriate view (not sure) except that it hard codes each cell as div, then change 'display' property of div to 'inline'.  it will then layout as span and take any inline content, including img or char
15:55 < mcallan> also google: horizontal CellList
15:56 < mcallan> with 'inline' display, it will flow left to right (or right to left, if you can figure out how to do that with css3)
15:59 < conseo> i have searched for horizontal celllist, but looking at celllist's code, i have found out that it hardcodes div. searching has told me to use css: float: left;
16:01 < conseo> we want it to float from right to left, newest on the left side?
16:04 < mcallan> (newest on right, right?  that's how typical time series goes, when you write it on paper) float sounds wrong.  float is too extreme, and its not meant for that.  if display inline fails, then i would forget about CellList
16:11 < mcallan> if CellList won't work as view, then its model (ListDataProvider) might still be useful, not sure.  gwt does not generally have solid gui constructs.  nothing like a proper toolkit has
16:14 < mcallan> (hardest part is to push the overflow to the left, instead of right.  so you narrow the window, and the left part is clipped)
16:21 < mcallan> conseo: maybe best to plan on throwing the first one away.  so code a prototype strictly for test purposes (extremely simple and ugly).  list the biggest risks/problems in order (model/view communications, layout, etc.), and test each with the prototype...
16:22 < mcallan> then throw it away and code the real thing.  expect to put major time into it.  it's difficult work
16:23 < conseo> ok
16:23 < mcallan> (is CellList appropriate?  your prototype will tell you)
16:23 < conseo> i'll have a look...
16:25 < mcallan> (for example: communications with server is not a risk/problem.  so don't code it.  save time.  just use fake data for the proto)
16:26 < conseo> mcallan: display: inline on the div element works
16:27 < conseo> mcallan: sure, i have just reused diff-feed code to get a quick playground around the track framework
16:28 < conseo> so maybe celllist will do, this now depends how to float out on the left as you describe
16:30 < conseo> another question is if feed and track are supposed to be synced, or is this a minor thing we can integrate later? or is the feed "asleep" atm. waiting further use cases?
16:30 < conseo> waiting for
16:31 < mcallan> feed is asleep, along with maps (votespace, geospace).  i would keep it running at least until talk track works, and longer if it poses no big problems.  but i would not put time into it
16:35 < conseo> this is how it looks atm. btw. https://oc.polyc0l0r.net/public.php?service=files&token=52daccb3b8be12fa796929e52bf1ca33bef49000&file=/talktrack-proto1.jpg
16:36 < conseo> ok
16:46 < mcallan> looks good
17:29 < conseo> mcallan: is it reasonable to remove items from the model if the view overfloats? (and keep the list of all bites in a separate storage)
17:34 < mcallan> no, model must be independent of view.  might have any number of views.  css overflow is prob what u want for view
17:34 < conseo> ok
18:43 < conseo> mcallan: looks like this is a css blind spot. there seems to be no easy way to control the "overflow" direction. still searching...
18:50 < mcallan> moz- had something for layout direction, but it might not be css3 (i might be wrong about that)
18:55 < conseo> i am just looking into that
20:11 < conseo> mcallan: maybe an absurd idea, but can svg handle something like that as aligning?
21:17 < mcallan> yes, because it does no layout.  you have to draw everything yourself.  but it might be a mistake to use svg just for that reason.  it's harder to work with, slower to render, and also less stable across browsers
21:34 < conseo> ok
22:07 < conseo> mcallan: css overflow clipping only works in the contra-direction of the css float value (at least in firefox). i'll try to figure out more
--- Log closed Sat Sep 08 00:00:20 2012