Malte Timmermann wrote:
> 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?
>
Thanks, I missed the clipboard copy in UAAPI. When doing IA2 the advice
I was given from my team was to have all the clipboard operations in
IAEditableText, but perhaps that wasn't the best advice since a copy to
the clipboard doesn't modify the content, as you pointed out.
>>> 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.
>
Sounds good. Thanks 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
>>
>
>
--
*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
