[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 25+2 packages with (Glade) generated C source files without the source

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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: