Nestopia recognizes Meta L key, but refuse to use it

[TCH68k]

I've set Turbo B to Meta L and Nestopia got it right. But when i press Meta L, Turbo B does not happen. If i set it to Alt L, it works. Somehow it refuses to use it, even if it understands it.

Screenshot attached.

[rdanbrook]

It is an FLTK bug. There is a workaround in place for non-Apple platforms right now to deal with bad behaviour from GNOME, which is (somehow!) the most popular Linux desktop environment. It spams keyup events when the key is held down, which really messes up keyboard based emulation input. For this reason I have to use Fl::get_key in order to make it play nice with GNOME. I can give you a diff that fixes it, assuming you're not using GNOME:

diff --git a/source/fltkui/fltkui.cpp b/source/fltkui/fltkui.cpp
index 5382526..95d8e84 100644
--- a/source/fltkui/fltkui.cpp
+++ b/source/fltkui/fltkui.cpp
@@ -606,16 +606,7 @@ int FltkUi::handle(int e) {
 int NstWindow::handle(int e) {
     switch (e) {
         case FL_KEYDOWN: case FL_KEYUP: {
-            #ifdef __APPLE__
             inputmgr->event(Fl::event_key(), e == FL_KEYDOWN);
-            #else
-            // GNOME has a bad habit of spamming keyup events while holding
-            // a button down, so Fl::get_key is required here.
-            int key = Fl::event_key();
-            bool down = Fl::get_key(key);
-            inputmgr->event(key, down);
-            #endif
-
             if (jgm->is_loaded()) {
                 inputmgr->ui_events();
             }

I obviously can't push this because it will break keyboard input for the majority of Linux users. I think the FLTK bug should be fixed instead, which is that it cannot detect the Meta/Super key with Fl::get_key. I tested using 1.3.11, but need to test with 1.4 on my other machine before filing an issue.

[TCH68k]

Thanks, i do not use GNOME. :) (I use TDE (KDE3).) However, it still does not work. :( Sorry, i am retarded and i did not noticed, that my buildscript is flawed and did not apply your patch. It does work.

BTW, cannot this be pushed with some other macro check? I mean, instead of

#ifdef __APPLE__

it would be

#if (defined(__APPLE__) || (defined(NOT_APPLE_BUT_NOT_GNOME))

and NOT_APPLE_BUT_NOT_GNOME could be defined via configure.

[TCH68k]

I tested using 1.3.11, but need to test with 1.4 on my other machine before filing an issue.

I've just compiled FLTK 1.4.4 and recompiled Nestopia with it. Still not works, so if this is an FTLK bug, then it is still persists in 1.4 too. (I did not try 1.5 though, it seems to be a big change from the former FLTK versions.)

Edit: Funny thing: if i press Alt L along with Meta L, then Turbo B activates and stucks (it thinks it is still pressed after release) and it remains such, until Meta L is not pressed again.

Edit 2: This of course is only valid, if your patch is not applied. If it was, then it works perfectly. Thank you.

[rdanbrook]

Using a compile time check isn't going to work here, but an environment variable check at runtime could be a solution. Really though, the FLTK bug should be fixed, and in an ideal world GNOME would handle held keys more gracefully.

[TCH68k]

Why won't a compile-time check work? If it is an option for the compiling user, that the used environment is not GNOME? I don't know how you pass -DNOT_APPLE_BUT_NOT_GNOME to CMake via CMake options, but it should be easy.

You're right in the FLTK bugfix matter, that should be fixed. But you really should not expect sanity from GNOME developers. :(

[rdanbrook]

GNOME is not a platform or OS, so there is not a compile time solution like this. I think __APPLE__ actually comes from SDL and there is something else underneath that which SDL checks. There are other platform specific defines on Windows. An environment variable can be checked at runtime to determine what desktop environment is currently in use though.

[TCH68k]

No, no, you misunderstand me. I am not talking about an autimatic decision here. I am talking about the user specifying that the used ecosystem is not GNOME. The user specifies manually before compiling (in a CMakeLists.txt file, or whatever), that the used ecosystem is not GNOME, then the flag is passed to the buildsystem and the macro there is activated.
This is what i am talking about, not that the build environment somehow checks that we are under GNOME, or not. (I do not even know how to do that.)

[rdanbrook]

That still isn't a solution, because distros then have to choose for the user. This is what the solution will end up looking like: https://stackoverflow.com/questions/3496774/detect-desktop-environment-in-linux-programmatically-in-c

[TCH68k]

Why would they have to? Does not the user knows what desktop environment he uses?
I do not understand the link either. That SO thread is about detecting the DE from C and the answers are trying to answer that, but i am not talking about detecting the environment from C, i am not talking about detecting the environment at all. I am talking about specifying the environment not being GNOME. Like
sed -i CMakeLists.txt 's/IS_DE_GNOME=true/IS_DE_GNOME=false/' and somewhere in the CMake "scripting" (i don't know how does it work):

if (!IS_DE_GNOME)
	CFLAGS += '-DNOT_APPLE_BUT_NOT_GNOME'
endif

And that is it. I am not talking about any kind of detection from any kind of language. I am talking about specifying that we are under GNOME, or not. And that manual definition can determine if the GNOME branch should be used by the preprocessor, or not.

[rdanbrook]

Most users are not compiling on their own. The majority of users are on the distro-supplied package or the Flatpak distribution. In those cases, it cannot be assumed what desktop environment the user is on. What you are proposing will work as you have designed it, but it creates new problems. Even if a distro packager wants to turn off the GNOME-specific behaviour at compile time, I'll end up with bug reports from GNOME users on that distro pointing out that keyboard input is broken. This is why it has to be a runtime check. This isn't a really big deal, I already use getenv in this codebase, like in the following snippet:

    if (const char *env_xdg_data = std::getenv("XDG_DATA_HOME")) {
        basepath = std::string(env_xdg_data) + "/nestopia";
    }
    else {
        basepath = std::string(std::getenv("HOME")) + "/.local/share/nestopia";
    }

Basically the solution will be to check if XDG_CURRENT_DESKTOP is GNOME and enable the workaround if it is.

[TCH68k]

Okay, i see your problem now, but i think this problem can be workarounded by the package maintainers shipping two packages: one is for GNOME and one is for not. Of course, this requires the co-operation of maintainers.

But a runtime check of XDG_CURRENT_DESKTOP at startup can work per se. Assuming that someone or something does not overwrite it and set it to GNOME under KDE, or to KDE under GNOME. (Don't ask why would anyone or anything do this; who knows...? Anything can happen.) So, it is not foolproof.
Checking whether gdm is running would be much safer, i think.

But something now occurred in my mind: does this bug plague all GNOME versions, or just GNOME3 and beyond? Because if it is the latter, then somehow you have to check the version too. I know not a lot of people uses GNOME1 or GNOME2 nowdays, but they might install an older distro onto a retro-PC.
But, on the other hand, if it does affect all GNOME versions, then the GNOME2 fork MATE is affected as well, and XDG_CURRENT_DESKTOP will not contain GNOME there.

This is way more convulent than i thought at first... :/