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 > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Michael Torrie <[EMAIL PROTECTED]> _______________________________________________ gtk-app-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
