| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2841
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | FLUID |
|---|
| Summary: | preventing of unintentional removing in Fluid |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | Nikego |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.4.0 |
|---|
| Fix Commit: | 0698e16a6b154f227dcb4ab135b273af1fa0f5f9 |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | Nikego
02:35 May 11, 2012 |
| I propose to add confirmation on removing widgets in Fluid. Someone can account it annoying window, but I have a lot of troubles with accidentally removing of widgets. E.g. I want to remove last symbol from label field of Properties and if I press the "delete" button two times my widget will disappear! Because I don't know how to make Fluid correctly handle this case I added fl_choice() in handler of deleting widgets to prevent unintentional deleting. | |
| |
| #2 | greg.ercolano
10:03 May 11, 2012 |
| ^Z for 'undo' has always prevented me from needing that feature. | |
| |
| #3 | Nikego
11:07 May 11, 2012 |
| > ^Z for 'undo' has always prevented me from needing that feature.
I knew someone should give such comment! You are first :-) Of course, I use ^z too. Unfortunately "undo" restores not only widget, but many fields of widget too. For example, try to edit tooltip text and press "delete" button in the last position. Then press ^z and you'll see initial value of the tooltip field. All your previous work has gone.
Second, the "undo" doesn't restore the Properties window and you have to spend time to invoke it again. I'd rather prevent the accident than to try to cure its effects. | |
| |
| #4 | matt
14:53 Feb 01, 2019 |
| Holy WTF! So if pressing Del at the end of a text, Fl_Input considers the keypress as unhandled because no characters were deleted, propagates it up the tree until it reaches the main window and the deletes the current widget.
To me that is totally unexpected, and neither a dialog box nor Undo seem like a good solution here. Instead, IMHO, having a text input widget active should always mark Del and Backspace keystrokes as "handled", even if no characters are actually deleted.
Any opinions? | |
| |
| #5 | matt
14:56 Feb 01, 2019 |
| Which is btw what the Backspace key already does: pressing BS at the beginning of the input field will simply do nothing - as expected. | |
| |
| #6 | matt
15:06 Feb 01, 2019 |
| Fl_Input no longer propagates "Delete" key events up the widget tree, which eliminates this problem. I am aware that this changes the behavior of Fl_Input for every App, but I am quite sure that a Delete event running rouge inside an app is quite unexpected.
It does prevent the Delete shortcut event from being sent when an Input field is active, but that would also be in the old code if the cursor is anywhere but after the last character.
Lastly, pressing Delete anywhere else in the Widget Dialog will delete the entire widget. I would expect that Delete only works when the main window is active, but that's another discussion. I'll mark this 2012 bug as resolved. | |
[ Return to Bugs & Features ]
|
| |
