> Very strange! I wasn't able to reproduce this (tested on Linux and Mac).
>
> Anything special I have to do to trigger this weird behaviour?

Not that I am aware of.

Level currently in focus is "/usr/share/games/rocksndiamonds/levels/Emerald Mine Club/emc_cosmos_mine_10/22" -- in case EMC engine is a factor.

I started working backwards:

20160419-SDL2 (fixed "fast as possible") -- has the problem
20160418-SDL2 (slow "fast as possible") -- has the problem
20160319-SDL2 (my last previous build) -- DOES NOT have the problem

In 20160319-SDL2 binary, <Ctrl>- and <Ctrl>+ both work from main menu as well as during play.

Furthermore, both <Ctrl>[unshifted-/_] and <Ctrl><keypad-> work; and <Ctrl>[shift-=] and <Ctrl><keypad+> work. But I think this may be a property of that patch I asked you to integrate -- yes -- `git stash -p show` shows that I added references to "KSYM_KP_{Add,Subtract,0}" (as well as, elsewhere, "KSYM_KP_[1..9]" in relation to setting frame delays).

"Work everywhere" was one of the functional properties I intended to add with that patch. I'm not sure which of my old binaries have that patch (obviously 0319, and I think 1-2 before that, but I'm not sure how many).

Well, hmmm. By using the question "Do <Ctrl><keypad[-/+]> work?" as a test for when I put in that patch, I worked backwards and found that 20160223-SDL2 has my patch (and <Ctrl>+/- work everywhere); 20160107-SDL2 is before my patch and behaves the same as this report: grow/shrink both work from main menu; only shrink works in game play.

Aha, I have an idea. I see that my patch also enabled <Ctrl>= (i.e., on US keyboard, unshifted [+/=] key). I vaguely remember that I might have added that not only as a slight convenience, but because I had observed that in game play, the fact that I was holding down <Shift> seemed to get lost; i.e. that only the code intended to handle <Ctrl>= was invoked while playing, regardless of whether I had actually hit <Ctrl>= or <Ctrl><Shift>= (<Ctrl>+). Perhaps '+' is an unshifted key in your keyboard layout, and not subject to this trickery?

Perhaps '+' is an unshifted key in your keyboard layout, and not subject to this trickery?

Somehow I must have missed this detail! It came to my mind again when reading the patch you just sent me (by mail), where I wondered why on earth you added the "<Ctrl>=" key combination as a shortcut for "scale up window"!

I've had a look at an image of a US keyboard layout, and now I understand both the motivation for adding it to the patch, and why there are no problems with "<Ctrl>-", but with "<Ctrl>+" -- because you have to use <Shift> to get the "+", apparently being forced to use "<Ctrl><Shift>=" to get the "scale up" or "zoom in" action!

I wonder how this would be best solved in a way that works for all existing keyboard layouts -- it would have to be something like "<Ctrl> plus the key that is labelled with a '+' sign somewhere on that key". In SDL/SDL2, it seems that I cannot use key scan codes, as there is no corresponding SDL_Scancode value for the SDL_Keycode value "SDLK_PLUS", which I only get when pressing the "=" key together with the "<Shift>" key on a US keyboard layout. Oh well...

I think just adding "<Ctrl>=" as an alternative for "<Ctrl>+" would be a nasty workaround I could add to make this working for the US folks. But there has to be a better (generic) solution for this. Maybe I have to look at the Firefox source code, for example... :-/

I had observed that in game play, the fact that I was holding down <Shift> seemed to get lost

Modifier keys are indeed handled differently in the menu and in the game, as the modifier keys have a special meaning inside the game (potentially being game buttons there), and therefore have to be handled even if pressed without any other key, while outside the game they only behave as "classic" modifier keys, only recognized when pressed together with another key.

I think that mechanical knowledge of the actual physical keyboard layout is theoretically available in most modern operating systems (perhaps moreso on OS/X where the keyboard is almost always an Apple product).

BUT. I think it's often wrong, because on Windows and Linux the user is asked to choose from a list and may often get it wrong; and because vendors supply keyboards which may meet the basic alphabetical layout of some country accurately, but have the "special keys" in whatever sort of weird layout they chose -- especially on laptops.

Plus, even if some layer of the OS has been informed of the real physical layout, it then has to be plumbed through such things as (e.g. on Linux) X11 or Wayland or Mir; its keyboard handling routines; SDL; and only then reaches you. Odds of details being garbled are very high.

Accepting '=' as a synonym for '+' fixes almost all US layouts, which I suspect is > 50% of the keyboards in the world -- not because it's a great layout, not because it's the natural layout for people all over the world, just because lots of HW ships that way and people put up with it rather than trying to specially source a replacement. Especially in smaller countries with more obscure languages: insisting on a country-specific keyboard could restrict you to just a few models whose vendors have bothered to localize to you, while using a US layout lets you choose from hundreds of items.

So my (admittedly shortsighted and self-serving) recommendation is to let Mod-'=' stand in as a zoom key :)

Also noting that, for reasons we haven't yet figured out, <Modifier> plus keypad-Plus, keypad-Minus and keypad-Zero do not work on my machine unless I also hit <Shift>.

I've added the keypad counterparts of keys "0", "-" and "+" to the keys recognized as window scaling shortcuts. (So it works similar to the tile scaling in the editor, which also recognizes the normal and keypad +/-/0 keys.)

BTW: No idea why these keys worked before when you pressed the "Shift" key...

As you used "Alt" in your example: I've also changed it so that only the "Ctrl" key and the "Meta" key (this is the "Command" or "Apple" key on the Mac) is recognized for window scaling, as this kind of scaling/zooming key shortcut never works in conjuction with the "Alt" key, but always uses either "Ctrl" (Linux, Windows) or "Meta/Command/Apple" (Mac) for this functionality. (This also has the advantage that there are more modifier+key combinations available when defining debug key shortcuts(*) with "use_mod_key", as the window scaling key shortcuts have precedence over the debug key shortcuts.)

((*) This is a new feature introduced with one of the last commits that is only available when the game is compiled with "-DDEBUG". Save settings in the setup menu and search for "debug" in the file "setup.conf" for key shortcuts to control the game's frame delay (frame rate) either when playing or game-wide (also in menues).)

since it clearly did work for me until now. However, I'm perfectly happy with these things being restricted to just <Ctrl> / <Apple:Command>.

Sorry, this was a bit confusing. Of course it worked with the "Alt" key in R'n'D before I removed it. What I meant was that (AFAIK) all these text/window zooming shortcuts as known from browsers like Firefox/Chrome/Safari or other programs (like Linux/Mac terminal/console utilities) only use the "Ctrl" (or "Command") key, but never the "Alt" key, so there's no need to support it in R'n'D for such functionality either.