Re: [g-a-devel] Exposing document selection

[Bill Haneman <Bill Haneman Sun COM>]

Willie Walker wrote:
> Hi Aaron:
>
> On Tue, 2006-10-03 at 10:52 -0400, Aaron Leventhal wrote:
>   
> > Here is the current plan for exposing selection in documents -- please 
> > let me know if there is a better way:
> >
> > 1. Any object which has any part in the document selection will have 
> > STATE_SELECTED, which will allow the collection interface to be used to 
> > get all the currently selected nodes.
> >     
>
> STATE_SELECTED is usually reserved for objects such as interactive lists
> that let their children be selected (versus a portion of their text).  
>
> The use of STATE_SELECTED for this purpose, however, seems to work well
> if only to use the collection interface to provide a semi-efficient
> means to find all objects that have something selected, whether it is
> text or children.  I'm confused, however, about what happens when both
> types of selection are intended.  My guess about what to do here is in
> the next section...
>
>   

As Will says, STATE_SELECTED usually has different semantics, and is 
reserved for selection of children in list or container-like objects.  
STATE_SELECTED should never appear on objects which are not children of 
objects which implement AtkSelection.

Please do not conflate these two different meanings of the word 
"selected" - as you can see, these two meanings are represented in ATK 
by two different interfaces : AtkSelection, for containers, and 'Text 
Selection' which is exposed in AtkText as AtkText:getSelections etc.

Clients wishing to know the currently selected text should do so this way:

1) selection of text, and/or changes to text selection, must result in 
selection-changed events from ATK.
2) clients know from these events what the AtkText object currently 
undergoing a change in selection is (there may be an open bug about this)
3) clients use FLOWS_FROM and FLOWS_TO relations to consolidate the 
entire text selection, if it spans multiple AtkText objects.

Note that the mozilla "embedded object" convention which you are 
promoting ensures that selections in mozilla can span objects which do 
not themselves implement AtkText; this conveniently allows for selection 
of inline images or hypertext links without the use of AtkSelection.

Collection isn't really required for this.  If for some reason we feel 
it is vital to use Collection in this way, then "selected" should be a 
semantic text attribute (exposed via AtkTextAttribute), we should not 
use ATK_STATE_SELECTED for this.

Since there seems to have been some confusion about this despite the 
current docs, I will amend ATK_STATE_SELECTED to make clear that it does 
NOT apply to text selection (and point to 
atk_text_get_n_selections/atk_text_get_selection instead.)

Best regards,

Bill
> > 2. We will use the AccessibleText interface to expose selection via 
> > getNSelections and getSelection for each container in the document which 
> > has text. The document itself is currently also one such container, 
> > which supports AccessibleText.
> >     
>
> This is workable.  What happens in the case of things like list items in
> an interactive list, though?  That is, how does one represent that they
> are both selected as in the "I want this list item" means and that their
> text is part of a selection?
>
> I guess what one needs to do is look to the parent's Accessible
> Selection interface to see if it is SELECTED because of the Selection
> interface and/or to the Accessible Text interface to see if it is
> SELECTED because of Accessible Text.  Is that the intention?
>
>   
> > 3. Any accessible node which has any descendant even partially selected 
> > will be considered selected.
> >     
>
> In the case where a non-text node has text descendants (do these cases
> even exist) that have a text selection, I'm guessing the non-text node
> will be marked as SELECTED?
>
> Furthermore, will the Gecko implementation work the other way around?
> That is, I'm hoping the assistive technology can call the accessible
> text implementation to *modify* selections as well.  If so, will the
> implementation set all the appropriate SELECTED states for ancestors?
>
> Thanks!
>
> Will
>
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>