ALT F4 doesnt copy ??

[deadpahn]

Seems like the copy paste keybindings dont work. When I ALT + F4 it prompts me if I want to exit or not. When I try to paste nothing happens.

Im using the version in Linux Mint software repository.

[8bitbubsy]

I don't really know how to fix this issue. Maybe you can check if there's a keybindings setting in Linux Mint somewhere, and remove ALT+F4 that way.

[ludiusvox]

I had to change some settings on mac to actually "use" the function keys, as function keys, I suspect linux may have a similar issue, but a mac is a complete machine, linux is usually a self-installable.

[titanlab]

Right now I use the following dirty hack:

diff --git a/src/ft2_events.c b/src/ft2_events.c
index dfbb977..535a5ba 100644
--- a/src/ft2_events.c
+++ b/src/ft2_events.c
@@ -17,6 +17,7 @@
 #include "ft2_header.h"
 #include "ft2_config.h"
 #include "ft2_diskop.h"
+#include "ft2_edit.h"
 #include "ft2_module_loader.h"
 #include "ft2_module_saver.h"
 #include "ft2_sample_loader.h"
@@ -421,6 +422,7 @@ static void handleSDLEvents(void)
 #ifdef _WIN32
                handleSysMsg(event);
 #endif
                // text input when editing texts
                if (event.type == SDL_TEXTINPUT)
                {
@@ -460,6 +462,13 @@ static void handleSDLEvents(void)
                }
                else if (event.type == SDL_QUIT)
                {
+#if defined(__unix__)
+                       if (keyb.leftAltPressed) {
+                               copyBlock();
+                               continue;
+                       }
+#endif
+
                        if (ui.sysReqShown)
                                continue;

But of course this solution is not clean because it just checks if ALT has been pressed while the quit is processed. And as F4 does not arrive in the window I see no other solution to solve it right now.

I found out that by using Xinput (xinput test-x12) I can receive these raw keypresses (to also catch the F4) but there might be some work involved to get that working properly.

[8bitbubsy]

Ah I see, I thought ALT+F4 only closed programs on Windows, so the real fix is to move line 98 to 101 in ft2_main.c to before the #ifdef _WIN32 line above it. I'll fix it now.

[8bitbubsy]

Hmm, this may only work on Windows:

/**
 *  \brief Tell SDL not to generate window-close events for Alt+F4 on Windows.
 *
 * The variable can be set to the following values:
 *   "0"       - SDL will generate a window-close event when it sees Alt+F4.
 *   "1"       - SDL will only do normal key handling for Alt+F4.
 */
#define SDL_HINT_WINDOWS_NO_CLOSE_ON_ALT_F4 "SDL_WINDOWS_NO_CLOSE_ON_ALT_F4"

[8bitbubsy]

I did make the change anyway, can you try to see if it works now?

[titanlab]

Unfortunately this won't work because SDL_HINT_WINDOWS_NO_CLOSE_ON_ALT_F4 only works on Windows :-(

From Alt+F4 the Linux WM generates a WM_DELETE_WINDOW X11 message even before it arrives in the event queue of the application. No idea what to do here but I found out that by using Xinput you can somehow get that "F4" as Xi2 "RawKeyPress" event. But I neither coded with Xlib or Xinput so no idea how that really works.

[8bitbubsy]

This issue should be forwarded to the SDL2's github repo instead.

[titanlab]

With xev you get

KeyPress event, serial 38, synthetic NO, window 0x4c00001,
    root 0x9b5, subw 0x0, time 10919623, (1115,1220), root:(1165,1408),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 38, synthetic NO, window 0x4c00001,
    mode NotifyGrab, detail NotifyAncestor

ClientMessage event, serial 38, synthetic YES, window 0x4c00001,
    message_type 0x1a3 (WM_PROTOCOLS), format 32, message 0x1a1 (WM_DELETE_WINDOW)

So just ALT, FocusOut, DeleteWindow. No F4.

But with xinput test-xi you can see that RawKeyPress for the F4 key:

EVENT type 2 (KeyPress)
    device: 3 (18)
    detail: 64
    flags: 
    root: 839.00/1468.00
    event: 789.00/1280.00
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x9b5 event 0x4c00001 child 0x0
EVENT type 13 (RawKeyPress)
    device: 3 (18)
    detail: 70
    valuators:

EVENT type 10 (FocusOut)
    device: 3 (3)
    windows: root 0x9b5 event 0x4c00001 child 0x0
    mode: NotifyGrab (detail NotifyAncestor)
    flags:  [same screen]
    buttons:
    modifiers: locked 0 latched 0 base 0x8 effective: 0x8
    group: locked 0 latched 0 base 0 effective: 0
    root x/y:  839.00 / 1468.00
    event x/y: 789.00 / 1280.00
X connection to :1 broken (explicit kill or server shutdown).

Yeah I also think that should be fixed in SDL instead. Maybe SDL3 already supports it?

[8bitbubsy]

I don't think I want to include your fix as SDL_QUIT can be read from the queue in several other instances than pressing ALT+F4.
This would mean that holding ALT while a sigterm is sent to the program would refuse it to be handled. Not very nice...

EDIT: Maybe you could check if F4 was held down as well?

[titanlab]

I don't receive the F4 unfortunately, that's why I only have that as dirty hack :-( I can try to find a way to read the F4 with Xinput but can't promise I'm successful.

[8bitbubsy]

Ah I see, I guess I didn't read properly. I think this issue will have to stay open for now, until SDL2 eventually gets a fix. SDL2 is still getting minor fixes it seems like, even though SDL3 is in development.

[titanlab]

There must be several applications which have the same problem. Most of the people with Linux use a WM like KDE or Xfce to disable Alt-F4 for the affected applications. But I use GNOME and there are only system-wide keyboard shortcuts.

[titanlab]

As possible fix, I thought about taking that before SDL processes its events:

https://gitlab.freedesktop.org/xorg/app/xinput/-/blob/master/src/test_xi2.c#L433

using XPeekEvent instead of XNextEvent and then just checking for the XI_RawKeyPress events to get the F4.

[pivilartisant]

Also have this issue on mac OS Ventura. Control (or any other like alt, command) F4 & F5 does not copy/paste pattern. sampCopy/sampPaste in sampEditor works as expected using command c/command v.

So I tried to switch around SLDK_F4/F5 and SDLK_c/v to be able to use control/command + c/vand I was not successful manipulating the pattern.

[8bitbubsy]

Also have this issue on mac OS Ventura. Control (or any other like alt, command) F4 & F5 does not copy/paste pattern. sampCopy/sampPaste in sampEditor works as expected using command c/command v.

So I tried to switch around SLDK_F4/F5 and SDLK_c/v to be able to use control/command + c/vand I was not successful manipulating the pattern.

Like said on 16-bits.org/ft2.php, you need to disable these global OS shortcuts in macOS. You can do it somewhere in the macOS settings.

[titanlab]

Just FYI, my current fix (GNOME, X11 here) to this phenomena on Linux is still calling

SDL_SetWindowKeyboardGrab(video.window, SDL_TRUE);

at the end of the function setupWindow in src/ft2_video.c... and this works quite nicely! No idea if this can be/is a permanent fix but for me it's fine.

[8bitbubsy]

Well, does ALT+TAB still work as intended (switch between open programs) with this fix?
The SDL2 docs say that it will take over ALT+TAB and other keys, which may not be a good idea.

[titanlab]

Yes, for me it does.

[8bitbubsy]

Got someone with Ubuntu 22.04 to test it, and it didn't work for them. Also on Windows it takes over ALT+TAB, so that you can't switch between open programs with the keyboard. I just think that this is an unreliable solution, so I won't implement it after all...

[megakode]

I would also love a fix that somehow intercepted the keypress in the application.

As a workaround I tried disabling the ALT+F4 hotkey globally in Gnome. That stops the exit dialog from being shown as before, but copy/paste block still doesn't work. Not sure if it's the copy or paste part that is broken though.