Re: [gtkmm] Talk about a major rewrite

[Paul Davis <pbd op net>]

>Yes but where can you use that widget? Only in a Container. Now you 
>implement it again if you need it in a TreeView or Canvas. The way you 
>draw it also has to be redone, twice for a Canvas and again if you want 
>it to be printed.

an excellent point. i didn't quite grasp what you meant before about 7
renderers, but now i do.

>Furthermore, how are you implementing the contents of your widget? 
>Perhaps you use a DrawingArea and draw each of the little pieces, then 
>you have to re-create all the geometry layout, event and focus 
>management systems to deal with your sub-widget objects. If you try to 
>use full Widgets as your pieces you find the Widget class is far too 
>limited in its layout and rendering model. Note that this difficulty is 
>why widgets such as TreeView and Canvas had to be created, without 
>support for embedding Widgets.

right. thats why these days i tend to think in terms of the Canvas for
pretty much anything. it doesn't solve all these problems, but it
gives me incredibly fine control over rendering along with alpha
transparency and affine transformations that make GtkDrawingArea look
like, well, a baby's toy :)

  [ stuff about event-driven GUI programming ]

>All good points, and I'm not at all trivializing the effort to design a 
>good interface for human interaction. But I would call this interface 
>design, and my problems seem to come during the more mundane 
>implementation of the GUI design that I create on paper.
>
>There may be higher level kits that can help the UI design phase 
>someday. The more GUI programs I write and use, the more I see common 
>patterns being used, regardless of the underlying objects and their 
>features. Something that exposed user-level objects through a GUI using 
>standard techniques could be developed, though I don't have the clarity 
>yet to do it. Then we could concentrate more on our application-specific 
>feature objects, and less on re-creating common object<->GUI 
>interactions each time. The IBM book "Designing for the User with OVID: 
>Bridging User Interface Design and Software Engineering" seems to be 
>about such ideas, though I haven't read it yet.

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.)

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.

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.

--p