Re: How do you develop you GTK code?

[Tristan Van Berkom <tvb gnome org>]

On Tue, 2007-04-17 at 19:07 +0200, David Nečas (Yeti) wrote:
> On Tue, Apr 17, 2007 at 10:42:08AM -0400, Tristan Van Berkom wrote:
> > 
> > If your program is a long term investment and undergoes frequent
> > refactoring, then do it now :) you will significantly improve your
> > code's legibility, reduce lots of code and as such; add value
> > to your product, this is not just my pointed opinion - libglade
> > reduces complexity from your code
> 
> It redistributes complexity to other places and to relations
> between the code and the other places, if that is what you
> mean by `reducing complexity from your code', however it
> does not reduce the total.  The typical recommended use
> scatters strongly coupled information to distant places,
> destroys modularity and discourages refactoring into
> functional (reusable) units such as custom widgets and other
> classes. If the interface changes dynamically and/or it
> reflects some data structures (unknown at compile time),
> adding libglade into that is just a recipe for headache.
> 

Haha I never heard that one before, you must have had some
kind of bad experience, I will explain a little further down
what I mean by "reducing complexity"...

> > the fact that you can later dynamically change
> > your UI using a designer tool without editing your source code is
> > only added sugar.
> 
> Whether this is a featue or bug is yet to be determined.

Well people have been using it in practice for over 5 years,
i'd say that as its becomming more and more of a preference to
have this behaviour, its definitly proven not to do any harm
to distribute a dynamic UI, if it poses security threats (doubtfull),
then the paranoid can always compile the glade file into thier
program as a string constant. 

So its definitly not a bug, but I wouldnt call it a requirement, the
abstraction is definitly a requirement - not the dynamic part (although
that may have even become a requirement to some).

> > Consider that adding a user visible feature to your
> > program will become a matter of:
> >    a.) Adding a control widget to your GUI with a designer tool and then
> >    b.) Adding a callback function that will interface with your core
> >        application code to perform a task, maybe also 
> >    c.) Fetching a widget pointer from the libglade built hierarchy to
> >        provide the user with feedback from the core. 
> 
> The code representing the dynamics of the user interface
> forms the bulk of the code, accounts for almost all the
> complexity and often shares bits with construction code.
> If simplifying construction -- the easy and straightforward
> part -- radically simplifies your program, your program is
> most likely Hello world.

Not a chance dude, if you are writing hello word, xcalc
or any random peice of junk, you hardly need to implement a level
of abstraction to get rid of all the bloat that is a handcrafted
UI, but when your application starts to mesure hundreds of thousands
of lines then you better brace yourself - if you can mangle out
all the crap that touches your UI by hand then more power to you.

> c) in its typical use is global variables in disguise (a
> flat pool with everything).

Well look at the devhelp sources for a simple example of
what I'd call good use of libglade, any widget pointers
that are needed for a given module are stored at that module's
initialization process using glade_xml_get_widget() before
discarding the GladeXML, you only store pointers that are
needed on a structure that is only relevent to that module
(or that UI interface to a core module or what have you).

FYI, I have been using glade a long time before I was ever
writing code for glade - we maintain an embedded jukebox
system where the UI component (mesuring ~3000 lines of code
without any UI construction code thank god, just IPC and 
library calls wherever needed and all driven by an FSM engine) 
is 100% dynamic and "gladable". Before we had the goodness of gtk+
and libglade we were running a modified DOS kernel and had
our own UI description files and "in house" toolkit - I had to 
hand edit that description file and test it line by line to 
make sure I didnt leave any untracable mistakes, there was 
no designer tool, but at least we didnt have to hand code it.

Think about it, with a gstreamer pipeline leading into a real
time audio sound server (jack) over USB (quite experimental),
a database of songs/artists/bookkeeping/statistics, a self updating
software system & database over a secure network/telecom system, data
mining and survey fluff systems to manage - not to mention the whole OS
to fine tune and maintain (kind of like LFS or gentoo), device drivers
for peripherals such as coin acceptors, an IPC to hold it all together -
you think we could afford to mangle all the UI construction code into
our system ? just imagine the cost !

Heres a screenshot of what the current interfaces look like
using gtk+-2.0 and glade3:
http://www.gnome.org/~tvb/glade-tt-screenies/glade3-drag-anim1.jpg

Heres a screenie of what it looks like using the original
libglade with gtk+-1.3 and original glade tool (was developed
about 3 or 4 years ago):
http://www.gtk.org/success/touchtunes.png

Like I said before - if your application is not significantly big -
then you might not need the abstraction of libglade - but
eventually things get out of hand and you have to put your
foot down :)

Cheers,
                     -Tristan