Bugzilla – Full Text Bug Listing
|
Description
Silenio Quarti
Here's the IA2 IDL for IAEditableText (i.e. Windows): HRESULT copyText ([in] long startOffset,[in] long endOffset) HRESULT deleteText ([in] long startOffset,[in] long endOffset) HRESULT insertText ([in] long offset,[in] BSTR *text) HRESULT cutText ([in] long startOffset,[in] long endOffset) HRESULT pasteText ([in] long offset) HRESULT replaceText ([in] long startOffset,[in] long endOffset,[in] BSTR *text) HRESULT setAttributes ([in] long startOffset,[in] long endOffset,[in] BSTR *attributes) Here's the AtkEditableText interface (i.e. GTK): gboolean atk_editable_text_set_run_attributes(AtkEditableText *text, AtkAttributeSet *attrib_set, gint start_offset, gint end_offset); void atk_editable_text_set_text_contents (AtkEditableText *text, const gchar *string); void atk_editable_text_insert_text (AtkEditableText *text, const gchar *string, gint length, gint *position); void atk_editable_text_copy_text (AtkEditableText *text, gint start_pos, gint end_pos); void atk_editable_text_cut_text (AtkEditableText *text, gint start_pos, gint end_pos); void atk_editable_text_delete_text (AtkEditableText *text, gint start_pos, gint end_pos); void atk_editable_text_paste_text (AtkEditableText *text, gint position); These seem pretty much the same, except that replaceText on Windows is more flexible than set_text on GTK (will have to emulate on GTK using delete_text and insert_text for anything other than 0, length). Scott, can you please figure out what the equivalent calls would be for Cocoa? Does Cocoa have any of this capability? i.e. cut/copy/paste through VoiceOver that is separate from the usual text caret, insert/delete/replace of text, and the ability to set text styles for a specific text range? I am looking at accessibilitySetValue:forAttribute: but I can't see where the offset parameter(s) would go, but maybe there's another way that I am missing. I'm not sure there are Cocoa equivalents. These commands look like the WM_COPY, WM_CUT WM_PASTE etc. commands mapped into accessibility events. They could all be mapped into accessible actions, but those are basically commands that the user issues to the app, much like picking from a menu. In the case of copy and delete you would have to first set the location and length of the selected text and then invoke copy or delete. > In the case of copy and delete you would have to first set the location and
> length of the selected text and then invoke copy or delete.
Hmmm... and then set them back to what they were before... same with paste.
Can we do insert and replace without messing up the clipboard?
And how about setAttributes (aka set text styles). Can we do that somehow?
It just occurred to me that it's all moot if VoiceOver isn't sending any of the text editing commands <grin>. (<duh> I must have been asleep earlier...) I'm going to have a look at the VoiceOver User's Guide to see if there's anything at all that looks like a text editing function in VoiceOver. (In reply to comment #6) > It just occurred to me that it's all moot if VoiceOver isn't sending any of the > text editing commands <grin>. (<duh> I must have been asleep earlier...) > I'm going to have a look at the VoiceOver User's Guide to see if there's > anything at all that looks like a text editing function in VoiceOver. Yep. VoiceOver is a screen reader as opposed to an input technology. I'm still trying to understand how this API would be used. It seems like a very high-level thing for accessibility. In Cocoa I can see something like AppleScript invoking this, but beyond that I'm not sure what you would do with it. Funny, I am just in the process of asking Richard S. that very question. I have been told before that it is something to do with virtual buffers (which I have never used). But even aside from that, I was thinking that it is certainly not a very useful thing for a StyledText to have a screen reader telling it to set line styles outside of the LineStyleListener mechanism. The two things would be fighting over whether the word should be bold red or italic blue... <g> I'll get back to you on what Rich says. Actually, if AppleScript can invoke stuff like this, maybe that's the use case. Does it make any sense at all to support the "editable text" subset of the AppleScript commands with our "editable text" accessibility API? (In reply to comment #9) > Actually, if AppleScript can invoke stuff like this, maybe that's the use case. > Does it make any sense at all to support the "editable text" subset of the > AppleScript commands with our "editable text" accessibility API? I haven't looked at AppleScript support in some time, but it looks like we'll be stopped pretty early on because you need to identify your applications as scriptable via an Info.plist key and a supplemental XML file which identifies what scripting support you implement. That's not going to be practical for RCP apps. It certainly looks like there's support for getting and setting text attributes via AppleScript, but you can only set font name, size and color. Forget about bold, italic, underline or anything like that. The standard text support is done by using NSTextStorage, which is what Text uses: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ScriptableCocoaApplications/SApps_implement/SAppsImplement.html#//apple_ref/doc/uid/20000037-1001820 > That's not going to be practical for RCP apps.
Maybe, but they have to do the Info.plist dance already - what's one more key? <g>
Anyhow, we'll wait to see what Rich says about who uses this feature - and why - on Windows, and then we'll have a better idea of whether or not it's important to find a way to make it work.
Rich says, "IAccessibleEditableText is for voice recognition systems and not screen readers. It is meant to allow a voice recognition system to easily edit text without having to simulate key strokes to do all the work." So I typed "voice recognition Mac" into Google and got MacSpeech Dictate. It uses the Dragon NaturallySpeaking engine. It needs an Intel Mac and OS X 10.5.6 or later. http://www.macspeech.com/ So the question I have is "how does it work". Does it simulate keystrokes, or does it use AppleScript? (or something else). Do you happen to know? (In reply to comment #12) > So I typed "voice recognition Mac" into Google and got MacSpeech Dictate. It > uses the Dragon NaturallySpeaking engine. It needs an Intel Mac and OS X 10.5.6 > or later. http://www.macspeech.com/ Aha, that makes sense now. > So the question I have is "how does it work". Does it simulate keystrokes, or > does it use AppleScript? (or something else). Do you happen to know? Voice recognition is usually done as an input method, so when the user says something the speech recognition turns it into text and insertText: on the active app's first responder is called. Commands likely come in via doCommandBySelector:, so that means cut:/copy:/paste:/delete: would all come in that way. We're already covered for simple things like multi-line text, so we would likely need to add handlers for cut/copy/paste in Control and forward them on to the Accessible implementing the API. The manual for MacSpeech hints it has some pretty high-level support for editing, but doesn't give much clues as to how it implements it. It says that it does not use keyboard equivalents or commands, so this could be a good match. <http://www.macspeech.com/pages.php?pID=182> Rich says that Dragon Naturally Speaking for Windows does not currently use the IAccessibleEditableText interface (they just simulate keystrokes), however they may in future. On the GTK side, the only AT we could find that uses AtkEditableText is GOK, the Gnome On-Screen Keyboard. Created attachment 179548 [details]
patch with 3 new API classes
This patch contains the 3 new API classes:
AccessibleEditableTextAdapter
AccessibleEditableTextEvent
AccessibleEditableTextListener
SSQ and SK please review the new API.
Notes:
- we use "offset" (not "index") to describe character positions
- I used cutText, copyText, etc to distinguish from the usual cut, copy, etc because these methods do not work on the selection (however I could be convinced to use the shorter names)
- I used "start" and "end" (not "start" and "length") because that is what we did with the other accessibility api (i.e. "end" is the offset after the last character)
- I used "substring" to describe "the portion of text from start to end" because that is what we did with the other accessibility api (recall that we didn't want to use "range" because that typically means start+length)
Question:
- StyledText can copy/cut in multiple formats (RTF, plain text...). I assume that we copy/cut in whatever format(s) the object supports?
The following field and 2 methods would need to be added to every platform's Accessible class:
Vector accessibleEditableTextListeners = new Vector();
/**
* Adds the listener to the collection of listeners that will be
* notified when an accessible client asks for any of the properties
* defined in the <code>AccessibleEditableText</code> interface.
*
* @param listener the listener that should be notified when the receiver
* is asked for <code>AccessibleEditableText</code> interface properties
*
* @exception IllegalArgumentException <ul>
* <li>ERROR_NULL_ARGUMENT - if the listener is null</li>
* </ul>
* @exception SWTException <ul>
* <li>ERROR_WIDGET_DISPOSED - if the receiver's control has been disposed</li>
* <li>ERROR_THREAD_INVALID_ACCESS - if not called from the thread that created the receiver's control</li>
* </ul>
*
* @see AccessibleEditableTextListener
* @see #removeAccessibleEditableTextListener
*
* @since 3.7
*/
public void addAccessibleEditableTextListener(AccessibleEditableTextListener listener) {
checkWidget();
if (listener == null) SWT.error(SWT.ERROR_NULL_ARGUMENT);
accessibleEditableTextListeners.addElement(listener);
}
/**
* Removes the listener from the collection of listeners that will be
* notified when an accessible client asks for any of the properties
* defined in the <code>AccessibleEditableText</code> interface.
*
* @param listener the listener that should no longer be notified when the receiver
* is asked for <code>AccessibleEditableText</code> interface properties
*
* @exception IllegalArgumentException <ul>
* <li>ERROR_NULL_ARGUMENT - if the listener is null</li>
* </ul>
* @exception SWTException <ul>
* <li>ERROR_WIDGET_DISPOSED - if the receiver's control has been disposed</li>
* <li>ERROR_THREAD_INVALID_ACCESS - if not called from the thread that created the receiver's control</li>
* </ul>
*
* @see AccessibleEditableTextListener
* @see #addAccessibleEditableTextListener
*
* @since 3.7
*/
public void removeAccessibleEditableTextListener(AccessibleEditableTextListener listener) {
checkWidget();
if (listener == null) SWT.error(SWT.ERROR_NULL_ARGUMENT);
accessibleEditableTextListeners.removeElement(listener);
}
Oops - in the patch, change all @since 3.6 to @since 3.7. Created attachment 179644 [details]
revised: 3 new API classes with result field
I remembered that these operations always need a "result" field, so that the application can communicate back to the AT that the operation was completed.
So this updated patch includes 'result' in the event (see AccessibleActionListener.doAction for precedent). I also added some javadoc to the Event class fields.
This brings up the question: should we delete the 'string' field and just use the 'result' field for both [in] and [out] strings? (there isn't really a precedent for this, because 'result' has always been an [out] field only).
Never mind the question in comment 18 because the result is typically expected to be initialized to null, so it does not make sense to also have it as an [in] field. -- Re: start and end vs. offset and length -- AccessibleTextEvent uses both offset and length instead of start and end, but it is consistent when it uses one vs. the other. -- In AccessibleEditableTextAdapter some of the method descriptions don't match up correctly with the method names. I won't enumerate all of them, but deleteText's description should be on cutText and insertText's description should be on deleteText, for starters. AccessibleEditableTextListener is correct. -- In the descriptions for copy, cut, delete, replace, and setAttributes we say '<action> the substring between the two specified offsets' but 'between' isn't the right modifier here. I think of 'between' as always being exclusive, but the first index is inclusive and the last is exclusive. Could we reword it to be a bit more like java.lang.String.substring's description? For example, "Deletes the substring beginning at the specified offset <code>start</code> and extending to the character at offset <code>end - 1</code>." -- Copy and cut direct the listener to perform an operation as opposed to getting a string value back from the event, so I think it's up to the listener to decide if any styling information is placed on the clipboard as well. I would think it's obvious that offsets don't account for any styling options. -- In setAttributes, are we going to define the format of the attribute strings? I don't think it can be implementation- or window toolkit-dependent. Thanks, Scott! I'll answer the last point first, because I just tripped over it myself, and then I'll provide a patch with the fixes you suggested.
> -- In setAttributes, are we going to define the format of the attribute
> strings? I don't think it can be implementation- or window toolkit-dependent.
I noticed that when we implemented IAccessibleText::get_attributes, we used the following 2 fields to represent the attributes in AccessibleTextAttributeEvent:
public TextStyle textStyle; // for all the usual TextStyle attributes
public String [] attributes; // for custom & possible future expansion
So, for consistency, we can't just use:
public String string;
for set_attributes.
The question is, should we:
a) add textStyle and attributes[] fields to the AccessibleEditableTextEvent ?
OR
b) reuse the AccessibleTextAttributeEvent class for the setAttributes method ?
> -- Re: start and end vs. offset and length -- AccessibleTextEvent uses both > offset and length instead of start and end, but it is consistent when it uses > one vs. the other. Unfortunately, AccessibleTextEvent is old (@since 3.0). It was designed to be consistent with StyledText's "style range indexing", which used start/length. When we added IA2/Atk support in 3.6, we decided that we should go with start/end for consistency with many other methods in SWT that use start/end (i.e. StyledText/Text.setSelection(start, end), or Text.getText(start, end)). We made AccessibleTextExtendedListener extend AccessibleTextListener, and we just reused AccessibleTextEvent, instead of deprecating AccessibleTextListener. Our examples should only implement AccessibleTextExtendedListener methods now. > -- Copy and cut direct the listener to perform an operation as opposed to > getting a string value back from the event, so I think it's up to the listener > to decide if any styling information is placed on the clipboard as well. I > would think it's obvious that offsets don't account for any styling options. Yes, you're right. The application can decide whether they want to put multiple formats on the clipboard, or just plain text. I guess 'paste' may end up being problematic some day, i.e. is it 'paste' or 'paste special...' (which lets the user decide which clipboard format they want to paste) ? :) Created attachment 179675 [details] revised 3 new API classes again according to SK's feedback > -- In AccessibleEditableTextAdapter some of the method descriptions don't match > up correctly with the method names. Thanks - fixed. > -- In the descriptions for copy, cut, delete, replace, and setAttributes we > say '<action> the substring between the two specified offsets' but 'between' > isn't the right modifier here. I agree - fixed. (Note that this new patch does not - yet - address the setAttributes event fields question). We should not have three methods to change the text: insertText() deleteText() replaceText() ATK only have two (insertText, deleteText). I prefer to have only replaceText(), since both insertText()/deleteText() can be implemented with replaceText(). That way the interface is smaller/simpler. If insertText() is removed, only pasteText() has the "offset" event parameter. We should consider deleting that field as well and use start==end instead. We should reuse AccessibleTextAttributeEvent for setAttributes(). We will have to add result field to that event. Created attachment 179750 [details] revised 3 new API classes based on SSQ's feedback > We should not have three methods to change the text... I agree. (ATK also has 3 if you include set_text_contents, but that's not the same as IA2 replaceText). This new patch only has replaceText() in the interface. I added a comment to replaceText that hopefully covers insert and delete. Please check it out. I also removed 'offset', and changed the comments in pasteText to use start instead of offset. (I added a comment for 'end', to say that it equals start. Let me know if I should keep that comment line, or just delete it. I am not sure if it is useful, or just confusing). Note that this patch still does not address setAttributes. SSQ and I had a discussion about this, and we currently believe we will have to go with an array of strings, and not have a TextStyle field at all (which would unfortunately not be consistent with the fields used for getAttributes). The reason TextStyle is a problem in the "set" direction is that it does not make sense for Accessibility to create all of those colors and fonts to send in to the application. (Too bad we don't have a TextStyleData class... <grin>). (In reply to comment #25) > This new patch only has replaceText() in the interface. I added a comment to > replaceText that hopefully covers insert and delete. Please check it out. When start and end are equal you aren't deleting anything, so it's ambiguous as to where the insertion should happen -- is it before or after the start index? I think the description in replaceText should say "This event notification is also used to delete text if <code>string</code> is an empty string or to insert text before the specified offset, if <code>start</code> and <code>end</code> are equal. > I also removed 'offset', and changed the comments in pasteText to use start > instead of offset. (I added a comment for 'end', to say that it equals start. > Let me know if I should keep that comment line, or just delete it. I am not > sure if it is useful, or just confusing). Maybe we should just say 'end - field not used.' > Note that this patch still does not address setAttributes. SSQ and I had a > discussion about this, and we currently believe we will have to go with an > array of strings, and not have a TextStyle field at all (which would > unfortunately not be consistent with the fields used for getAttributes). The > reason TextStyle is a problem in the "set" direction is that it does not make > sense for Accessibility to create all of those colors and fonts to send in to > the application. (Too bad we don't have a TextStyleData class... <grin>). setAttributes would only set one run of characters at a time, so I would think a single TextStyle object per event is enough to convey what needs to be set. Are colors and fonts that heavyweight on platforms other than cocoa? I'm thinking about NSAttributedString, which uses NSFonts and NSColors for the appropriate attributes. You're going to get font and color data anyway from the AT, so you would have to decode it into a string and then reconstitute it into a Font or Color on the implementation side. > setAttributes...
OK, after further discussion, here's what we ended up with:
1) We will go with the 2 fields, which is consistent with getAttributes, i.e.:
public TextStyle textStyle; // for all the usual TextStyle attributes
public String [] attributes; // for custom & possible future expansion
2) We will use AccessibleTextAttributeEvent for setAttributes, which is also
consistent with getAttributes, i.e.:
public void setAttributes(AccessibleTextAttributeEvent e);
This means that the new AccessibleEditableTextEvent doesn't need the
TextStyle and String [] fields.
3) SWT Accessibility will create the font (there is only one) and the color(s) required to fill the TextStyle, and we will document as clearly as possible that these resources are only guaranteed to be available for the duration of the event. (i.e. Accessibility will dispose of them as soon as the listener method returns). So any application that wishes to keep these (i.e. StyledText would likely hang onto them in a StyleRange and use them later during paint), needs to make a copy, for example:
Font myFont = new Font(display, event.textStyle.font.getFontData());
Color myForeground = new Color(display, event.textStyle.foreground.getRGB());
... and the app needs to dispose myFont and myForeground when done with them.
This follows the SWT resource rule "If you created it, you dispose it. If you got it from the OS, you do not dispose it." In this case, from the application's point of view, the font/colors came from the OS.
The "only valid for the duration of the event" specification is like the GC in a PaintEvent. It is only valid for the duration of the paint, and must not be disposed.
I think we are ok with this. I will make the changes and put out another patch. I will address your other points in the patch.
Created attachment 180069 [details] 3 new API classes again + changes in TextAttributeEvent This patch includes the 3 new API classes again, with setTextAttributes javadoc for textStyle and attributes fields, and a new 'result' field in the AccessibleTextAttributeEvent class. I also added javadoc to the original fields in AccessibleTextAttributeEvent, and made very minor javadoc changes in AccessibleAttributeListener/Adapter. > When start and end are equal you aren't deleting anything, so it's ambiguous > as to where the insertion should happen -- is it before or after the start > index? I always think of the offsets as the gaps between the characters (where the caret goes), so my preference is to say 'at the offset' instead of 'before' or 'after'. i.e. for the string 'abc' the offsets are 0a1b2c3, and inserting an 'x' at offset 1 gives axbc. I discussed these words with SSQ, and he says the best words are "at the leading edge of the offset", because this takes care of bidi also. So I used most of your suggested words for the description in replaceText, except for the 'before'. I also used "at the leading edge of the offset" for pasteText. > Maybe we should just say 'end - field not used.' I have done something a bit different for the unused 'end' field for pasteText. In the pasteText method description, I simply don't desribe 'end' at all, and in the event field descriptions, 'end' does not have an @see for pasteText. Created attachment 180090 [details] Windows implementation This patch contains the full Windows implementation, including new API classes and fields. This includes an implementation for IAccessibleEditableText::setAttributes, however note that not all possible combinations of attributes in the IA2 spec are handled - only the simplest interpretation of the ones that make sense for StyledText. For this reason, we decided to pass all of the attributes through to the application in the "attributes" parameter (not just the ones that aren't in the TextStyle parameter). That way, if the application wants to implement something more specific, they are free to do so. FYI, here is the IA2 spec for the text attributes strings: http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2/textattributes Here is the (slightly bogus) test snippet.
Cut/copy/paste and replace should really be implemented in StyledText, but I will let Felipe do that when he returns. :)
Since StyledText's cut/copy/paste API only operate on the current selection, this test snippet has the side effect of setting the selection for those operations.
StyledText does not need to implement setAttributes. That will be left up to the application. For example, the Java editors will not implement it, because they use LineStyleListener to set the styles the way they want them. So setAttributes is only for applications that let the user change the styles directly.
import org.eclipse.swt.*;
import org.eclipse.swt.widgets.*;
import org.eclipse.swt.accessibility.*;
import org.eclipse.swt.custom.*;
import org.eclipse.swt.layout.*;
public class AccessibleEditableTextTest {
public static void main(String[] args) {
Display display = new Display();
Shell shell = new Shell(display);
shell.setText("AccessibleEditableText");
shell.setLayout(new FillLayout());
final StyledText text = new StyledText(shell, SWT.BORDER | SWT.MULTI);
text.setText("The quick brown fox jumps over the lazy dog.\nThat's all folks!");
text.getAccessible().addAccessibleEditableTextListener(new AccessibleEditableTextListener() {
public void copyText(AccessibleEditableTextEvent e) {
System.out.println("copyText " + e);
text.setSelection(e.start, e.end);
text.copy();
e.result = ACC.OK;
}
public void cutText(AccessibleEditableTextEvent e) {
System.out.println("cutText " + e);
text.setSelection(e.start, e.end);
text.cut();
e.result = ACC.OK;
}
public void pasteText(AccessibleEditableTextEvent e) {
System.out.println("pasteText " + e);
text.setSelection(e.start);
text.paste();
e.result = ACC.OK;
}
public void replaceText(AccessibleEditableTextEvent e) {
System.out.println("replaceText " + e);
text.replaceTextRange(e.start, e.end - e.start, e.string);
e.result = ACC.OK;
}
public void setTextAttributes(AccessibleTextAttributeEvent e) {
System.out.println("setAttributes " + e);
StyleRange style = new StyleRange (e.textStyle);
style.start = e.start;
style.length = e.end - e.start;
text.setStyleRange(style);
e.result = ACC.OK;
}
});
shell.pack();
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
}
}
Created attachment 180173 [details]
Windows implementation + all platform API
This patch is identical to the previous one, except that it includes the remaining new API (i.e. addEditableTextListener, removeEditableTextListener, and accessibleEditableTextListeners) for all platforms (gtk, carbon, cocoa, and the emulated accessibility platforms).
SSQ, I know that you are swamped, so I will do the GTK implementation, and you can review the patch.
Scott, do you have some time available to do the cocoa implementation? SSQ and I can review it together.
SSQ, should we just leave the carbon implementation as stubs for now?
(In reply to comment #31) > Scott, do you have some time available to do the cocoa implementation? SSQ and > I can review it together. I'm finishing up native toolbar support today and probably a bit tomorrow, but then I should be able to get started. We'll have to see how much of this can be done in Cocoa. Created attachment 180252 [details]
Windows implementation (with dispose) + all platform API
After all of the discussion about fonts and colors, I forgot to dispose of them after calling the application's setTextAttributes method. This patch is identical to the previous, with this missing code added:
if (style.font != null) {
style.font.dispose();
}
if (style.foreground != null) {
style.foreground.dispose();
}
if (style.background != null) {
style.background.dispose();
}
And a new sentence in the javadoc for the setTextAttributes "textStyle" parameter:
* <li>[in] textStyle - the TextStyle which contains attributes that replace the old set of attributes.
* The foreground, background, and font fields of this TextStyle are only valid for the duration of the event.</li>
Created attachment 180769 [details] GTK implementation (setAttributes is incomplete) Here is the GTK implementation. This patch assumes that the patch in comment 33 has been applied first. The atkEditableText_set_run_attributes method is incomplete (still need to go through the given attributes string and set the textStyle fields). Created attachment 180774 [details]
Cumulative patch: API + win + gtk
This is the full patch so far. It includes all of the new API, plus the Windows implementation, plus the GTK implementation so far. It contains the stubs for carbon, cocoa, and emulated platforms. I also added "WARNING: API UNDER COSTRUCTION" to all new API classes, methods, and fields.
I am going to put this out so that Scott can have all of the stubs he needs to begin the cocoa implementation. SSQ, please review when you synchronize.
OK, Scott - it's released. There's a test snippet in comment 30. FYI, I forgot to include the GTK PI in the patch, so that has now been released to HEAD. In addition, a symbol needed to change to compile on AIX. So please consider HEAD to be the most up-to-date source for this bug now. Better test snippet (makes a copy of the font and colors from the event):
import org.eclipse.swt.*;
import org.eclipse.swt.widgets.*;
import org.eclipse.swt.accessibility.*;
import org.eclipse.swt.custom.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.layout.*;
public class AccessibleEditableTextTest {
public static void main(String[] args) {
final Display display = new Display();
Shell shell = new Shell(display);
shell.setText("AccessibleEditableText");
shell.setLayout(new FillLayout());
final StyledText text = new StyledText(shell, SWT.BORDER | SWT.MULTI);
text.setText("The quick brown fox jumps over the lazy dog.\nThat's all folks!");
text.getAccessible().addAccessibleEditableTextListener(new AccessibleEditableTextListener() {
public void copyText(AccessibleEditableTextEvent e) {
System.out.println("copyText " + e);
text.setSelection(e.start, e.end);
text.copy();
e.result = ACC.OK;
}
public void cutText(AccessibleEditableTextEvent e) {
System.out.println("cutText " + e);
text.setSelection(e.start, e.end);
text.cut();
e.result = ACC.OK;
}
public void pasteText(AccessibleEditableTextEvent e) {
System.out.println("pasteText " + e);
text.setSelection(e.start);
text.paste();
e.result = ACC.OK;
}
public void replaceText(AccessibleEditableTextEvent e) {
System.out.println("replaceText " + e);
text.replaceTextRange(e.start, e.end - e.start, e.string);
e.result = ACC.OK;
}
public void setTextAttributes(AccessibleTextAttributeEvent e) {
System.out.println("setAttributes " + e);
/* Create new graphics resources because the old ones are only valid during the event. */
TextStyle textStyle = new TextStyle(e.textStyle);
if (textStyle.font != null) textStyle.font = new Font(display, textStyle.font.getFontData());
if (textStyle.foreground != null) textStyle.foreground = new Color(display, textStyle.foreground.getRGB());
if (textStyle.background != null) textStyle.background = new Color(display, textStyle.background.getRGB());
if (textStyle.underlineColor != null) textStyle.underlineColor = new Color(display, textStyle.underlineColor.getRGB());
if (textStyle.strikeoutColor != null) textStyle.strikeoutColor = new Color(display, textStyle.strikeoutColor.getRGB());
if (textStyle.borderColor != null) textStyle.borderColor = new Color(display, textStyle.borderColor.getRGB());
StyleRange style = new StyleRange (textStyle);
style.start = e.start;
style.length = e.end - e.start;
text.setStyleRange(style);
e.result = ACC.OK;
}
});
shell.pack();
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
}
}
Created attachment 180919 [details]
patch for setAttributes to not use String.split/replace
Patch for Windows implementation Accessible.setAttributes() to remove references to java 1.5 String.split() and String.replace().
Uses String.indexOf() and String.substring() instead.
This has been released to HEAD to remove API version errors from the build.
Created attachment 181014 [details]
test snippet - checks for null
Updated test snippet once more because we decided that the textStyle and attributes event fields can both be null. API Javadoc in HEAD now mentions this.
Created attachment 181022 [details]
Patch for Cocoa
Mac implementation attached. The best we can do right now is implement setting the selected text. The only attributes that deal with attributed strings (which is how you would use setAttributes() are parameterized, and it's not possible to set a parameterized attribute.
I'll check this in, in any event, as this is needed functionality.
Created attachment 182168 [details]
patch for GTK setAttributes
Fixed > 20101101. The final patch for the implementation of this API on all platforms is now released to HEAD, so this bug can be closed. I have opened bug 329216 for StyledText to implement some of the API, so that any Eclipse UI that uses StyledText will be accessible to speech recognition systems "for free". |