Thanks for your input Malte. Some comments below. -Pete Malte Timmermann wrote: > 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). > Any clipboard operations, such as copy, are in IAccessibleEditableText. That appears to also be the case for ATK.
It's interesting that JAAPI and UAAPI are missing a copy to clipboard feature. I guess you have to cut/paste. > 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"? > IAEditableText.paste with a single index is consistent with ATK (and UAAPI and JAAPI) I should have documented "current position" (actually it's -2; length is -1) in more of the IAEditableText methods. I put that on my todo list. > 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. > For cut/copy I think you are saying: cut: remove the selection, cut the specified text into the clipboard copy: change the selection to the specified indexes; copy that text to the clipboard (assuming the AT would have set the start/ending indexes to match the selection, so the selection wouldn't actually change). paste: a) if there is selected text, delete it and insert the text at the index of the deleted text, ignoring the specified index (assuming the AT would have set the index at the beginning of the selection). b) if there is no selected text insert the new text at the specified location. What did the Firefox, Adobe, and Symphony developers do? > Makes sense? > Malte. > > 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), [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 >> > > -- *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
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
