Re: [gtkmm] Talk about a major rewrite

[Michael Babcock <mbabcock la creatureshop henson com>]

Paul Davis wrote:
[snip]
> well, i also see common sets of problems arising, but for me they
> mostly come from a willful avoidance of deeply designing a toolkit
> around MVC principles. my code typically has at least two ways to
> control the model (MIDI data from audio/MIDI control surfaces, and the
> GUI), and the model also has lots of state that frequently prevents
> certain controls from being effective. i have to work like crazy to
> get a non-MVC toolkit to work right for me. things like stopping
> buttons from changing their visual state just because they were
> clicked. things like dealing with floating point roundoff causing the
> apparent state of a GtkAdjustment not matching the double value in the
> model, thus causing deeply nested sets of model->view->model
> communication. even fresco doesn't handle this well, though its a bit
> better in some areas than many. i have yet to see a toolkit that
> really takes MVC seriously - that considers user events as mere
> requests, mere initiations of possible change, rather than things with
> pretty-much-given conclusions ("the button becomes selected"; "the
> item is highlighted" etc.)

If I understand you correctly, I think I've run into similar issues, and 
my GUI classes are cluttered with ugly boolean flags like 
in_changed_handler_ that I test to avoid redundancy or infinite loops. 
Even though my models check for actual change before emiting 
notification on setters, with rounding errors I can get into  loops 
between model/view updates. Also sometimes the model is on another 
machine over the network with other clients updating it too so I can get 
into ugly timing race conditions or "loops around the whole network".

> however, i wasn't really talking about getting things right for the
> *user*. what i meant was that the event-driven model (as opposed to
> the imperative one) makes life for us as programmers much harder. you
> can no longer think in terms of a single, continuous thread of control
> throughout the program - instead, i find myself visualizing lots of
> small circular code pathways (event handlers) that originate in and
> then lead back the dark core of the main event loop. throw in some
> additional threads, and all of a sudden, the functional style i learnt
> when i started programming no longer really has anything to teach me,
> or any metaphors or analogs to help me think about what i'm doing.

However can't we think of the main event loop as simply reading events 
one at a time and calling functions to process them? Isn't this 
analogous to reading bytes from stdin and processing them until EOF? I 
guess it doesn't seem that dark to me. I agree that with threads it's a 
whole different game. I've just recently started using threads for a 
project and it does dramatically complicate things, so I sympathize there.


> no thread library, no socket programming API, no WWW-parsing library
> can help with this dilemma. but neither can a toolkit, at least not by
> itself. what a toolkit can do is not waste my time on its internals,
> and the lack of MVC in GTK+ and just about everything else really does
> that a great deal. most common GTK+ call in my gtkmm software:
>
>      gtk_signal_emit_stop_by_name()
>
> :) fortunately, gtkmm2 (and GTK+ 2) should change all that nonsense.

I've heard of this but never used it. Is it an alternative to the ugly 
flag approach I mentioned above? Could you please elaborate on how you 
use it and how gtkmm2 will help? Thanks.


--
Michael Babcock
Jim Henson's Creature Shop