Drawing tool changes mode when tab is pressed in different dialog

[Bernhard Hiller <bhil@…>]

The drawing tool got a new functionality some versions ago, so that specific angles can be drawn. This drawing mode can be changed using the tab key.

Error scenario:

Having drawn a way, I use to click on "+" button to add a tag. In the "add tag" dialog, the key textfield is focussed, I enter the key. Next, I press tab to navigate to the value textfield, enter the value, and then press OK to apply the changes and close the dialog.
During that tagging action, the tab key was pressed once. This causes the mode of the drawing tool to be switched.

[akks]

I confirm - it does. I simply do not know how to catch Tab correctly - when some toggle dialog is focused, it works too - switching modes with switching buttons... I tried disabling it (consume event), but it was not a good solution.

What can you advice? (Tab is customizable, by the way)

[Bernhard Hiller <bhil@…>]

That looks like quite an odd event subscription. But I do not know Java well - I work in the .NET world. There, I'd have the drawing area subscribe for user gestures (mouse, keyboard, etc). The drawing area would then provide these events to its subscribers. I.e. the drawing tool would listen for events from the drawing area, which are actually forwarded events of keyboard and mouse. And of course, in the .NET world, the drawing area would register for those events in such a way that it receives them only when it is focussed.

[akks]

I tried to detect event sender, but sender is always some other component - no drawing area :(

[akks]

Does anyone have idea how to fix this?

[akks]

Even after working with getInputMap and so on I have no idea how to fix this. We can only disable Tab for switching modes or for switching controls - both are not good solutions.

Tab can be changed in shortcut preferences (F12) if you use it often as controls switcher.
Should we close this ticket or wait for more advices or comments?

[errt@…]

I think, Tab is a bad idea for anything that's not the normal use of 1) indenting or 2) switching between controls. So a different shortcut should be used by default. SammysHP suggested using 'a' not only for switching to drawing mode, but also for switching between the two drawing modes, which seems reasonable.

[akks]

Hm, this can be really reasonable - when mode is activated, A have no addtional meaning.
If it will be approved, I can add this behaviour (in nearest latest or tested - depends on team).
We should not turn off Tab-snapping in this tested (you can disable it manually)

[akks]

Simple replacement of Tab to A helps, but all A strokes in all dialogs are captured then (hifhwAy, etc.).
After tested release I'll try to rework key handling (now it is half-based on AWTEventListener, should be on MapMode's actionPerformed or Main.registerShortcut etc. Capturing button holding is a real problem).

[errt@…]

How can this be? Typing 'a' into a text box currently does not activate drawing mode, so why does, after the change, pressing 'a' in a textbox toggle this? Could you give a hint where in the code this is handled, I'd like to have a look at this.

[akks]

Shortcut registered by Main.registerActionShortcut , which calls

contentPanePrivate.getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW).put(shortcut,action)

works OK (they are still captured in toggleDialogs, like Tab now, but not in Other dialogs).
Example is backspaceShortcut:
​http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/actions/mapmode/DrawAction.java#L175

If we use lower-level AWTEventListener, like now: ​http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/actions/mapmode/DrawAction.java#L185 (for button holding capture), it is global and captures all events. The solution is either to drop holding support (press A twice = fixing), either tune AWTEventListener.

[akks]

I have made two alternative patches:

• first adds ability to use A for angle snapping not fixing Tab issue (it can be disabled manually in preferences),
• second removes TAB completely and uses A for angle snapping instead of it.

In both variant A and Tab works for snapping only when focus is in MapView parent component, not in dialogs and menus.

@team: if we decide to drop Tab support (or change default key due to unfixable unexpected behaviour), it is better to do in current tested, together with other shortcuts changes. Elsewhere users will complain when next April tested will come out :)
If Tab will remain, there is no need to hurry.

[akks]

In 5137/josm:

Andle Snapping improvements: activation on A (Tab can be disabled, see #7438), better projections, show activation in status line

[akks]

Since we have disabled TAB for angle snapping by default, this can be closed too :)