Re: Glade GUI: changing mechanism
- From: Philippe Bertin <philippe bertin telenet be>
- To: Tristan Van Berkom <tvb gnome org>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: Glade GUI: changing mechanism
- Date: Mon, 23 Oct 2006 08:40:54 +0200
Tristan Van Berkom wrote:
You're right in some sense. Still, how can one statically prove that the
created .glade file is *statically* correct ? I mean by this, how can
the (no longer existing, no longer statically compiled) program be
proven it would link statically ? I have the impression the user
interface is kind of linked-in dynamically, at runtime, having libglade
dynamically parsing the .glade file ?
Why would someone want to go from
glade file --> generated code --> GUI
when you can simply go from
glade file --> GUI
with much less code-generators & generated code to maintain ?
There's another recent thread on this newslist from a certain leoo. Well
I think his problematic program compiles but doesn't work because all
callbacks (specified in his .glade file) aren't available in his
program. Using code generation I could exclude such a suspiction, for
Maybe it's just the libglade doumentation which is not clear enough on
this issue (or I haven't found it in the last 2 days I've been actively
trying to figure out libglade usage examples ?). Would there be any good
documentation one could consult on this issue(s) ?
That being said - I think that distributing the glade file seperately is
a cleaner design, as it allows not only users but also developers to
the UI without recompiling (allowing for some magic at the packaging
level), also - typicly apps are installed by a super-user into a
prefix, generally the glade file - being part of the program's
files is not user writable.
If shit can happen, it will. In other words: if users can mess up, they
will. Even root users aren't safe from trying to tamper with fiiles,
even when told not to do so (provided they have read the README
What I mean by this is that I would feel a lot more comfortable to have
my program be confirmed to link and run. In other words : those
code-generating glade plugins which used to exist must still be around
somewhere. Where are these to be found ? Provided people are no longer
feeling being forced to have to use them (call me an exception ;) still
these plugins must be around somewhere. Where could these eventually be
found ? I think it is unwise (please do not take this personally, it is
far from being meant personally) to force users into the direct GUI ->
glade file concept. The former plugins should, to my feeling, be
continued to be put available (as a libglade submodule, or give it
another name, that's a detail). So that one can generate oneself the
code an prove a .glade file to conceptually work... statically.
Apart from that, I also fail to find documentation on another aspect of
using glade and libglade : what is the API to provide to write a glade
plugin (e.g. to be able to create custom widgets with glade) ?
I fear I sound like a libglade critics. I myself don't feel like that
(apart from a 'positive' libglade critics) : on the contrary, I am
enthousiasted by the concept. But I do have some questions, which can to
my feeling all be answered by a good documentation set, which I fail to
find easily (enough)...
] [Thread Prev