[Accessibility-ia2] IAccessibleEditableText::cutText, copytext, and pasteText

Malte Timmermann malte.timmermann at oracle.com
Wed Oct 13 01:50:38 PDT 2010

I can only make assumptions about the parameters, because history was
written much earlier than ATK ;)

> http://download-llnw.oracle.com/javase/7/docs/api/javax/accessibility/AccessibleEditableText.html

For some reasons, I can't find a copy() in javax.accessibility...

IIRC, we stumbled over the missing copy() some time after starting UAA
implementations, and we coordinated this with the ATK people who then
introduced it in AccessibleEditableText (for compatibility reasons),
while the correct location would be AccessibleText (like in IA2 and UAA,
while the later one actually was the template for IA2).

With JAA missing copy(), I can't imagine why the positions have been
introduced, shouldn't have been needed. It also looks inconsistent to me
that paste() only has one position, not a selection, so someone would
first need to do deleteText() when I want to have the same behavior like
ctrl+v when having a selection.

But with having copy() in AccessibleText, the parameters suddenly makes
sense, because you might not be able to have/set a selection in every
widget implementing AccessibleText.

So now, we could say the parameters in cut() are for consistency,
because it would look strange if copy() has some, while cut() doesn't.
Or we would need to have a copy() in AccessibleEditableText overloading
the copy() in AccessibleText, but w/o paramaters, which could be
difficult to implement in some languages.

Just my thoughts on this, and with having the argument that copy()
really needs the parameters, the question changes to
- why only one parameter in paste()
- why not allowing -1 as "current position"?

And to answer Pete's question how to deal with an existing selection:
I would interpret the positions in the way, that a call to
cut/copy/paste would implicitly change the selection to match the
parameters provided. This way, you should have exact the same behavior
like when the user is using cut/copy/paste. To bad that the AT
implementation needs to special case paste() in a way that it calls
setSelection/deleteSelected before doing paste() in case there is a
selection, if behavior should be the same like when using ctrl+v.

Makes sense?

Pete Brunet wrote, On 10/12/10 23:50:
> Hi Carolyn, It's for historical reasons, but I don't know the history. 
> I agree that it would have been more natural to cut/copy from a
> selection and paste to the current selection or caret location if no
> selection.
> Based on the fact that the offsets are part of the API and no side
> effects are documented then I'd have to assume any existing selections
> are (in most cases) not affected by cut/copy or paste, but that does
> raise some particular issues.
> 1) The selection would have to shrink if cut removed some of it.
> 2) The selection would grow if anything was pasted into the middle of a
> selection.
> 3) What about a paste just before or just after an existing selection? 
> Would the selection be expected to grow?  In this case I'd choose to not
> grow the selection.
> From a practical perspective, I assume that when using an AT which
> provides these features the means for the user to specify the offsets
> would not result in a side effect of selecting or deselecting text in
> the app and thus the three issues mentioned would not arise.  To
> eliminate some tricky coding perhaps the best thing to do is to deselect
> anything that's selected at the beginning of any of these operations.
> What are others thoughts?
> Pete
> -- 
> *Pete Brunet*
> a11ysoft - Accessibility Architecture and Development
> (512) 238-6967 (work), (512) 689-4155 (cell)
> Skype: pete.brunet
> IM: ptbrunet (AOL, Google), ptbrunet at live.com (MSN)
> http://www.a11ysoft.com/about/
> Ionosphere: WS4G
> Carolyn MacLeod wrote:
>> Why do IAccessibleEditableText::cutText, copytext, and pasteText have
>> "position" parameters?
>> Why don't they just act on the current selection?
>> Or are they supposed to have a side effect of setting the current
>> selection, so that the client AT doesn't have to call
>> IAText::setSelection first? (If so, then this side effect does not
>> seem to be documented anywhere).
>> I see that AtkEditableText and AT-SPI also have "position" parameters
>> for cut/copy/paste of text, so IA2 probably did it "for historic
>> reasons". But what is the history, here?
>> I don't understand why these API's seem to be allowed to work outside
>> of the current selection, when any typical application always does
>> cut/copy/paste using the current selection.
>> Carolyn
> _______________________________________________
> Accessibility-ia2 mailing list
> Accessibility-ia2 at lists.linuxfoundation.org
> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

More information about the Accessibility-ia2 mailing list