GTK_MODULE (G)Option breakage & init ordering ...

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.
-- 
 [email protected]  <><, Pseudo Engineer, itinerant idiot