[Glade-devel] libglade usage
James Henstridge
james@daa.com.au
Fri, 09 Jan 2004 15:08:17 +0800
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/