Re: libglade vs glade for dialog generation

[Gus Koppel <gtk spamkiller bytechase cx>]

Roger Leigh wrote:

> > As I mentioned earlier, you don't need to look at the Glade-created
> > code ever, except if you want to learn from it. You must not modify
> > interface.c on your own, anyway. Just treat interface.c the same way
> > as likely any source file from any other library you use: don't care
> > about its contents, just utilize its results.
>
> Sure, but if you work this way, you end up with a big homogenous blob
> of code plus a stack of callback functions.  My biggest problem with
> this is that there's very little structure to the code (you snipped
> this in your reply).  You get no code reuse and you can usually only
> instantiate one copy of the interface due to having to keep a lot of
> state in global variables.

If you don't care about the contents of interface.c, as you're supposed
to, there's no caring about little structure in it as well.

I don't understand what you mean by "only instantiate one copy of the
interface" and "no code reuse"? You can create as many instances of
interface items, i.e. dialogs, as you want, i.e. my_window1 =
create_my_window (); my_window2 = create_my_window (), etc.

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?

> libglade does not in itself solve any of these problems, but it does,
> if you permit it, allow one to root the widget tree in a
> GtkWidget-derived object, and then use that as you would any "native"
> GtkWidget.  You now have a native object which you can instantiate
> multiple instances of, derive from, emit signals from etc..  You now
> have decent object-oriented code instead of a big list of callbacks.

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?

> > Just think about a number of forms with combinations of i.e. 200
> > text entries, comboboxes, radiobuttons and checkmarks in them.
> > Several variations of those forms with totally individual widget
> > layout variants exist. This sounds worse than it looks, if properly
> > designed, but can quickly grow a Glade XML file beyond the 1 MB
> > border.
>
> At that point, I'd personally start generating them in code, since
> both the Glade interface and the Glade-generated code will be bigger
> and slower at this point.

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.