Manuel,
It seems that Wouter is wrong and have some sdl dependencies issues in his machine (typical if you have 2 sdl versions installed)
Imulilla is right, IS A BUG that appears even in other programs ported from SDL 1.2 to SDL 2.0 with exactly same issue and the explanation of the bug is consistent with the same solution that imulilla applied
http://icculus.org/pipermail/quake3-commits/2014-September/002643.html
Log Message: ----------- Fix binding 'context menu' key using SDL2 SDL 1.2 converted Windows' VK_APPS and X11 XK_Hyper_R to SDLK_MENU. SDL2 has it as a separate SDLK_APPLICATION key, so convert it to K_MENU too.
Thanks for that reference. We already thought of doing this additional mapping, but seeing that other projects did exactly the same convinced me to commit it now without doing other tests first. Please try the next build. (Of 4219e5e0e2226eef8e7238ea82326fb973beb51f or later.)
I'd be very happy to hear the results of your tests.
@DrWh0: You should be able to build it on your LTS fine, either with a staticbindist build (in which the openMSX build system will download and compile all necessary dependencies) or a normal build. Provided your LTS as a modern C++ compiler. I think you need g++-6.x or later, for example. Just try it and tell me where it fails.
Or tell me what you mean with 'messing with dependencies'... Did you know about apt-get build-dep openmsx? (If you're on a Debian based distro...) Although this will not pull in SDL2, so these packages need to be installed manually (just some SDL2-dev packages and you should be fine; e.g. libsdl2-dev, libsdl2-ttf-dev.)
What do you mean about Wouter being wrong and having dependency issues on his machine? I assure you he has not! Current openMSX really doesn't build on anything else than SDL2... and I'm quite certain that Wouter knows exactly what he is doing.
Hi Manuel
In first place I want to make clear that I am not trying to say that Wouter does not know what he is doing (of course not!).
Simply I say that, in this particular case, there is a mistake upgrading the code to SDL2 (bugs, old code left behind mixed, nobody is perfect).
Making a mistake is not a crime nor is it anything to be ashamed of, as i said before nobody is perfect and we only wanted to help pointing the error and the solution.
"Shit happens"
Regarding to "messing" I am referring to a phenomenon that occurs in development systems when you upgrade from one version to another and start linking everything frequently there is something left behind kicking your butt in form of a dependecy call or code left behind living along your new version.
Even in Debian is common things like this:
When you create a .deb package you have to specify "a policy" when building .deb file in order to be more or less aggresive in the installation of the package by the final user, asking for specific versions of dependencies (for compability reasons) or simply "recommending the version" of the dependencies.
So when you install a program that shouldn´t interfere with your normal work............it leaves something behind and mixes with another
Before you realize, you have some incompatibilities in the system because you or someone installed some program that is supposed to touch nothing important but corrupts your development environment.
That means that Debian devs don´t know what are they doing? of course not, sometimes the most simple and stupidest thing can make you mad..
"Shit happens"
I have just tested the windows builds and both works ok.
Bug Solved in Windows (I still have to test on linux build when I have spare time)
Thanks!
OK, thanks for confirming.
Apparently, there is some Windows specific thing regarding this key that wasn't Windows specific in SDL1.2. This change is not documented anywhere as far as I can tell and the people in the SDL IRC channel didn't respond to my questions. Luckily the people who made that commit to that Quake git repo figured out what was going on.
I'm not sure what you mean with 'stuff left behind', but I wasn't thinking about creating Debian packages. Just compiling openMSX from source. Usually the packages that come in Debian are of very good quality and do not leave anything behind that should cause any trouble.
Anyway, for openMSX you only need to install normal packages from the repo and compile openMSX, optionally install it in an isolated place like /opt/openMSX and then just run it. No risks on corruption of anying, no issues, I think...
So, let me know how it goes for you and where I can help with compiling and running the latest openMSX on your Linux box.
Also, if you find anything else broken (e.g. due to our migration to SDL2), please do let us know, so we can fix it.