Welcome to The Bug Genie
Please fill in your username and password below, and press "Continue" to log in.If you have not already registered, please use the "Register new account" tab to do so.
Please wait while updating issue type...
Could not save your changes
This issue has been changed since you started editing it
Data that has been changed is highlighted in red below. Undo your changes to see the updated information
You have changed this issue, but haven't saved your changes yet. To save it, press the Save changes button to the right
This issue is blocking the next release
This issue has been closed with status "Fixed" and resolution "RESOLVED".
There are no comments
There is nothing attached to this issue
This issue has no duplicates
There are no code checkins for this issue |
|||||||||||||||||||||||||||||||||||||||||||||||||||
Really delete this comment?
Really delete this comment?
Really delete this comment?
Yes, this can produce some issues. For example, if I select one or two layers in layers Panel and press Ctl+A, then it selects all layers in layers panel instead of selecting all ducks in the canvas (like old behaviour). To select all ducks I must activate canvas window before pressing Ctl+A...
Another thing: when canvas window is active focus often goes to the "Quality" spinbox in the toolbar at the top. If that happening then I can't use Ctrl+. and Ctrl+, keyboard shortcuts to navigate to next/prev frame. I guess maybe this issue will be fixed when Jcome will fix toolbar widget...
Really delete this comment?
This behanvior is the result of fix the bug introduced in Bug report 159 - Keyboard shortcuts interferes with param values.
The old behavior was that any key pressing was handled by the application shortcuts system before being handled by the currently focused widget. This produced that for example, when editing a parameter and pressing the "home" key, the time cursor responded going to the start of the animation instead of placing the cursor at the begining of the widget in edition.
The fix of Bug report 159 - Keyboard shortcuts interferes with param values is to ask the current widget to handle the keyboard combination and if it is not handled, then call the main applicaiton shortcut handler to process the key stroke.
So the final solution is to, one by one, define what key strokes should be handled or not handled by each widget type and in case it is not handled let the global shorcut keys handle it.
Really delete this comment?
I'll open a forum thread to discuss which keyboard shortcuts should be handled by each widget or not.
Really delete this comment?
Shouldn't widgets be allowed to override key shortcuts only if a widget input box is in edit/input mode? Would this be possible to do?
To define which key strokes is to be allowed as shortcuts or not can become confusing to the user, and unwanted limitation may show up.
If this is the only solution then I think the behaviour before 3472549 was fixed is better. There is then a limitation on which shortcuts can be practically used but the shortcut behaviour is consistent, no matter which window is currently in focus.
Really delete this comment?
Fixed on 0.63.05
Really delete this comment?
The issue was updated with the following change(s):
Really delete this comment?
Really delete this comment?
Really delete this comment?