Re: libglade vs glade for dialog generation

[Michael Torrie <torriem chem byu edu>]

On Sun, 2005-01-23 at 12:50 +0100, Gus Koppel wrote:
> I don't see how using Glade code requires you to keep states in global
> variables, while libglade doesn't? If you refer to globally storing the
> values of input widgets in dialogs, i.e. values of a number of
> GtkEntries, there isn't really a difference between Glade code and
> libglade, is it? You should store values in both cases in external
> (optionally globally accessable) data structs when the dialogs are
> closed, shouldn't you?

I believe what he means is that since glade-produced code is not derived
from the GtkWidget class, but is instead simply a set of functions that
create the GUI and then disassociated callbacks to handle events, any
state-keeping code would have to be outside this and since it we are
dealing with flat, static callbacks, such variables would have to be by
definition global.  Compare this to libglade where each dialog box or
window you create is actually a true object (derived from GtkWidget)
which means you can, in glade, define member variables for things like
state.  You can also define new signals that your new object can emit.
This can be very powerful.  For example, you could create a dialog box
in libglade that presents some kind of message and asks for some kind of
input (say a set of radio buttons plus okay or cancel).  Then instead of
having a global callback to handle each button and the radio buttons,
you have a class callbacks to get the info, and then the callbacks for
the buttons take thehttp://www.gtk.org/~otaylor/gtk/tutorial/
information, close the dialog box, and emit a custom signal indicating
the radio buttons status to whomever created and displayed the dialog
box.  This example is pretty poor, but it is all I can think of at the
moment.

Essentially libglade promotes good object-oriented design (and hence
code and object reuse) whereas glade-produced code is not object-
oriented at all and is limited in its complexity.  This is not to say
that someone couldn't write a program to emit good OOP code from glade.
It's just that it is not worth the effort.

> I don't understand what you mean by "native object"? When I call
> create_mw_window () I get a native GTK object (GtkWidget) as well. I
> program GTK+ in its native language, btw, which is C. Sounds like you
> use something different, possibly C++? Although I haven't spend any time
> exploring GTK+ programming in C++ yet (in fact, not having to use C++ as
> in QT is one of the advantages of GTK+ to me), I think there should be
> ways to C++-objectify the result of a Glade-coded create_...() as well?

Don't let the fact that GTK is written in C fool you.  GTK+ is a full
object-oriented framework with real OOP semantics including classes,
inheritance and polymorphism.  Because we're using C, there is no
syntactic sugar to make this happen, so it takes a bit more work.  But
it really is object-oriented.  The core GTK+ object system is referred
to as gobject and you can find more documentation on this concept at
http://www.gtk.org/~otaylor/gtk/tutorial/

The difference here is that libglade produces a set of structures and
methods inheriting directly from GtkWidget, whereas your glade-generated
code is merely a set of functions that instantiate (but not bind
together) a group of GtkWidgets.  In libglade, if you create a window,
that window inherits from GtkWindow (thus it is a window), and then adds
all of the window's widgets as members of this new class.  This gives
inherent structure to your gui and allows you to find things inside of
your callbacks.  In glade-generated code, every time you want to refer
to another widget, you have to look it up in the global widget
hierarchy.  Inside of a class callback, you merely refer to the other
widgets by pointers stored as class members.  This is my understanding
anyway.  The exact methods you would use I am probably wrong about.

As for GTK+ using C++, since GTK+ is already object-oriented, it works
*extremely* well in C++.  I use the GTKMM bindings.  C++ hides some of
the extra work needed to work with gobject code, but it actually works
out to about the same thing in the end.  GTK+ in C# or Java is also
pretty slick.  If it wasn't for the amount of busy coding needed to
implement the gobject system for abitrary non-GTK use in straight C, I'd
use gobject for many things in C other than GUIs.  Apparently there is
an object creator preprocessor that can convert pseudo-object-oriented C
definitions of objects into gobject-based C code.

Hope this helps.

Michael

> Why should I start generating them in code if Glade can do the same for
> me already? If you are to create 10 similar GtkTextEntries in a row, you
> could certainly code something like:
>
> for (c = 1; c <= 10; c++) {
>     widget = create_text_entry_and_stuff ();
>     connect_all_signals_and_stuff (widget);
>     add_text_entry_to_dialog_container_and_stuff (widget); }
>
> While certainly being shorter than 10 widgets being created by plain
> Glade code, it's not faster but actually (marginally) slower. If the
> layout of the dialog is more diversified (which in our case it is), like
> GtkEntries, GtkCombos, GtkToggleButtons, GtkTreeViess, GtkFrames and
> such mixed together in several GtkVBoxes, GtkHBoxes, GtkTables,
> GtkVPanes and GtkHPanes in a (seemingly) random pattern, there is
> actually no room for loop-based widget creation optimizations like the
> above example. Again, this mixture sounds worse than it actually looks.
> But without being able to design the GUI on a WYSIWYG basis in Glade I
> would be lost often, indeed.
>
> Except for rather simple dialogs with maybe one or two GtkTables or
> Gtk[VH]Boxes and a limited number of input widgets, I don't consider
> coding (layouting, actually) without Glade feasible. For rather complex
> dialog designs, with 50+ widgets in various container structures in it,
> which are required by our work, I think Glade is essential to create the
> most convenient layout and keep a good overview.
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
-- 
Michael Torrie <torriem chem byu edu>