[Glade-devel] libglade usage

[james daa com au (James Henstridge)]

On 8/01/2004 10:13 PM, Damon Chaplin wrote:

> On Thu, 2004-01-08 at 03:41, James Henstridge wrote:
>
>  
>
> > Libglade's autoconnect function looks up function names in the global 
> > symbol table.  By default, functions in the main executable do not 
> > appear there, so would not normally be visible.
> >
> > The flags returned by "pkg-config --libs libglade-2.0" should include a 
> > linker flag to export the apps symbols for use by things like 
> > autoconnect() (for linux systems, the flag is -Wl,--export-dynamic).
> >    
>
> Is the autoconnect stuff known to work across all platforms now? I seem
> to remember it was uncertain initially.
> (I know we didn't use it in Evolution, but I can't remember why.)
>  
I don't know if it works on all platforms.  I know it works on a fair 
number of them though (possibly all the interesting unix platforms, 
even).  Python uses this same feature (exporting the main app's symbols) 
to handle extension modules, so if Python works on the system, libglade 
will probably do so as well.

The one system I am not sure about is Windows.  Shared libraries are 
handled quite differently there, so I don't know the answer (I am sure 
someone does though ...).

> If it is reliable, are the other glade_xml_connect_* functions really
> necessary any more? Why would you use them? I think this needs to be
> documented better.
>  
I know some people don't like the idea of libglade connecting up signals 
to arbitrary global functions in their apps.  I remember someone talking 
about loading semi-trusted .glade files off the network, and only 
wanting to allow connecting a small number of signal handlers.  Of 
course this use case isn't a very good one: loading untrusted data with 
libglade is a recipe for disaster -- libglade can instantiate arbitrary 
GObjects and set pretty much any property on those objects.

> I think Todd's problem is the common one where libglade has already
> shown the widget before the signal handlers are connected, so you never
> get the signal. The solution is to set the window's 'Visible' property
> to FALSE in glade, and call gtk_widget_show() on it after calling
> glade_xml_signal_autoconnect(). (But why not just call a function to
> initialize the window instead?)
>  
Yep, that is probably what his problem was.  Realize isn't really that 
great a hook for random initialisation though.  If you are using it for 
one-time initialisation tasks, then your assumptions might get broken 
once screen migration becomes popular (where the window is hidden and 
unrealized, set to use a different display and realized/shown again).

James.

-- 
Email: james daa com au
WWW:   http://www.daa.com.au/~james/