Possible to activate "Viewport following" mode when not in "Expert mode" through keyboard shortcut

[ris]

Noticed this one during a missing maps event tonight.

The option for "Viewport following" mode is hidden behind "Expert mode", but this doesn't stop the keyboard shortcut from activating it (and it's not hard by default - Ctrl-Shift-F - just have to accidentally also hold shift down when trying to do "Find"). Problem is, because the user's not in expert mode there's no indication of why the editor's now "behaving strangely" and no clue as to how to deactivate it. What's more, when expert mode is then switched on, the new menu option doesn't pick up the "enabled" state of the mode, making it not look like the culprit. To remedy the situation the user has to seemingly "enable" the mode and then "disable" it.

I have a suspicion that there are other "Expert mode" features which behave similarly.

I'll probably look at picking this up myself, but I can see A few ways to approach this:

• Lowest hanging fruit is to at least make sure controls created by switching on "Expert mode" pick up any "enabled" state of their associated Action.
• A slightly harsh option would be to disable keyboard shortcuts for "Expert mode" features when not in expert mode.
• A slightly less harsh option would be to have a small unobtrusive message to say e.g. "this feature requires 'Expert mode' to be enabled" with possibly a pointer to how to enable it or even a button.
• Perhaps what the actual issue here is that modes like "Viewport following" mode show no indication of why they are behaving in such a weird way or how to get out of it. Features like the "Filter" have an on-viewport notice showing that they're enabled. Should other "modes" have this? Of course this raises the question - what to do when several of these modes are enabled? Stack them up in the viewport? Space is valuable.

What are others' thoughts?

[Don-vip]

Good questions!

My thoughts:

• when in Expert mode, display only a notification "<feature> is active" when enabled, rather than a permanent OSD
• when in non-expert mode, go with the popup+button "<feature> requires export mode to be enabled, would you like to enable it now?". If the user chooses yes, enable both expert mode and the feature.

Ideally we should have a generic system for this.

[Don-vip]

It's not so minor as I already heard about this problem in other mapping events. Just forgot about it.

[Klumbumbus]

Replying to Don-vip:

• when in non-expert mode, go with the popup+button "<feature> requires export mode to be enabled, would you like to enable it now?". If the user chooses yes, enable both expert mode and the feature.

Keyboard shortcuts for expert features in non expert mode are much likely in nearly all cases executed by accident and therefore the user will be confused whats going on if suddenly a message pops up about a feature he didn't want or even know about. Disabeling these expert shoutcuts in non expert mode seems to me the better solution from the view of a non expert user.

[Don-vip]

I'm also OK with this solution.

[ris]

Yes - it seems like the most to-the-point solution. The only issue it raises is this - do we want to actually strictly enforce the divide between expert and non-expert mode? A user may just want to use one feature from expert mode, and maybe they've been told about the shortcut by someone else. Do we want to "force" them to put up with all the scary expert features? The answer may well be "yes" because it simplifies things for us.

Also if we're going to be strictly segregating the separation of expert features it implies that, for consistency, we should be performing a step when disabling expert mode to make sure all expert mode features are not currently active.

[ris]

FWIW I don't seem to be able to reproduce the "menu item doesn't pick up state of ToggleAction when not made visible by expert mode" problem on my local machine. Machine in question was a mac - should probably check that. Or write a test.

[stoecker]

Keyboard shortcuts for expert features in non expert mode are much likely in nearly all cases executed by accident and therefore the user will be confused whats going on if suddenly a message pops up about a feature he didn't want or even know about. Disabeling these expert shoutcuts in non expert mode seems to me the better solution from the view of a non expert user.

That would require, that we mark the shortcuts as expert and activate, but disable them. The actions are instantiated always, so such a separation can only be done on shortcut calling time.

Is it really necessary to do this for every action or should this be restricted to mapping modes and permanent behaviour modifications like the follow feature? This could be handled in these directly without touching the shortcut framework. And it is more logical to me.

[ris]

I think silently ignoring "expert" shortcuts might lead to confusion. A newer user asking "how to do xyz" would get the answer "oh that's easy, hit Ctrl-Shift-K" and then just be confused as to why it's not doing anything for them.

Is it really necessary to do this for every action or should this be restricted to mapping modes and permanent behaviour modifications like the follow feature?

This is a good question - my immediate thought had been just for "toggle" actions, because those are the ones that need to be un-toggled. But the choice of features for which this is a problem may be more subtle.

[simon04]

In 17795/josm:

fix #16848 - Disable "Viewport following" shortcut when not in "Expert mode"