[Lumiera] [PATCH] Timeline Zoom Scale Control Widget

Michael Fisher mfisher31 at gmail.com
Sat Oct 8 00:57:23 CEST 2011

> Which somewhat brings me to the main problem I see with this zoom handling.
> It's the TimelineState, which can be switched.
> This shared Zoom state (which we both seem to agree on) somehow needs to
> be connected with the TimelineState. Thus, when you switch to another
> sequence
> with the sequence chooser, all of the presentation parameters of the
> timeline,
> view, including the zoom, need to switch on-the-fly.
> Yep

>  That's why IMHO all
> conversions to display coordinates should be concentrated there.
> Currently, they are a bit scattered throughout the code.
> http://issues.lumiera.org/ticket/795

I noticed actually.  I can definitely be helping out in this area.

> Yet still the problem is: if we hand in a reference to a specific
> Gtk::Adjustment instance into the ctor of TimelineZoomScale, this reference
> can't be rebound. And when the TimelineState is switched, the original
> reference
> would just continue to point "somewhere", i.e. continuing to use it this
> way
> would lead to memory corruption.
> Rather, we'd need to use a smart-ptr<TimelineViewWindow>. And additionally,
> we
> need to get the TimelineZoomScale to be notified from the TimelineState
> switch.
> I.e. we need to connect it to some signal slot, which gets invoked when the
> switch happens, and in the handler then TimelineZoomScale would reset its
> smart-ptr to point to the changed TimelineViewWindow.

A little confusing for me maybe.  Do you mean the TimelineZoomScale holds
smart_ptr<TimelineViewWindow> ?
I'll follow the concept, just having a hard time visualising it.  I'll go
through and have a look at the code to see
what is currently happening during a sequence switch.  I'll be able to have
better responses.

> And, in order to make this happen, we need to refactor and re-arrange the
> objects a bit, because the design seems to be not optimal for handling that
> concern. The relation of, and the dedicated roles of the TimelinePanel vs.
> the
> TimelineWidget seems to be not entirely clear and orthogonal. Who of these
> two objects is the "Master" and in control, and which one is the "slave"?
I was actually trying to figure that one out while writing the ZoomScale
widget. ;) Shooting from the hip,
I'd have to say it 'looks like' the TimelinePanel is the Master since it
holds a pointer to TimelineWidget.
But then again, the TimelineWidget is probably acting according to the state
of the Timeline Panel.
Could be wrong there.  Again here, I need to get a full understanding of
what's already happening from top
to bottom in the timeline before I can provide a good response.  Getting

But I'm happy to join IRC when we arrange for a discussion there.
> Do you know our #lumeira channel on freenode.net?
Absolutely, been hangin' around on #lumiera since I began working with the
code.  Normally I'll be on as 'mfisher31' but sometimes 'axetota' (xchat
likes to reset my settings for whatever reason)

> _______________________________________________
> Lumiera mailing list
> Lumiera at lists.lumiera.org
> http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
> http://lumiera.org/donations.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lumiera.org/pipermail/lumiera/attachments/20111007/20fec589/attachment.html>

More information about the Lumiera mailing list