Re: Glade C code a bad thing? (was: root windows)

[Gus Koppel <gtk spamkiller bytechase cx>]

Maciej Katafiasz wrote:

> > > Unless by "build of glade" you mean autogenerated C code, which
> > > is bad, bad, bad thing to use. Use libglade, really.

> > why it is bad? I use it and it works just fine and I don't have
> > glade dependiencies.
 
> Because it makes it impossible to later rework UI without rewriting
> the code. In general, mixing autogenerated and hand-written code is
> always a bad idea, and that's exactly what is being done here.
> Besides, it hardcodes interface in code, which is also very bad thing.
> Fortunately, glade-3 won't support generating C, making it painfully
> obvious that libglade is the right thing.

Do all conceptual decisions by all developers make "painfully obvious"
that they are / were doing the right thing? If Glade 4 were to add
support for QT or MS-Windows resources or other nonsense, would it still
be "painfully obviously" the right thing?

Possibly contrary to you I've been using both ways, libglade and
hardcoded C source. After quite some time of performance drawbacks and
other quirks I returned to Glade C code and am very happy with it. I'm
co-working on a rather large Glade-based project, btw, with the .glade
file being > 1 MB in size. For performance reasons, such files are
inherently unsuitable for being accessed via libglade.

In contrast, we have never experienced any impossibilities of reworking
UIs. There is no more Glade-related code to rewrite (just custom handler
code) when using Glade C code than when using libglade. I also don't see
why mixing auto-generated code with hand-written code is "always a bad
idea" or hardcoded interface is "also very bad thing"? Imagine that a
hardcoded interface is actually exactly what some people (developers and
users) WANT to have, for several reasons! (Speed, size, GUI can't be
altered by unauthorized people, installations, easier to program, etc.)

See URL below for an extended discussion of why Glade generated C code
is actually preferrable, why its ceasing support is regrettable and will
certainly cause quite some professional developers to stick to Glade 2.

http://mail.gnome.org/archives/gtk-app-devel-list/2005-January/msg00227.html