Re: Glade GUI: changing mechanism

[Philippe Bertin <philippe bertin telenet be>]

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

me linuxmax:/usr/compils/glade3-3.0.1> find . -name test-libglade.c
me linuxmax:/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