Community
Participate
Working Groups
3.0 Eclipse uses readonly text fields as an emulation for "accessible labels", that is labels into which you can navigate by tabbing and where you select and copy the text to the clipboard. This approach reveals the follwoing problems on Mac OS X: - a readonly text field does not have the same background as a Label. It still looks like a field where you can enter text (bugs #39661, #68713, #34547) This invalidates Eclipse's use of readonly fields as "accessible labels". See first attached screenshot for how Apple implements accessible labels in the XCode IDE. - tabbing into readonly fields is questionable: example: you can tab into a wizard's header description field (see bug #65322). Apple does not support tabbing into text labels even if the text can be selected with the mouse or keyboard. See property dialog in XCode IDE. (Even turning on the "Full Keyboard Access" option in the Keyboard & Mouse preference pane doesn't enable tabbing into text labels). - showing a focus ring for readonly text fields is misleading (bugs #33241) See any Mac application that supports selectable/copyable text labels (Apple XCode, MS Entourage): they never show a focus ring. In addition readonly text fields have another problem on their own: - a readonly field has no cue that it is readonly (bugs #32471, #32944)
Created attachment 13871 [details] readonly text fields in XCode IDE
*** Bug 39661 has been marked as a duplicate of this bug. ***
*** Bug 68713 has been marked as a duplicate of this bug. ***
*** Bug 34547 has been marked as a duplicate of this bug. ***
*** Bug 33241 has been marked as a duplicate of this bug. ***
The accessible labels cause similar problems on Linux/GTK+ as they look out of place on themes with pixmap backgrounds (I thought there was already a bug about this but I cannot find it). GTK+ 2.4 added support for keynav into labels using Ctrl-Tab for a11y. If the Mac has no way to tab into a label, how do screen readers work?
Billy, may be bug #39661 is the one you are looking for. It started as a linux bug and was closed and later reopened for Mac OS X.
Need to determine how native Windows applications do this.
*** Bug 74716 has been marked as a duplicate of this bug. ***
SSQ, could we use the fact that the text fields of this type are SWT.READ_ONLY and created without a border to indicate that they are really "accessible labels". At least on the Mac, we could draw them the same way that XCode does.
I think we should make our TNXObject based Text control behave the same way as the single line read only text control that we are proposing to use in the Spinner control. SSQ?
*** Bug 66994 has been marked as a duplicate of this bug. ***
*** Bug 75566 has been marked as a duplicate of this bug. ***
What Carbon APIs are being leveraged to create the readonly text fields in Eclipse? Apple's Human Interface Guildelines provide guidance on how to display static text (active/dimmed/ selectable) as well as text fields in Mac OS X. For reference see: http://developer.apple.com/ documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html
>>I think we should make our TNXObject based Text control behave >>the same way as the single line read only text control that we >>are proposing to use in the Spinner control. SSQ?
Under HIView, we are using the HITextView control rather than the TXNObject. We are no longer drawing the focus ring. However, you can still tab to the field but you get no indication that focus is in the control (bad). I'm not sure we should change this for accessibility reasons. Your thoughts?
Readonly text fields are still a sore point in the SWT API. The commonly used solution is a Text widget with SWT.READ_ONLY and text.setBackground(getDisplay().getSystemColor(SWT.COLOR_WIDGET_BACKGROUND)); Since on Windows, a READ_ONLY text gets a gray background for free, most users forget to hack the bg color. On GTK and Cocoa, the bg stays white.
(In reply to comment #17) > Readonly text fields are still a sore point in the SWT API. > > The commonly used solution is a Text widget with SWT.READ_ONLY and > > text.setBackground(getDisplay().getSystemColor(SWT.COLOR_WIDGET_BACKGROUND)); > > Since on Windows, a READ_ONLY text gets a gray background for free, most > users forget to hack the bg color. On GTK and Cocoa, the bg stays white. Just happened to me (see bug 222090 comment 10). It would be good to address this.
Current state: On Cocoa, a Text with READ_ONLY but without BORDER has a white background (not widget background color). On GTK, it depends on the specifics of how the Text is created: In the ControlExample, it initially looks OK (gray bg with READ_ONLY), but when you set a custom bg color and then click Colors and Fonts > Default, the bg becomes white. OTOH, in an Eclipse properties page, it was always white (bug 222090 comment 10).
Regex to find readonly text fields that need a workaround: new Text\([^,]+,[^\)]+SWT\.READ_ONLY Internal workaround for JDT UI code: org.eclipse.jdt.internal.ui.util.SWTUtil#fixReadonlyTextBackground(Text)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
