Work on Toggle-Editor-Views with discussion on shortcuts/hotkeys

Re: Setup of keyboard shortcuts

Existing shortcuts:
- f = toggle window / fullscreen display
- h = main menu (options, save, exit, etc.)
- t = tools menu
- p = players menu
- m = mini map
- space-bar = toggle Buildspots view

Inaugurated shortcuts:
- v = toggle Resources view
- b = toggle Immovables view
- g = Terrain menu
- i = Immovables menu
- a = Animals menu
- r = Resources menu

- What is the required format and pixel-size of the icons?

I think we should start with actual functionality and once we know it is doable, we can think about GUI.

For the begining the shortcuts would be sufficient.

Are you saying you want to join the implementation team? So far the team consists of only me. As a member of the team you may criticise the work plan. But as I have put in work already, I may ask you to propose a complete rewrite of the plan as alternative.

Actually I prefer to work on GUI matters first since a) I need a testing environment anyway, so the "real" GUI serves also well for this, b) it is a design rule to walk from behaviour to implementation, c) I have little doubt it is doable and d) the GUI isn't such a great effort.

If you want to join I would see you for the task of implementing the inaugurated shortcut keys. Someone else could go ahead and update documentation about it. GunChleoc, of course, has the option to intervene with the design of the new function buttons, otherwise I may give it a try. I would also take over the GUI update of the function buttons and related logic.

If we succeed in this, we have a first result that can go online!

Restatement of Function Keys (Shortcuts):

Existing shortcuts:
- f = toggle window / fullscreen display
- h = main menu (options, save, exit, etc.)
- i = information tool
- t = tools menu
- p = players menu
- m = mini map
- space-bar = toggle Buildspots view
- ctrl-z = undo last action
- ctrl-y = redo last action
- ctrl-l = load map
- ctrl-s = save map

Inaugurated shortcuts:
- v = toggle Resources view
- b = toggle Immovables view
- g = Terrain menu
- o = Immovables menu
- a = Animals menu
- r = Resources menu

Comment:
- updated existing shortcuts
- changed "Immovables menu" to "o" because of collision
- may be discussed what key suits best for "Immovables menu"

Additional existing in-game keyboard shortcuts:

- Page up/down = Game speed
- Pause = pause game
- c: toggle census
- s: toggle statistics
- o: toggle objectives
- n: toggle messages (news)
- F1: help

Statistics:

- i: stock (inventory)
- b: building statistics

If we ever manage to support constructing scenarios in the editor, we will want the census, stock and building statistics in the editor as well. So, this removes c, i, b from the list of possible new hotkeys.

What would you assess more often, the toggle resources/immovables function, or selecting the tools? We should consider using the Ctrl key to widen our options. So, something like:

- Ctrl + r = toggle Resources view
- Ctrl + v = toggle Immovables view
- e = Terrain menu
- v = Immovables menu
- a = Animals menu
- r = Resources menu

I also changed the terrain menu to e, since the letter is in the word.

And anybody can add constructive criticism to the work plan, we shouldn't discard ideas just because the person who posted them is too busy working on another part of the code ;)

Well, my idea was that GENERALLY one should start from most complicated stuff and finish with trivial stuff. But if you are sure that everything is doable - I am fine.

I must say I dont know the code and dont have the motivation to learn it, but I am thankful that you are working on this :)

@GunChleoc
A few things to say to this:
Candidates to reserved keys from in-game: c, s, n, o, i, b

1. collision of in-game i = inventory and existing editor i = information tool
Either we can take this chance to move the editor assignment or we have to drop the i = inventory future assignment.

2. CTRL-keys; I'm not a friend of this type of key combinations because it takes more time to realise the switch. Work flow in editor should be as smooth and easy as possible, so I'm all for keeping to single key assignments as long as possible. Second, I would like to see the VIEW-TOGGLES in a vicinity to the space-bar so that they are easily reachable when s.o. is toggling through the variety of display states. Immovable-View and Resources-View should therefore be single keys in close preferably neighbour vicinity. So I propose f and g for them now, in the face of the reservation list. Requires redefinition of the window toggle which I believe is used rarely. Alternatives are x, y or z, u.

3. Restatement

Inaugurated shortcuts:
- f = toggle Resources view
- g = toggle Immovables view
- e = Terrain menu
- v = Immovables menu
- a = Animals menu
- r = Resources menu

Re.defined shortcuts:
- w = toggle window / fullscreen (replaces f)

Existing shortcuts (single):
f, h, i, t, p, m, space

Reserved shortcuts:
c, s, n, o, b

1. I have no problem with this - only common editor/game functionality needs to keep hotkey consistency.

Since we just freed up . and , - how about using those for the new overlays? This way, we can keep f for fullscreen.

