Hello, 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 ? > > 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. I didn't exactly mean libglade itself but rather the user's created .glade file's result. See my next remark. >> 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. Thanks for this elaboration. However, this still doesn't prove, at compile time, that you have e.g. all necessary callbacks available to connect to... Whilst when you'd have generated code available and ready to be compiled, you could be (statically, I mean at compile time) reassured that your interface is valid, and that all necessary callback functions are available. Maybe I wasn't clear on this point. If you don't understand my point, let's drop this issue; I can still come back to this one later in a separate thread, eventually. > 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 I had seen this one. See next remark. > You should see the test-libglade.c example sitting in the libglade > tarball for a really quick example. Well that's what I meant. Maybe in the link above, it could be mentioned that this is an example of how to use libglade. It'd help out people (digging into the subject) to obtain an example more rapidly. > 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. That's a political discussion ;-) >> 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) ? > > ... > These are the docs to write a plugin to the Glade 3 core: > http://glade.gnome.org/docs/index.html I had seen this one, but here too I miss some practical examples. Are any available ? > Is there anywhere in particular you think it should be linked from ? What did you mean by this question ? I don't understand the question, actually... Your question is probably what I need a glade plugin for ? I need to write a glade add-on that would have custom properties (all of course based on GtkWidget's properties). Kind regards, PhB _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
