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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
