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

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to