#5678 closed defect (fixed)
Layer panel should not take focus when pressing layer icons
| Reported by: | Zverikk | Owned by: | team |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | Core | Version: | |
| Keywords: | focus, layer | Cc: |
Description
After clicking eye icon or changing active layer using layer list, input focus seems to stay in that window. As a result, pressing "Delete" to remove selected object or using "Ctrl+V" to paste anything does not work, or works worse than expected (for example, deleting active layer: #5671).
Focus must stay where it was, or, if that's impossible, automatically move to main editor window. This would be more obvious behaviour, and will simplify actions like copy-paste from one layer to another.
Attachments (0)
Change History (4)
comment:1 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:2 by , 14 years ago
I haven't implemented focus shift, but re-routing of shortcuts.
The focused gui element (its a JTable) reserves a limited number of short cuts for itself (because they have a certain function) and forwards the rest. I made it forward also Ctrl+V and a few others (see changeset).
If you find other shortcuts that do not work when focusing this area, please reopen and list them here!
comment:3 by , 14 years ago
I consider this solution a path to usability disaster.
Why do you need to focus JTable component when changing visibility or active layer? How does user know that the table aquires focus? Why could he need that?
For example, in Photoshop there's no focus in panels with tables. In Inkscape layer list grabs focus, and it's very annoying.
The list of rerouted shortcuts will keep growing and growing, and for what reason?
comment:4 by , 14 years ago
Try to press the visibility button in the layer list dialog. Then press space - this presses the button again. Technically this is no different. The list of rerouted shortcuts cannot grow indefinitely because there is only a limited number of shortcuts reserved for this GUI element. We could even extract them from the source code if it gets too annoying.
Can you name any other practical problems, when doing it like this?
Haven't tried it, but transferring focus on click might be somewhat tricky. But i'd reconsider if there were clear advantages.
In [3688/josm]: