Bugzilla – Full Text Bug Listing
| Summary: | StyledText shows blinking caret when text is selected (violates native text editing behavior) | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Doug M <eclipse> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | arronm |
| Version: | 4.1 | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | stalebug | ||
|
Description
Doug M
The caret does tell the user some information. It indicates Shift+<arrow key> will do. ex. Caret on the right, and SHIFT+LEFT will subtract a character from the selection, and SHIFT+RIGHT will add to the selection. When the caret is on the left, the opposite affect occurs. Using a native text widget, there is no indicator of what the key presses will do IMO, this is an improvement over the native behavior. Whether this is a bug is up to the Eclipse team, I suppose :) (In reply to comment #1) > The caret does tell the user some information. It indicates Shift+<arrow key> > will do. > > ex. Caret on the right, and SHIFT+LEFT will subtract a character from the > selection, and SHIFT+RIGHT will add to the selection. When the caret is on the > left, the opposite affect occurs. Using a native text widget, there is no > indicator of what the key presses will do > > IMO, this is an improvement over the native behavior. Whether this is a bug is > up to the Eclipse team, I suppose :) That is potentially useful behavior I was not aware of. Contemporary editors I tested use Shift-L & R simply to initially expand the left or right edge of the selection. (You can shrink a chosen side with a more obscure sequence.) With that behavior, the caret adds no information. To make use of the extra functionality provided by the caret, the user would have to anticipate needing to shrink a specific edge while making the initial selection. While one could argue the odds of that feature being used in practice, I realized my actual interest is in making an application that looks and acts like a platform native one. That's one of the primary design goals of SWT and precisely the reason I chose it over Swing. Even if an alternative selection behavior is subjectively or objectively better, for my users I need SWT text areas to look and act like Mac and Windows text areas. That's the bottom line for this developer. 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. Dear Lars, Thank you for responding to the bug report that I filed in 2011, eight years ago. At this point, I have moved on to other interests. The desktop app I was working on in 2012 was a failure, due to numerous bugs in SWT's text handling (many of which could not be worked around), and the glacial responsiveness of SWT's developers to addressing them. I can truly say that choosing SWT over Swing for this project was the worst design decision I have ever made in my career. I am sure that SWT is highly tuned to the limited needs of Eclipse, but as a UI for general apps it is unfit for purpose. Thanks for listening, if anyone is. Sincerely, Doug M |