On Sun, 2008-08-31 at 15:08 +0300, Sami Liedes wrote: > On Sun, Aug 31, 2008 at 09:12:34AM +0200, Josselin Mouette wrote: > > I’m pretty sure many of the list are in similar cases. Now loading the > > UI directly into the application is the standard, but not so long ago > > people generated template code with glade and then edited it by hand. > > The .glade file was removed simply because it has become irrelevant. > > Ok, my bad then. I admit I'm not too familiar with glade, although I > did know that the newest glade does not generate source code (but what > argument is that, this code was obviously generated with glade, the > existence of the newer version wouldn't magically make this the > preferred form of modification, would it!?). Of course it does! Once the functionality is dropped, there is no way to continue working on the project without editing the C files. Developers cannot continue using the old version of glade (it doesn't support some of the stuff that you can do with glade). You are confusing the two elements of Glade (v2) and the main functionality retained in Glade v3. Glade is about creating an interface (as an XML file, not C). Glade v2 allowed that interface to be easily converted into C code but could not cope with any manual alterations to the C code - once you started editing support.c, interface.c, callbacks.c etc., you were on your own. (Trust me, it was nearly always better if you did edit the C files too.) If you tried to re-generate, you lost all your own changes. Not good. Gladev3 takes a more sensible approach - you create whatever C files you need (no longer confined to particular file names) and load the Glade XML file with a library call. Or, if you want an interface in C or you don't want to depend on libglade, use Glade to get an idea of what kind of interface might work and then code that in C yourself. I didn't like this at first - it seemed to add more burden to the C programming - but I view it differently now. The generated code is quite awful to review later and makes project management a lot harder in the long term. Short term convenience causing long term logjam. > Although I do wonder, since this seems to mean that the interfaces are > (or at least seem to me) quite immutable. Sorry, that is just tosh. If you want to load the glade file via Glade, you keep the XML, depend on libglade and call libglade at runtime. If you designed the interface in Gladev2, you have the option to use the existing C files to continue improving the interface and you don't have to package the Glade file or depend on libglade. Yes, it might look like more work than editing stuff in the GUI or in the XML but in the long term it is the only sane option. To the point that I've virtually stopped working on any other projects that tried to generate C code, after working through the Glade migration. There are downsides to generating C code - bloat for one. > It has a number of functions like create_window() and > create_options_win() which still at least look quite repulsive for any > attempts to make any real or substantive edits to the interface. WTF? It's actually fairly good code in most cases. One of the ideas behind generating code is that you gain from the experience of others and avoid common pitfalls. The limitation is that the generated C code is too generalised which can be wasteful. > For example, the variable declarations in those functions: > create_window() has 541 local variables named like pixmap57, hbox419, > label547, hseparator49, frame 384. create_options_win() has 496. The > code (4710 lines in case of create_window()) doesn't look much more > editable either. That is the choice of the developers - if the developer is lazy and designs in glade rather quickly, the number suffixes remain but glade does/did allow developers to choose more sensible names, if the developer takes the time to edit the properties of the widget. > But I do trust you when you say that the "do not edit" note is > obsolete, I just wonder since after a cursory inspection this code > definitely doesn't look like anything I would want to touch to edit a > complex UI :) Of course if they are edited anyway, that might make > them the preferred form of modification. That is something for upstream to review and, from personal experience, I can say that, at some point, upstream will be *forced* to review all that code and redesign it - when we get Gtk3 if not before. Projects where the original Glade design was lazy or rushed will find it hard to port the old generated C code but that is their choice and their problem. Like it or not, those rushed C files are the only modifiable form of the source code that are available for usage. Either edit those files or remove them and replace the entire interface with one entirely done in glade and then depend on libglade with no generated C code. It is also possible for projects using libglade to still define some widgets or windows in various C files but that is probably not ideal. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part