Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#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:


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 bastiK, 14 years ago

Resolution: fixed
Status: newclosed

In [3688/josm]:

fixed #5678 - Layer panel should not take focus when pressing layer icons (it still takes focus, but does no longer occupies certain shortcuts)

comment:2 by bastiK, 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 Zverikk, 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 bastiK, 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.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.