1. So can I note that "i = information tool" is agreed fix?

2. You decide! I see an advantage with x y instead of , . because a) it is left hand and most people will use the right hand for the mouse, b) these characters are elements of the alphabet, just like the others, and are more obviously displayable.

1. yes.

2. x y doesn't work on German keyboards, because they swap y and z. We should have a look at some keyboard layouts to make sure that , . is near the space bar too.

, . are available as expected in German and English layouts. French appear to have a totally different layout, but I'm not sure. Other languages like Russian or Greek are also out of the game. So there's a bit of a problem with translations I should guess.

My suggestion is to resort to f g and redefine w for window size toggle. This is the best compromise in ergonomic and documentary perspective. w for window is easy to remember.

Why not use the F[2..10] keys? (F6 must be redefined then)

I think those keys are on mostly the same in each keyboard layout. E.g. the F-keys can be used for toggling the overlays or for switching through the entries in the immovables menu. Recognizing the numbers with the order of entries in the immovables menu is maybe better than trying to find single letters which may or may not associate with a specific view or function.

Since there is a plan to make the editor an own program and the editor has other requirements for shortcuts, there is IMHO no need to have all shortcuts from in game the same as in editor. Except global shortcuts which manipulates the view (Zoom related shortcuts, Fullscreen).

Regarding f vs. w for fullscreen: Can't see a reason why f should associate with the ressources view (you mean the resources overlay here?). From my point of view f associates better with "fullscreen" than w. But i guess it's just because i am familiar with this and because i start widelands usually in window mode and switch to fullscreen then :-)

>Why not use the F[2..10] keys? (F6 must be redefined then)

We have 19 functions to administer and map to keys, so 8 would not suffice. More to that, function keys should be reserved for META kind of stuff like saving, loading, options etc., IMHO. For your other arguments, please read our above discussion.

Ok, I wasn't aware the f also means something in the running game. So since I don't like , . for several reasons, we are left with the following alternatives:

q-w, d-g, j-k, k-l

I favour q-w, second d-g. Are we through with lettering then? :)

Side Notes: You see that only discussing behaviour of systemats renders loads of problems which were not aware before. Second, for program translations probably key-to-function maps are required to be created in-program. Don't know if such exist already.

q-w sounds good, because it's on the edge on the keyboard and thus easily hit. This also works for French keyboards https://en.wikipedia.org/wiki/AZERTY

At the moment, all hotkeys are hard-coded. I started working on a branch that lets the user assign hotkeys

https://code.launchpad.net/~widelands-dev/widelands/configurable_hotkeys

it's a heavy work in progress though and I haven't done anything with it for a while.

> We have 19 functions to administer and map to keys, so 8 would not suffice.

Seems my suggestion was not as clear as i meant it was. From my point of view we have three different groups:

1. Shortcuts that open windows -> e.g. t for toggling Tools menu
2. Shortcuts that toggle things directly on the map (overlays) -> e.g. space for toggling buildhelp
3. Shortcuts that have influence on the main view -> e.g. f for Fullscreen

So i was just thinking to have one of this group on the F-keys, e.g. the overlays.

> function keys should be reserved for META kind of stuff

From my experience the developers of a particular program defines what 'meta stuff' is. Once i used a 3-d drawing program which used the f-keys to get different views of an object.

Anyway, trying to find such groups would help to find good shortcuts, imho. Using the function-keys for one of the groups would mean to have more possibilities for other shortcuts.

Just an opinion :-)

Thanks, Kaputtnik, I always like to hear opinions! As for the purpose of this thread, however, I see things settled. We have not only fixed the required settings for the new functions in an ergonomical and conservative way, we also integrated with the key mappings of the running game as good as possible. I would say: good job! :)

We can think about re-mapping some of the current functions, and particularly from those which were not spoken of here, like the CTRL+ keys, to function keys, but that is a bit of a different topic. As for the view toggles I wouldn't like to have function keys because of their ergonomical disadvantage.

Below restatement of our current results. I have added j as reserved for the "inventory" menu. We could also use x if you prefer or leave it undefined.

RESTATEMENT of KEY MAPPINGS

Inaugurated new shortcuts:
- q = toggle Resources view
- w = toggle Immovables view
- e = Terrain menu
- v = Immovables menu
- a = Animals menu
- r = Resources menu

Existing shortcuts (single keys):
f, h, i, t, p, m, space, F1

Reserved shortcuts:
- c = edifice census display
- s = edifice statistics display
- n = messages
- o = objectives
- b = building statistics
- j = inventory

There are a few more things to discuss about behaviour of the new toggle functions.
Results so far:
- we have a short-key assignment for the functions
- we have all-time visible buttons to trigger the toggles

1. How is toggle status indicated in the display?
2. How is button display organised?

