Hi Greg, Good job on your success!
Something to check into as you work on the problem: be sure that you're testing with enough events, spaced out temporally, that they are not all painted at once. This was something that caught me when testing autoWidth. -- The original-painter's paint function (line 62) only paints a subset of the events. So you need to test with an event set that requires multiple calls to the paint function. It only paints the events that are visible on the screen, see original-painter lines 89, 90 and then 99 where the painter iterates through the visible events from minDate to MaxDate (in reverse order). For an example of requiring multiple calls to painter, see example2 where I added additional events at the year 4400. With regard to integrating it: Depending on how many changes are needed, you may or may not need to create a new painter file. -- Try to localize where your changes are and fold them into the file. Comments are good. You can add a flag to the theme, perhaps something like layoutUsingOrder to theme.event.track. and theme.event.overviewTrack Some other thoughts from reading your message: You refer to the order of the events as they are in your xml file. But Timeline currently does not assign any meaning to the order of the events as they come in from the server. So rather than change that fundemental aspect of Timeline, I suggest that you instead add an optional event attribute "order" which your sw would use to order the layout of the events onto the band. You could write an iterator for your new order that line 99 would use instead of getEventReverseIterator. Then you would just have an if statement to use one instead of the other based on the theme. Another thing to check: you report that you painted the events "in order." But my experience in trying to use the EventIterator instead of EventReverseIterator was a failure. Something to check: try using events whose labels are longer than the event's tapes. In general, it is important to test with both instant and duration events and to test using all of the examples in http://simile-widgets.googlecode.com/svn/timeline/trunk/src/webapp/examples/index.html Also take time to test with IE7, Safari, and FF. All are available for Windows. If you usually use a Mac, find a PC for the IE7 test--it tends to turn up problems the other browsers don't. A comment on your email: The painter uses a function to iterate through the object (not clear how), painting tapes as it goes along. a) The paint function only iterates through the events that will be visible on the screen b) It iterates through them in chronological reverse order. Here's another thought: Maybe all you need to do is to change the reverseIterator to take into consideration an optional event attribute of "order" -- is it the case that the events start at the same time? Good luck on your sw. Note that I have added the event attribute trackNum to the trunk ver of Timeline. Your help in testing it would be appreciated. TrackNum (is supposed to) enable you to set the event's track num within the events file. You can also search the source for trackNum to see what you have to do to add a new event attribute. Regards, Larry ________________________________ From: greg <[EMAIL PROTECTED]> To: SIMILE Widgets <[email protected]> Sent: Monday, November 3, 2008 8:48:26 AM Subject: Re: Old style layout of events. Hi Larry: I believe I have found a solution for the top to bottom ordering problem. I was nosing around inside the "orignal-painter.js" file as well as the "sources.js" file and discovered how the events are extracted from the (in my case ) XML stream. It goes something like this: XML -> XML document -> Object containing event objects. The painter uses a function to iterate through the object (not clear how), painting tapes as it goes along. I noticed that the order in the event object collection is not that same as the order in the incoming XML stream (The order I wanted them in). I decided to use an array to store my events and then modified the painter to loop through the array. Since the array was in the order I wanted, the display is a thing of beauty! So essentially, the order is predefined on the server and the painter just does as it's told. I have been thinking of making this a fully integrated painter ("ordered-painter"). What do you think? Of course if that was to happen you (or someone else) would have to let me know how to do it while still maintaining the overall code structure. Thanks On Oct 30, 2:45 pm, LarryK <[EMAIL PROTECTED]> wrote: > 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/76... > > 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 -~----------~----~----~----~------~----~------~--~---
