Hi Pete, Pete Brunet wrote, On 10/19/10 00:26: > 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.
Just to clarify it: JAA seems to not have it at all, while UAA has it: In XAccessibleText. XAccessibleEditableText is better than not having it at all, but it's the wrong place. Why shouldn't I be able to call copy() for the content of a fixed text and other non-editable widgets? >> 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 know it's consistent with other API - it's still strange, for given reasons. > > 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. Well, with implicitly changing the selection to the parameters provided I mean completely ignoring the current selection in all cases. In the implementation of the single API functions: Step 1 (cut/copy/paste): Set selection to provided offset(s) Then, for cut/copy, copy the selected text to the clipboard. For cut only, delete selected text. For paste: paste text to "selection", which actually is just a (cursor) position, select new text. So cut/copy behave exactly like when done via keyboard (when the selection is the same), while paste is different (no selection possible in API call). Deleting the previously selected text on paste would be inconsistent when not doing the same for cut, and unexpected IMHO. So if AT wants to implement the same behavior on paste like when using the keyboard, it needs to delete the currently selected text with deleteText(), and then do paste(). Whether or not the AT works on the current selection, or using different selections for what ever reason, is up the the AT what ever use case it tries to implement. Malte. > > 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 _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
