Re: [gtkmm] Talk about a major rewrite

[Paul Davis <pbd op net>]

>I'll probably regret this, but... I think the GTK design is a piece of 
>crap (though I usually try to be more diplomatic), and I am using gtkmm. 
>The problem with the "leave" suggestion is, where do we go? 
>Unfortunately there really is no good answer, and this is why these 
>debates/flamewars come up from time to time over the years.

I am entirely sympathetic to this point of view. I agree with you that
there is no obvious place to go to.

>Maybe I'm just being too picky, and I am picky when it comes to 
>programming, but it is striking to me that I don't feel this almost 
>constant frustration with any other library that I regularly use, such 
>as the C++ standard library, Unix networking functions, 3D scene graph 
>libraries, OpenGL, sound libraries, POSIX threads, etc. In all other 
>cases I can (eventually) perceive an underlying concept behind the 
>design, appreciate the designer's work and implement my program using 
>their library. With gtk I am mostly cursing the simplistic design and 
>trying to find workarounds to do what I want.

Agreed. My only additional comment is that I think its possible to
misperceive how much time you spend doing this. When I actually read
the code for the gtkmm GUI for ardour, i am amazed at how much of it
was just completely simple to implement. yet i remember all the
stupidities, all the problems much more clearly than the smooth sailing.

>to write a custom gtk widget and then realize you have to implement 
>about 5 different versions with 7 different renderers to actually use it 
>throughout your gtk program, etc etc. Perhaps Gtk 3.0 will surprise me 

this has not been my experience at all. i've written several custom
widgets, and while its painful, its not because of what you
describe. its more the need to write boilerplate code that as a C++
programmer, i am used to having done for me by the compiler. writing
custom widgets in gtkmm directly, for example, is an exercise in
simplicity. or so i've found ...

>with a complete redesign of the widget class hierarchy. But as that is 
>what it would take, a simple implementation patch to gtk won't help.

what i *hope* will happen by GTK+ 3 is that all widgets will render to
a canvas. this will provide not only alpha transparency, but will
unify the wonders of the canvas widget with the rest of the GTK+
widget set - they are currently very incompatible. writing new canvas
items is a breeze compared to a new widget, mostly because of the
rendering model.

>something better to emulate. I don't know. But I do know that there is 
>nothing fundamental about a graphical user interface that should make it 
>so much more difficult to implement than the other parts of the program, 
>and in 10 years we will be using the model that provides this ease.

i would offer one possible reason why its so hard. the GUI is the one
part of the program that interacts directly with the user in an
intentionally open-ended and fluid way. the difference between
writing, a cmdline driven program and a GUI equivalent (even just a
wrapper for a cmdline program) reveals many conceptual differences
that need to be handled by the programmer in some way, and that were
just not there before. what if the user clicks on this then that
instead of that then this? what if the user pastes into the text entry
field? what if she wants to drag-n-drop a file? how to provide more
information without more on-screen widgets? how to provide finer
control over some parameter without a new widget? what about different
mouse buttons? should i grab the pointer - an important new concept
that if done in the cmdline world (grabbing the keyboard driver and
preventing any and all other interactions) would be quite unusual
... etc. etc.

the event-driven nature of GUI toolkits requires a totally different
program organization when compared with most other program designs. it
means that the program doesn't control the program, so to speak. take
a look at apache: although its quite complex code, at any point in
time, the program is 100% in charge of what is going on. with a GUI
(even a curses-based one to some extent) this is no longer true. the
same comparison is true of linux - despite interrupts and other deeply
wierd h/w stuff, the kernel always control "what happens next".

i believe that this difference makes GUI programming conceptually
different from many other kinds of programming. it may be that a
certain toolkit design can help. i haven't seen one yet.

--p