A few outstanding issues with ATK API

[Bill Haneman <bill haneman ireland sun com>]

Hi:

There are a few issues, some along the lines of "do we really need
this", that Owen raised to do with ATK.

(1)

atk_editable_text_set_attributes(AtkText *text, 
                                 gint start, 
                                 gint end, 
                                 PangoAttrList *attributes);

OK, Java AccessibleText has this feature.  We know PangoAttrList is
not supported by all the widgets that implement AtkEditableTextIface,
so there would have to be some transcoding/adapting of attributes. 
That's messy but feasible.

Not every editable text widget supports attributes at this time.  No
problem, if attributes are not supported there is no case for setting
them ;-)

Pango attributes are maybe the wrong choice.  GtkTextBuffer seems to
use things called TextTags, if I understand it correctly.

My gut feeling is that this will be implementable on GtkTextView (via
the GtkTextBuffer) but Owen asked (in effect) the question "shouldn't
this be done via the application UI?".  

So:  how do ATs use this feature in Java today (if they do), or
how/when do they use similar functionality in other environments?

(2)

AtkImage question...

There is at the moment a atk_imate_get_storage_type(...) method.  At
the moment it seems to indicate the internal storage type (GtkObject
type) of the image data.  I am not sure that is important... however I
can see a use for "image format" info here, for instance in an
AtkObject container that has HTML content in it, an image in the page
would have an AtkImage implementor that had actions on it (save image,
etc., right?) and a user might want to have content-type information
about that image.  If the user agent doesn't expose this in an
accessible way via UI elements, then it would be good to provide this
info for AtkImage instances.  Just a thought.  Otherwise it's not
clear to me that this method is needed.

I think the overall issue of how AtkImage would work in a web browser
is worth thinking about a little.

(3)

The factory registry implementation:  at the moment when
AtkObjectFactory factory types are associated with AtkObject
implementing classes, we are storing the GType of the factory.  Owen
suggested that this could be a problem for language bindings, since he
says some language bindings would not always return a unique GType for
each factory "type".  I don't know enough about the language binding
implementations to understand this, but I am concerned that if we has
factory instances themselves, we will have to instantiate a lot of
factories (all possible ones, I'm afraid) even if only one or two are
used.  Are there really such good arguments for not storing GTypes in
our factory registry?  Comments please.  My vote is for keeping some
kind of lazy instantiation - can we find a workaround for the language
binding issue here?  I really don't think we want to store
"customized" instances of factory classes, if a factory needs to do
anything special I think we should use inheritance (with the exception
of the trivial operation of setting ATK_ROLE on a widget-type basis,
as Marc and I have discussed).

(4)

Should we move get_caret_offset from AtkText to AtkEditableText?  In
other words, will we ever want immutable text objects with carets? 
(of course not insertion carets :-)

There are a few more, will post separately,

regards,

Bill

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