Ad 1: Toggle status has to be indicated firmly. This could be some semi-transparent icon in a corner of the display (separate indication), alternatively we can be contended with the button appearance. (I will ignore any opinions that the world itself is 'nuff indication of the status, it isn't!)

Ad 2: Currently (with the "space" function) we have the PRESSED button for function "showing" and the RELEASED button for function "hiding". This corresponds to the running game behaviour. This would mean for the new functions that PRESSED button is the regular and default appearance and stands for showing resources and immovables and RELEASED button stands for hiding resources and immovables. Is that how we want it?

Pressed button means "on", non-pressed button means "off" This is like we now have it for everything, and I see no reason to change it.

Id there a particular reason that you want to change the inventory key from i to j? The editor doesn't have an inventory, so we don't have any hotkey collisions with i = info tool.

Last sentences to F-Keys: Ergonomic disadvantage isn't really a reason for the shortcuts in editor. When creating a map there is no hurry to switch between different views (overlays) and immediately open other windows. IMHO. If somewhen an additional overlay get implemented, it could just be added to an F-key, otherwise one has to find another character-key for it..

> - j = inventory

In Editor there is no inventory. Maybe sometime if the editor is capable for helping with scripting. As explained before there is no need to keep all the shortcuts from in game in the editor (except for global shortcuts).

> ... that PRESSED button is the regular...
> ... RELEASED button stands for hiding resources and immovables.
> Is that how we want it?

From my point of view this behavior would be logical: Pressed = On

1.
>Id there a particular reason that you want to change the inventory key from i to j?

As you will remember it was your wish to reserve the keys for the major functions of the running game. Just in post #11 you agreed that i = information tool, so it is j reserved for inventory now. We can leave "inventory" totally away though, if you prefer.

2.
Any preferences on the topic of indicator icons? I would envisage negative indication, that is an indicator would show when the display function is off. Such an indicator is not strictly required as we can see the button states as indication as well, but they would allow quicker recognition of the states. A bit of a luxury, but we can talk about it, i.e. if there are objections?

What about shortcuts for 'height tool' and 'noise height tool'? And 'set port space'?

Because this bug was initially created for adding "the new toggle-able views "Immovables" and "Resources".", i think we should focus on that issue, and not come to an overhaul of the shortcuts in general.

This could be better done if shortcuts could be modifiable:

https://code.launchpad.net/~widelands-dev/widelands/configurable_hotkeys

or in another bug report. imho :-)

So my proposal is to leave all shortcuts as they are right now and just add the shortcuts which are needed to show the new overlays (when ever they will be implemented).

For the icons we may need an additional entry in the main (bottom) menu called something like "Overlays", or "Views" if you prefer. This will need also a shortcut then :-) This will open a window containing buttons to switch each overlay on (Pressed) or off (Released). But i don't know if this is feasible.

I don't think we need an extra indicator at this point - we have much more important fishes to fry coding-wise. If you would enjoy working on an indicator yourself and can find a good way to make one, there will be no objections though :)

I see no harm in creating more hotkeys without making them configurable at once - hotkey use is optional, so it gives faster access to the tools for people who do a lot of map editing.

I would like to implement a graphical dropdown menu that comes up from the bottom, so it will be feasible to have them in the future. I need to clear my backlog of branches first though.

We could have v for the overlays and b for the immovables.

n is available for for noise height, what is h being used for?

I don't see any serious objections to the following thoroughly worked-out assignment of short-keys. I call for review and file objections, otherwise I would take this state as agreed.

RESTATEMENT of KEY MAPPINGS

Inaugurated new shortcuts:
- q = toggle Resources view
- w = toggle Immovables view
- e = Terrain menu
- v = Immovables menu
- a = Animals menu
- r = Resources menu

Existing shortcuts (single keys):
f, h, i, t, p, m, space, F1

Reserved shortcuts:
- c = edifice census display
- s = edifice statistics display
- n = messages
- o = objectives
- b = building statistics
- j = inventory

What about toggling of bobs/critters? It is missing a shortcut imho.

When I was designing the task, I didn't think of the Animals as something different to Immovables, probably because they don't move in the editor and better handling of the editor was my only purpose. We have to re-think.

SirVer has suggested to separate Animals View from Immovables View. This renders two decisions to be taken

a) is it worth it to have Animals View toggle separated from Immovables?
b) if yes, what short-key is to be set up for Animals toggle?

The questions is whether it makes sense to have one additional toggle-view or this is not causing confusion or extra work for the users?

If Animals Views is to be implemented, we probably have to re-assign the Terrain tool key 'e' in order to have 'q', 'w', and 'e' in a consecutive row on the keyboard for the View toggles, and we don't have many options left for plain keys.

