Re: [DEVEL] Accessibility for BonoboControls

[Michael Meeks <michael ximian com>]

Hi Bill,

On Fri, 21 Sep 2001, Bill Haneman wrote:
> In view of the looming 'platform alpha' API milestone for Gnome-2 I
> have been reviewing what seems to be required for accessibility of
> bonobo controls.

        That's great - sorry for the delay in replying.

> I suggest that a BonoboControlFrame, when queried, should return the
> embedded BonoboControl's accessible.  (It could return its *own*
> accessible which exposes the BonoboControl's accessible as its only
> child, but this would appear to add very little value).

        Yes.

> The query could be done via bonobo_object_query_interface ()

        It is not possible/sensible to aggregate a remote interface
against against a local object; ie. there is no

bonobo_object_add_interface (BonoboObject *obj, Bonobo_Unknown remote);

        So we can't have the ControlFrame do this without a proxy - which
defeats the point of the optimization really :-)

        Better to have a method to get the remote accessible directly I
think.

> BonoboObject *bonobo_control_get_accessible (control);
>
> which would instantiate (and aggregate) the accessible interface
> object only on-demand.

        Hmm - what mechanism is Gtk+ providing to allow you to
non-intrisively add accessibility interfaces where neccessary ?

        I have only really 2 goals:

        * Not depending on at-spi
        * Not requiring code changes for things to be accessible.

        Can we provide loadable module hooks in some way ? so that the
accessibility interfaces can be aggregated automaticaly ?

        Either way - I propose we add:

        interface Control {
                ...
                Unknown getAccessible ();
        };

        If this is what you anticipate needing ? is it not neccessary for
a symetric arrangement with a getAccessible on the parent as well ? or
have I lost it ?

> In the first case we would have:
>
> Bonobo_Control control =
>     bonobo_control_frame_get_control (control_frame);
>
> Accessibility_Accessible accessible =
>     bonobo_object_query_interface(bonobo_object(control_frame),
>                                 "IDL:Accessibility/Accessible:1.0");

        Aggregating makes lots of sense inside the control's process.

> This will work IFF every bonobo_control does:
>
> bonobo_object_add_interface (bonobo_object (object),
>            accessible_new (
>                   gtk_widget_get_accessible (
>                           bonobo_control_get_widget (control))));

        What is the implication of this ? having libbonoboui depend on
at-spi ? or libspi ? - this seems not a particularly pleasant prospect to
me off hand; can we not provide a hook here ?

> Please have a glance at my implementation notes below, I am optimistic
> so far that we can implement this using existing API (with the single
> addition to BonoboControl mentioned above, but I certainly may have
> missed something.

        Ok - I'll beg a few questions here:

> In short, supporting accessibility for BonoboControls requires that:
>
> (a) a bonobo control has API for getting its toplevel GtkWidget; [met]

        Toplevel ? what do you mean ? the toplevel all the way up the
hierarchy of frames that the control may be buried in ? ie. the GtkWindow
parent ? or the top of that Control's widget hierarchy ? We can only get
the X id of the true toplevel.

> (g) bonobo controls that are in a separate process space must not
> register as separate apps with the Accessibility_Registry (thus they
> behave differently from other Gtk toolkit clients). [met if bonobo
> control factories ignore GTK_MODULES ?]

        Any environment variables will be inherited via.
bonobo-activation-server; so it rather depends on how the activation
server is activated I think. Possibly we could persuade Maciej to clobber
GTK_MODULES somehow though.

> (h) bonobo controls must be able to
>     use a similar, complementary means of returning their enclosing
>     frame when Accessibility_Accessible_getParent (accessible) is
>     called.
>       [bonobo_control_get_control_frame (control) or
>        bonobo_control_get_remote_ui_container()]

        Not quite sure what this is all about frankly; but if you say so.

>     Fortunately this usually only happens across one level of
> hierarchy, it is not a frequent occurrence that an AtkObject calls a
> method on its parent or child AtkObject.  However it needs to be
> possible even if it is not terribly efficient.  It also means that
> GtkPlug and GtkSocket need a means of getting to the bonobo controls
> they embed/frame.

        If you look at BonoboPlug / Socket - we have a wrapper around the
plug / socket that allows us to get (at least) the socket CORBA reference
from the widget.

>     [can do this via:
>      bonobo_control_x11_from_window_id (wid) in conjunction with
>      bonobo_control_get_control_frame (control),
>      gtk_plug_get_id (plug), and
>      gtk_socket_get_id (socket);

        Not convinced about the above - then again, perhaps I've
misunderstood the intent.

>      Michael: We probably want platform-neutral API for the first
> bonobo call above, to wrap the X-implemented stuff.]

        Oh - bonobo will only work under X - and I've not seen anyone even
thinking of porting it elsewhere really :-)

>     (The dependencies on bonobo should be restricted to libgail, not
> exposed in Gtk, of course). [implementable with current codebase, we
> think.]

        How does that sound overall ?

        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot