Hello, Tristan Van Berkom wrote:
> Thats an interesting idea, I'm sure a simple program could be used > to parse signals in a glade file and ensure the availability of the > said callbacks in the binary - this kind of tool could be used in > makefiles to validate a built program, maybe we could take something > like this to intltool ? (you could bring this up on > glade-devel@ximian.com > if you want... there's propably a gnome intltools list too...) > Let me indeed do that. I wonder why nobody ever came up with the concern I have; am I that much of a security freak ? >>> 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. > > Some things are the way they are - and wont improve untill someone > who cares about those particular things sends a patch, I'm sure > James Henstrige wouldnt refuse that simple kind of patch... [EMAIL PROTECTED]:/usr/compils/glade3-3.0.1> find . -name test-libglade.c [EMAIL PROTECTED]:/usr/compils/glade3-3.0.1> It doesn't seem to be there ? >>> 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 ;-) > > Ugh - I give up here, I dont see why you are arguing that an > application distributor should support a situation where the > user tampered with the software (yes, the xml glade file that you > distributed with the app is "part of the software") - this is > not political at all. My reasoning is that if you inhibit the user the *possibility* to tamper with the files you deliver, you won't have to take this into account when providing support. Call me a security (effectiveniss ?) freak: the less tweaking that can be done, the less support one should provide. If you provide your compiled program as one whole (i.e. without a separate file called e.g. project.glade), then the question "Did you tamper with project.glade, sir ?" is a question you shouldn't even think of asking when supporting your end product. But it would surely have to be one of the *first* questions you'd be obliged to ask your customer when not linking everything statically (i.e. using libglade's autoconnect possibilities)... >>>> 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 ? > ... > You can look at the libgnomeui plugin included in the Glade 3 tarball. I suggest adding a link right after http://glade.gnome.org/docs/children.html , at the same indentation level, as an example of a glade plugin ? I find it rather difficult to get an insight into all internal glue magic. Libglade is difficult to start with, at least for gtk/glade/libglade newbies like me. I agree, calling "glade_xml_signal_autoconnect" does everything. But I want to understand more of it than just calling "glade_xml_signal_autoconnect". 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
