Hi Greg, I think I wasn't clear...
I think your proposal for how to layout the event is a good one. I'd like to accomplish it automatically, with high performance and low resource (memory) usage.... The problem is a) I don't know how to do it b) David H's work on this issue indicates that it is a tough nut to crack See David's reply on this thread: http://groups.google.com/group/simile-widgets/browse_thread/thread/76d0e3469d6b7858/9072e4e6d0755348? So the choices I see are: a) My forthcoming event track attribute may help for some use cases b) You could write sw that automatically sets the track attribute of events c) You could write a new event painter with the layout heuristics that you prefer. Regards, Larry On Oct 27, 1:18 pm, greg <[EMAIL PROTECTED]> wrote: > Hey Larry: > > I use an XML event generator that reads event data from a database on > the server and transmits it to the client for Timeline to digest. It > seems to me that it would be simple to just render(paint) events as > they are presented from the server. On the server I can write my DB > queries to return the event data in any order I wish. In fact, I most > often return the event data chronologically from earliest to latest > (crude example to follow:) > > ------------event1 > ------------------event2 > --------------------------------event3 > > where event3 occurs after event2 which occurs after event1. What > displays on the screen is more like: > > -------------event1 --------------------------------event3 > -----------------event2 > > I agree with the notion that the temporal relationships are the same, > my guess is that people tend to read from left to right and top to > bottom which would be mush easier in the first example. > > Thanks for your consideration in this matter. > > greg > > On Oct 24, 12:42 pm, Larry Kluger <[EMAIL PROTECTED]> wrote: > > > Hi Greg and G F, > > > Re: optional explicit (manual) track choice for an event: yes, this is > > agreed. I think there is an rfe (Request for Enhancement) filed for it. > > I'll be in that section of the code relatively soon and will add it. > > > Re: changing the automatic layout to have (in general) earlier events at > > the top (Timeline v1 layout heuristic). As has been discussed in prior > > emails, the automatic layout is a tricky (difficult) problem. David H has > > re-worked it several times. For example, one goal is to NOT have to scan > > all of the events on the fly when determing the layout of event n. It may > > be best for you to experiment with different layout strategies yourself. > > For example, your Timelines may have relatively few events. The feeling > > that I got from David H's post on the subject was a performance issue for > > Timelines with larger number of events. Given the choices, I'd rather have > > the stock Timeline be focused on performance. (You can see David's messages > > on the subject in the group's archive.) > > > Another issue for the Timeline source base is that it does not have a > > server component--every time a Timeline is displayed, it has to > > re-calculate everything. For example, you could write a nifty layout > > function that requires multiple passes through the event collection and is > > relatively slow. The "nifty layout function" would not be a good choice to > > run on the browser since it would need to be run every time the Timeline > > page is loaded. But it would be fine to run it on the server once per event > > collection. You'd then store the carefully computed track number with the > > events. That way, loading the event collection would be speedy and you'd > > get the benefits of the nifty layout too. > > > You could also design a hybrid solution where your layout function would > > run on the browser, but would automatically update the server's event data > > to cache the computed track numbers. > > > A key method is > > Timeline.OriginalEventPainter.prototype._findFreeTrack > > > Currently it does not take the current event as an arg, only the event's > > rightEdge. When I add optional explicit layout, I will add the current > > event as an additional arg. That way, you'll be able to experiment with > > different layout strategies by over-writing the method and returning > > which-ever track number you think is best for each event being painted. > > > I notice that events are currently painted in order from latest event to > > first event. Obviously, iterating in reverse order was an explicit decision > > by David H. My guess is that it worked better with left-to-right languages. > > (Due to label layout issues.) If you want to experment, see line 90 of > > original-painter.js > > > Something related that I have found: currently the painter does not provide > > any margin for an event when painting it. That is, the exact right edge of > > an event is used, rather than right edge + margin. This can lead to two > > events' labels being very close together depending on the timing of the > > events, length of the labels and resolution of the band. > > > ==> Has anyone else seen this on their Timelines? > > > I think it can be fixed through css by adding right-margin to the label and > > tape divs. I think this issue would be specific to different event > > collections. -- I would not change the defaults. > > > Thoughts, comments? > > > Regards, > > > Larry > > > ----- Original Message ---- > > From: greg <[EMAIL PROTECTED]> > > To: SIMILE Widgets <[email protected]> > > Sent: Friday, October 24, 2008 10:23:34 AM > > Subject: Re: Old style layout of events. > > > Hey g f: > > > Sorry no fix here just a show of support because I too would like to > > place the events in some order vertically. Maybe a sequence number as > > an event parameter. The horizontal ordering,however , should be > > strictly by time as it is now. > > > On Oct 24, 8:52 am, "g f" <[EMAIL PROTECTED]> wrote: > > > Hello all, > > > I wanted to have my events layout the way they used to layout, left to > > > right, top to bottom. > > > Is this something I can address by modifying the current code or do will I > > > have to use version 1 code? > > > Thanks! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en -~----------~----~----~----~------~----~------~--~---
