Re: [DEVEL] Accessibility for BonoboControls

[Bill Haneman <Bill Haneman sun com>]

Hi Michael:

Thanks for the reply.  I, too am juggling a couple of things at the 
moment.

I will try to clarify a couple of points...

>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 :-)

What I mean was, call bonobo_object_query_interface() on the remote 
object (which can be gotten from the control).  The optimization is not 
a performance optimization, but a simplification for the benefit of the 
client.

>        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 ?

There is always an accessibility interface (or, rather, it is always 
available "on demand").  There is a whole factory pattern thing going on 
behind the scenes, but probably there is not point is going into that 
here.

>        I have only really 2 goals:
>
>        * Not depending on at-spi
>        * Not requiring code changes for things to be accessible.

I am not sure we can achieve both to 100%.  But I think we can minimize 
the problem.

We can return opaque accessibles from bonobo-control, just as you could 
use a known interface (like query_interface) to get instances of 
hitherto unknown objects.

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

I think you have a better idea of how to achieve this.  We could have 
the call to bonobo_control_get_accessible () dynamically load libspi, 
the point is that once such a request is made there is no escaping the 
dependancy on libspi (or at least, the idl in at-spi).  I think we 
probably should split libspi into client and server bits anyhow (at the 
moment stubs and skels are all linked together in one .so).

>        Either way - I propose we add:
>
>        interface Control {
>                ...
>                Unknown getAccessible ();
>        };
>
>        If this is what you anticipate needing ? 

Yep, that sounds good.

>is it not neccessary for
>a symetric arrangement with a getAccessible on the parent as well ? or
>have I lost it ?

Maybe, I am not sure what you mean by the last question :-)
The accessibility interfaces define API for getParent, getChild, etc.  
So once you have the control's accessible you can get the 'parent' 
(which would be the container housing the bonobo-socket, not the socket 
itself).

>> 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 ?

Sounds like you'd rather add a single method of API to bonobo-control 
rather than introduce the dependancy.  Fine by me, I think that's better 
too.  So replace the above with:

  Bonobo_Control control =
      bonobo_control_frame_get_control (control_frame);
 
  Accessibility_Accessible accessible =
      bonobo_control_get_accessible (control);

[this is called in a 'bridging' module that does have to know
 about both libspi and bonobo-control]

When such a call is made, if the accessibility module is not yet 
initialized/loaded, the control does so, then instantiates and 
aggregates an accessible via that module:

  Accessible accessible = accessible_new (
                   gtk_widget_get_accessible (
                        bonobo_control_get_widget (control)));
                        
  bonobo_object_add_interface (bonobo_object (object), accessible);

and returns an Unknown to the original caller:

  return bonobo_object_get_corba_objref (bonobo_object (accessible));

>> 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.

I mean, the 'outermost' GtkWidget in the control's process space.

>> (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.

Yes, or maybe someone will explain to me how the new dynamic module 
stuff works and we can figure out something else, that allows us to 
distinguish between "application" Gtk+ clients and "embedded" clients.

>> (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.

Yep.  Basically we have to be able to call 'getParent'/'getChild' in a 
Gtk widget's process space, for the internal ATK implementation.  In the 
case of bonobo sockets and plugs we end up doing a weird thing, creating 
an 'in-process' proxy that wraps our bonobo IPC.  This is only used for 
doing internal bookeeping things in ATK, for instance finding out what a 
widget's "siblings" are, in order to establish relationship flags.  We 
want this to work for out-of-process embedded widgets as well as for 
in-process ones.

>>     [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 :-)

Tsk tsk.  ;-)  It would be a very easy thing to replace 
"guint" for wid and the API call reference to X11 with "GdkNativeWindow" 
and "bonobo_control_native_from_window_id (GdkNativeWindow id)" - then 
we could leave the not-so-easy stuff for later.

(The accessibility work may in fact present a practical case where we 
have incentive to port bonobo to non-X platforms.)  I don't see any
theoretical issues that would prevent it.  And I assume you mean
BonoboControl - the plain Bonobo code (other than some activation
stuff that gets stored on the root window) should be cross-platform,
no?

Regards,

-Bill

>>     (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
>
>
>_______________________________________________
>gnome-components-list mailing list
>gnome-components-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-components-list

------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland