Re: Glade GUI: changing mechanism

[Tristan Van Berkom <tvb gnome org>]

Philippe Bertin wrote:
> Hello, Tristan,
>
> Tristan Van Berkom wrote:
>
> > 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 ?
> 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 ?

libglade is a portion of code, it exists in the form of a library
and can be linked to staticly or dynamicly, what libglade does
is simple - it creates a widget heirarchy prorgressively whilst
parsing a glade file.

> 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 
> instance.

libglade uses dlopen/dlsym to access symbols in the program's global
namespace (actually indirectly via GModule), when you lookup symbols
in a namespace:
 a.) you need to have those symbols exposed globally in your program text
 b.) you need to compile those symbols so that they export using the
   -Wl,--export-dynamic linker flags

If you find anything weird about "b", think of it this way - if you
were developing a plugin, the entrypoints of that plugin have to be
visible to the app that loads it, so they also must be exposed in the
same way - its just a really basic requirement to be able to load
addresses for signal callbacks in a generic way from a parser.

> 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) ?

This is the second google hit for 'libglade', you should try
the "GladeXML" section (which is the one that concerns you)
   http://developer.gnome.org/doc/API/libglade/libglade.html

You should see the test-libglade.c example sitting in the libglade
tarball for a really quick example.

> > 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 
> > update
> > the UI without recompiling (allowing for some magic at the packaging
> > level), also - typicly apps are installed by a super-user into a 
> > read-only
> > prefix, generally the glade file - being part of the program's 
> > distributed
> > 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 
> altogether)...

Sure, people can modify fstab & inittab and the computor just
wont run anymore - would you consider that a valid bug report
if one of your users told you they were unable to use your
program after removing the "/" entry of /etc/fstab ?

I think we need a little more trust on this front, if the user
is tampering with the system, its not a valid bug report/use case.

> 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.

Sure code generators exist, people can use glade files to do what
they desire - if that desire be to generate code - since we're on the
topic today, my only question to them is: why ?

If its only ease developer's fear of change, is it worth throwing
volunteer developer hours at ? (then again - a developer might write
such a code generator purely out of thier own interest).

Ok actually admittedly - some projects have opted for code generation
use because of optimization reasons; it takes less time to create a
GUI when you dont need to parse an XML (using libglade)... people
concerned by this should look into the gtk builder effort [1], if
we all screw are heads on correctly - we should have this in gtk+ 2.12.

Note that one of these companies was considering; instead of a
code generator - a binary file generator/binary reader that basicly
is a libglade equivalent in a more compact/optimized version.

> 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)...

These are the docs to write a plugin to the Glade 3 core:
    http://glade.gnome.org/docs/index.html

Is there anywhere in particular you think it should be linked from ?

Cheers,
                  -Tristan

[1]: http://bugzilla.gnome.org/show_bug.cgi?id=172535