[prev in list] [next in list] [prev in thread] [next in thread]
List: gnome-components
Subject: GTK_MODULE (G)Option breakage & init ordering ...
From: michael meeks <michael.meeks () novell ! com>
Date: 2006-02-07 11:36:05
Message-ID: 1139312165.17637.12.camel () linux ! site
[Download RAW message or body]
Hi there,
So - I've been chasing a rather interesting bug:
"GNOME hangs on login with a11y enabled"
Of course - clobbering the proximate cause: gnome-session activating
vino-server synchronously works around this nicely; but there is a
deeper problem:
When bonobo-activation-server spawns a process; it requires that
process to send back to the parent an IOR reference on a given
file-descriptor - specified in the arguments. If this is not found, the
server registers another way [ as if it were run by hand ]. So - far so
good.
Like other libraries - bonobo has a double-init guard; so these
arguments need to get to the 1st 'bonobo_init' call; otherwise we
potentially never get the --oaf-ior-fd=NN argument, and bad things
happen[1].
So - in the 'bad old days' (gtk-2.4) - this worked beautifully. When
you enable a11y you do:
export GTK_MODULES=gail:atk-bridge
The arguments passed to gtk_init got dupped, and subsequently passed to
gtk_module_init and onwards to libbonobo & the registration all passed
away nicely.
Unfortunately - the introduction of GOption clobbered all GtkModule
argument passing; and ensures that no GtkModule gets anything but a
0/NULL argc/argv cf.
gtkmain.c (do_post_parse_initialization)
Also - I see no mechanism for allowing modules to register their own
arguments [ though presumably that'd be fairly easy with the new
GOptions framework ]. So; that can't be used to fix this either :-)
So ... in the absence of any blindingly brilliant solutions, or
suggestions, or corrections :-) there are 2-3 possible solutions:
* every app need retro-fitting to reflect the underlying
functionality change: to call bonobo_init before
gtk_init [urgh - very sub-optimal].
* add more code to libbonobo to try to 'do better' on
a 2nd init with more argument data - ie. re-parse the
relevant arguments.
* we have to propagate the pipe name / argument to the
child process via a (presumably reliable) environment
variable instead of an argument.
I guess we'll need one or other of the latter two; perhaps the argument
re-parsing on 2nd init. Either way: Bill - I'm slightly amazed we havn't
seen this before - whatsup there ? :-)
HTH,
Michael.
[1] - like b-a-s potentially never returning a status for previous
activations on the stack, or the app itself.
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
gnome-components-list mailing list
gnome-components-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-components-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic