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