a) this is no question to me. Placing animals under trees for example is quite common in Widelands maps and gets hard if you can only toggle trees and animals all at once.
b) I proposed 'a' for animals, but I agree that 'e' would be preferable.

How about using the CTRL key in combination with the key for the tool menu? It would make it easier to remember the shortcuts, even if it means pressing an additional key. e.g.

a = Animals menu
CTRL+a = Toggle animals overlay

Or the other way around

CTRL+a = Animals menu
a = Toggle animals overlay

@SirVer
Animals don't hinder viewing the woods, so there is only one scenario where you would use the Animals View and that is when you want to see Animals sole on terrain, i.e. without the trees and anything else. There may be occasions where this is useful but I regard them RARE.

I was driven to open this task because I wanted to see a facility to allow the editor to see and handle the TERRAIN bare, without what could hinder viewing, judging and editing it. With Animals sole, if implemented, we have 4 view switches, a bit a lot if you just want to reach at View Bare.

Can you do me the favour and implement a function under key 'x' (without button) which does the following:
i) if there is at least one View disabled, the enable all Views
ii) if there is all Views enabled, then disable all

- - - - - - -
About the key assignements, there is clearly an advantage to stick to the upper row starting with 'q', 'w' and then possibly 'e' for Animal View. If the Animals are to stay, I propose 'u' for Tools menu, 't' for Terrain tool and 'e' for Animal View.

> There may be occasions where this is useful but I regard them RARE.

I do not. I had wished for this when designing maps for scenarios before, that's why I implemented it.

> Can you do me the favour and implement a function under key 'x' (without button) which does the following:

Rather not before it is requested by actual map makers. This is more stuff to learn. Let's wait for user requesting this. Having the hotkeys easy to reach and press should be sufficient I think.

I like your idea of geometrically aligning the buttons (qwer), but this does not work in most key layouts that are not QWERTY or QWERTZ. I have a different suggestion: lets use 1234, 1 doubles for "space" (for symmetry) and the others toggle as the order of the buttons are. I know of no keymap that changes the number row to something else and other tools also use number keys for switching on/off layers. As a bonus we get all the mnemonic keys back for tool shortcuts. We use the numbers in game to save map positions, but I think this has no use in the editor, so we might as well reuse them. What do you think?

We use numbers in the editor for tool size, so it would have to be CTRL+number or ALT+number for either the tool size or the overlays.

> a = Animals menu
> CTRL+a = Toggle animals overlay

I like that idea.

At #31: True, I forgot. My vote is then on ctrl + 1-4 then.

@SirVer
The requested function under 'x' appears simple to implement if you designed the code somewhat structured which I believe you did. So if you can't implement this very simple function on my wish, actually you suck! (That's a quite simple and truthful statement.)

I must ask you to continue organising this task as I resign and don't want to feel responsible for its outcomes any more. Moreover this will be my last attempt at Widelands as the ways of development here I find quite odd and bullyish. Have a nice day!

If you think SirVer sucks, why don't you implement it yourself then, since it's so easy?

At #34: I am sorry if it was unclear in #30, but I do not want to implement this feature - not because it is hard, but because I find it adds unnecessary complexity. This has been my goal and argument all along: let's try to reduce complexity and a use a simple mental model. I think I also laid out good arguments:

- do not couple tools to visualization. It is not what gimp and co does - so would be unexpected - and it decouples everything to simple toggles which are easy to understand.
- do not combine animals + immovable. Animals have their own tool, are already a separated thing so toggling them separately is a simpler mental model. And I also wanted to have this independence when I designed maps.
- As for hotkeys, I really like your geometric arguments (buttons next to each other), but argued that this is hard across different keymaps. So I suggested something along those lines, but different. Moreso my believe is that good hotkeys will make the 'x' feature you wanted unnecessary.

> Moreover this will be my last attempt at Widelands as the ways of development here I find quite odd and bullyish. Have a nice day!

This is sad, I'd hate to see you not contribute anymore. I think you brought up quite a few useful discussions and feature requests. But after rereading everything said in the three merge requests and in this bug report and not finding fundamental flaws in communication: only work and suggestions were critiqued (which is the point of a discussion), never was any personal worth but in question, so I do not see bullying. I think that if you do not enjoy this kind of technical discourse then you will not find joy in the development process of software. I hope you will reconsider.

Sorry to have been a bit curt lat night, that was my suffering from a migraine and being called a bully at the same time...

I certainly do appreciate your balancing and sound design contributions, so I'd be happy as well if you'd stay.

I do notice a pattern in this discussion though that we have gone through before: you sometimes make assumptions about what the codebase should look like without verifying what the codebase actually looks like, and then you get told by us that the world is not as easy as you think it is and that the feature you want won't get implemented easily - I get it if that feels frustrating. We don't deserve being called bullies for that though.

Fixed in build20-rc1