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), [email protected] (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
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Reply via email to