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
-~----------~----~----~----~------~----~------~--~---
