[Lumiera] [PATCH] Timeline Zoom Scale Control Widget

Ichthyostega prg at ichthyostega.de
Fri Oct 7 18:31:47 CEST 2011

> On Thu, Oct 6, 2011 at 9:44 PM, Ichthyostega <prg at ichthyostega.de 
> <mailto:prg at ichthyostega.de>> wrote:
>> As you've probably noticed, GUI development is somewhat stalled, since our 
>> dedicated "master of the GUI", Joel Holdsworth left. Thus, the GUI, as it 
>> stands now, is in no way finished; rather it's stalled in a state where it
>> was just about to be fleshed out in more detail.

Am 07.10.2011 16:58, schrieb Michael Fisher:
> Think Joel is ever coming back?  If not, he for sure left behind a very nice
> and intelligent gui framework to work with.

Well -- for the project it would be bliss if Joel were to join again.
But I rather don't hope it for Joel ;-)
The reason is, he left when he got a really nice but also challenging
full time job as a programmer, adequate to his skills.

>> Maybe we should consider to introduce some central entity, which mediates 
>> any zoom / scroll changes? What do you think?

> This idea is what I was thinking yes. Unless I'm wrong, in GTK+ and Gtkmm,
> adjustments can be shared by multiple widgets.  Maybe the central entity is
> nothing more than a simple adjustment object that gets referenced by the zoom
> slider?   If my thinking is correct, then any other widget that references a
> 'central' adjustment would get updated "on-the-fly" I guess.  Honestly, I'd
> have to try it out before really knowing if that would even work or not.

Yeah, that would be nice indeed. We'd just have to try it out.
Alternatively I'd suppose that it would be possible to wire several
Adjustment objects, as they each expose sigc++ signal slots.

> Also, sorry if my C++ terminology is off a bit.  I'm not used to having to
> deal with pointers, data typing, etc...

Don't hesitate to ask, really!
This stuff is nasty and involved and at times really tricky. We all have
only partially knowledge, so the best is always to ask and exchange our findings.

Since you're rather comming from dynamically typed languages, statical data
typing will for sure be somewhat a challenge at start. But, over time you'll
notice that it's actually an additional safety net provided by the compiler.

Which is really helpful, because the most significant challenge in C/C++
programming is that there is *no* safety net in the runtime. If you do
something silly, often there is no helpful error message, rather just a crash.

One thing really helpful when it comes to memory management are the "smart
pointers", especially the ref-counting shared_ptr type. You've certainly
noticed that at several instances being used within the GUI. These little
objects can be used like a bare pointer, but -- because of the reference count
-- they detect automatically when an object managed by smart_ptr is no longer
referenced, and then this object can be released automatically.

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.

> If so, then we could have something like
> TimlineZoomScale(Gtk::Adjustment> &adj) and ....

And here is the catch.
Of course, we could easily manage for this original Gtk::Adjustment to live
within the TimelineState. We'd just put it into the TimelineViewWindow, which
is owned by the current TimelineState. Actually, that would pretty much be
the most orthogonal and self evident way of doing it, for sure.
The TimelineViewWindow is kindof "the real thing". It has all relevant data,
i.e. the scroll start position and the zoom scale. And, what's important,
it uses real time units, not display coordinates. That's why IMHO all
conversions to display coordinates should be concentrated there.
Currently, they are a bit scattered throughout the code.

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.

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"?

Hermann V.

PS: usually it is way more convenient to discuss such details on IRC.
Unfortunately I'm quite overloaded with several projects, so I choose not
to hang out on IRC, it's just too much distraction.
But I'm happy to join IRC when we arrange for a discussion there.
Do you know our #lumeira channel on freenode.net?

More information about the Lumiera mailing list