Opened 2 years ago
Closed 19 months ago
#5781 closed enhancement (fixed)
No keyboard shortcut for "Edit properties"
| Reported by: | Am909 | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Component: | Core |
| Version: | latest | Keywords: | keyboard shortcut edit properties |
| Cc: | Am909, xeen |
Description (last modified by simon04)
In v3738, there are keyboard shortcuts for "Add properties" and "Delete properties" that link to the relevant actions in the Properties pane.
There is no keyboard shortcut for "Edit properties", but there should be.
Attachments (3)
Change History (23)
comment:1 Changed 22 months ago by simon04
comment:2 Changed 22 months ago by stoecker
Aren't they visible in mouseover tooltip?
Changed 22 months ago by simon04
comment:3 Changed 22 months ago by simon04
No, at least not under Linux (cf. screenshot).
comment:4 follow-up: ↓ 5 Changed 22 months ago by skyper
By the way: At least in German "add tag" and "change tag" window have both the header "Werte ändern ?" (change values ?).
Should be "Wert(e) hinzufügen" (add value(s)) for "add tag".
comment:5 in reply to: ↑ 4 Changed 22 months ago by skyper
comment:6 Changed 20 months ago by simon04
What about changing the mnemonics to the following?
- [Alt]+[A]: Add
- [Alt]+[S]: Edit
- [Alt]+[D]: Delete
These keys are easily accessible on a QWERTY keyboard and quite similar to the editing shortcuts [A], [S], [D].
comment:7 Changed 20 months ago by simon04
- Resolution set to fixed
- Status changed from new to closed
In [4500/josm]:
comment:8 follow-up: ↓ 9 Changed 20 months ago by simon04
- Description modified (diff)
Lets test it … :-)
comment:9 in reply to: ↑ 8 Changed 20 months ago by skyper
- Resolution fixed deleted
- Status changed from closed to reopened
Replying to simon04:
Lets test it … :-)
Thanks, do only work if the mouse is over the property window. Was this intended ?
One more request:
- Would be nice, if the shortcuts are shown in the mouseover tooltip. Right now you have to know them and in my case they where even changed caused by silent conflicts.
Repository Root: http://josm.openstreetmap.de/svn Build-Date: 2011-10-10 01:31:57 Last Changed Author: stoecker Revision: 4512 Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b URL: http://josm.openstreetmap.de/svn/trunk Last Changed Date: 2011-10-10 00:16:18 +0200 (Mon, 10 Oct 2011) Last Changed Rev: 4512 Identification: JOSM/1.5 (4512 de) Memory Usage: 105 MB / 881 MB (22 MB allocated, but free) Java version: 1.6.0_20, Sun Microsystems Inc., OpenJDK 64-Bit Server VM Operating system: Linux
comment:10 Changed 20 months ago by skyper
#6954 is probably the reason that the short cuts do not work.
Remains the tooltip.
comment:11 Changed 20 months ago by skyper
- Type changed from defect to enhancement
comment:12 follow-up: ↓ 14 Changed 20 months ago by olejorgenb
Shortcut description in tooltips is usually handled in JosmAction. The new inner classes for add/edit/delete extends vanilla AbstractAction. If there's a reason they shouldn't be JosmActions, it seems we're supposed to use:
putValue(SHORT_DESCRIPTION, Main.platform.makeTooltip(normalDescription, shortcut));
comment:13 Changed 20 months ago by simon04
- Resolution set to fixed
- Status changed from reopened to closed
In [4518/josm]:
comment:14 in reply to: ↑ 12 Changed 20 months ago by simon04
Replying to olejorgenb:
Shortcut description in tooltips is usually handled in JosmAction.
Thanks for pointing that out.
comment:15 Changed 20 months ago by olejorgenb
In [4518/josm]
That probably fixes #6954 since the problem was a missing call to Main.registerActionShortcut (the josm action does this)
comment:16 Changed 20 months ago by olejorgenb
One more thing: (A bit OT I guess)
Would it make sense to bind the up/down keys to move the active/selected property in the sidedialog?
I'm attaching a patch that sets the focus to the property table after a tag has been added. This binds the arrowkeys "temporary" after adding a tag. (Enter key -> add property as before, although it make more sense to bind it to "edit", or not bind it at all).
This approach is probably not robust though. The table might shadow keys we use for other actions, and this is platform dependent.
comment:17 follow-up: ↓ 18 Changed 20 months ago by xeen
- Cc xeen added
- Resolution fixed deleted
- Status changed from closed to reopened
The keyboard shortcuts are not unregistered correctly when the MapFrame is destroyed:
Keystroke alt pressed A is already assigned to org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$AddAction@499ce8f3, will be overridden by org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$AddAction@20ab085 Keystroke alt pressed S is already assigned to org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$EditAction@996c8c2, will be overridden by org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$EditAction@1c7783ea Keystroke alt pressed D is already assigned to org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$DeleteAction@db5eaed, will be overridden by org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$DeleteAction@1b4b07df
STR:
- create new layer
- destroy the layer
- create new layer
Changed 20 months ago by olejorgenb
Changed 20 months ago by simon04
comment:18 in reply to: ↑ 17 Changed 20 months ago by simon04
Replying to xeen:
The keyboard shortcuts are not unregistered correctly when the MapFrame is destroyed:
Keystroke alt pressed A is already assigned to org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$AddAction@499ce8f3, will be overridden by org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$AddAction@20ab085 Keystroke alt pressed S is already assigned to org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$EditAction@996c8c2, will be overridden by org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$EditAction@1c7783ea Keystroke alt pressed D is already assigned to org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$DeleteAction@db5eaed, will be overridden by org.openstreetmap.josm.gui.dialogs.properties.PropertiesDialog$DeleteAction@1b4b07df
attachment:5781-unregister.patch should fix. Is there a better solution?
comment:19 Changed 19 months ago by simon04
In [4526/josm]:
comment:20 Changed 19 months ago by simon04
- Resolution set to fixed
- Status changed from reopened to closed



What is the scheme of the current shortcuts ("mnemonics")?
As logical consequence, what would be the key for Edit?
Should we somewhere make visible these shortcuts for the user?