| | [ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]
STR #2844
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Fl_Text_Display: needs keyboard nav for caret motion and keyboard selection |
|---|
| Version: | 1.3-current |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
| |
| #1 | greg.ercolano
10:38 May 11, 2012 |
| Fl_Text_Display seems to have the features Fl_Multiline_Output does in that one can enable a 'caret' cursor that could be used for keynav selection, but the caret doesn't respond to keyboard motion (up/down/left/right or 'shift selection').
Also, there seems to be inconsistencies in how the caret is displayed once it's enabled. If the widget opens without focus, the caret can not be made to appear via keyboard nav (ie. using the tab key to shift focus). Probably the caret should appear when the widget has focus, and disappear when not in focus (if it's enabled). | |
| |
| #2 | greg.ercolano
14:52 May 12, 2012 |
| Adding a file here, 'display-issue.cxx'.
If compiled as is (on linux/flwm), no caret appears, even if you use
TAB to shift focus to/from the button.
But if you comment out the (A) line, this causes the display to take
focus, allowing the caret to appear, and it remains even if you use
tab to shift focus from it.
Also: when the caret is visible, keynav can't be used to move it;
only mouse clicks and selections can manipulate it. | |
| |
| #3 | greg.ercolano
14:55 May 12, 2012 |
| Oops, accidentally posted the code with the "(A)" line
already commented out, so when built by default
the caret shows OK; you'll have to remove the comment
to make the caret disappear. | |
| |
| #4 | ianmacarthur
15:14 Sep 04, 2014 |
| For what it's worth, I think this behaviour is "by design", in so far as Fl_Text_Display supports all the cursor and carte stuff so that Fl_Text_Editor can use them, but to does not enable them, nor control them, by itself.
There was some discussion of this here:
https://groups.google.com/d/msg/fltkgeneral/eFHqyyksMJ0/6SsltjGYJ90J
that covers the ground on this... A potential way of using this is shown in the attached file text-display-move-cursor.cxx
So... do we want to consider closing this STR? | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
FLTK Apps 
