close without saving shortcut

[51n7]

The ability to hit cmd+d to close save dialog boxs and discard file changes, matching macos behaviour.

[RedBearAK]

@jonbestdev

The ability to hit cmd+d to close save dialog boxs and discard file changes, matching macos behaviour.

Where exactly is this supposed to work like this in macOS? If I try to close an edited file in TextEdit.app the Cmd+D shortcut just changes the save location to "Desktop" and doesn't activate the "Delete" button at the bottom of the dialog. This is from testing on Big Sur. And Ctrl+D is used for other things depending on the app. In Gedit text editor it's "Delete current line", so remapping that in a way that would apply to a save dialog would block that built-in function in the overall app.

I've looked into it but I don't see how this could be implemented without interfering with the other uses of the shortcut in various apps. Or even what it should be remapped onto to make it work. In the simpler "Do you want to save this?" type of dialog in Linux, you can usually just hit tab or tab-tab and then hit space to activate the "Close without saving" button with the keyboard. Normally just tab, because the "Save" button will be the default highlighted button, and tab will move the highlight to the "right" which will wrap it onto the "Close without saving" button which will normally be on the far left of the three dialog buttons. But this all depends entirely on how each app chooses to implement their "Save this?" warning dialog.

[rbreaves]

I will need to merge this PR into my fork for this request to even be a thing - otherwise pop up windows inside of an app have no way of being deciphered from the main app itself.

The main reason I requested this feature several months ago was for Remmina (I wanted remaps to happen in some windows, but not others). Same concept can apply here, set certain remaps for some pop up windows within an app, but not other parts.

https://github.com/mooz/xkeysnail/pull/129

[rbreaves]

Not yet tested but I have at least merged that PR by Lenbok into my Kinto xkeysnail fork, it can be checked out on this branch and installed manually at any time. If it is confirmed working I will merge it into the actual Kinto branch which is the branch the installer uses.

https://github.com/rbreaves/xkeysnail/tree/kinto-wmclass

As mentioned in that 129 link above, how to use it is like the following.

define_keymap(lambda wm_class, device_name, wm_name: "Google Docs" in wm_name, {
    # Google Docs uses M-slash as an execute-extended-command binding, let's make it more emacsish
    K("M-x"): K("M-slash")
})

Just now realizing I named the branch wmclass when I meant to name it wmname.. oh well lol.

[RedBearAK]

@rbreaves

I will need to merge this PR into my fork for this request to even be a thing - otherwise pop up windows inside of an app have no way of being deciphered from the main app itself.

Yeah, I was hoping you'd merge that sometime soon, so I can go on the attack with some WM_NAME fixes of various things. I'm just not that comfortable with trying to run a dev branch to get an early peek at that functionality.

Have you actually seen any issues reported with it, or seen any issues yourself? Or have you just not tried it at all?

[rbreaves]

@yoshinari-nomura is the only user I have seen that says that it works. Of course I handle buttons a little differently than the main branch, so I had to retain that when merging just now. But I guess I can setup a scenario with Remmina to test this as working or not.

I forget what it was exactly but I broke how some consecutive hot key configs worked for some users of the mainline and until I split that out properly I don't think my Kinto branch can be merged again. I am surprised that they haven't updated xkeysnail at all in 2021. It's a really under appreciated project imo - and remappers like xremap or keyd might end up over taking it at some point imo. They are already gaining Wayland support, with some DEs while xkeysnail is kinda sitting still.

[rbreaves]

@RedBearAK And yea that merge has failed.. not sure why yet something is seen as a string but needs to be converted to an int it seems.

[RedBearAK]

@rbreaves

Just now realizing I named the branch wmclass when I meant to name it wmname.. oh well lol.

No time like the present to rename it, before any idiot like me starts messing with the branch.

@RedBearAK And yea that merge has failed.. not sure why yet something is seen as a string but needs to be converted to an int it seems.

If you can get to a point where it's mergeable, I can make the effort to spend some time testing it. It would really be a quantum leap in forcing Linux windows to behave consistently.

[51n7]

Where exactly is this supposed to work like this in macOS?

@RedBearAK sorry I should of been a bit clearer, on macos cmd + d only works on the simpler "Do you want to save this?" dialog boxes. I didnt account for the TextEdit.app example where it's promting for a save location. A use case would be the mac mail.app when closing an email draft I'll hit cmd + w followed by cmd + d (not releasing cmd) to close the window and then imediatly discard changes.

It looks like this is a universal mac feature as I've found it works in every other case I'm promted to save changes (not when choosing a location to save the file). A few other quick example with the close dialog are the Adobe/Affinity Suite and sublime/vscode. This only works in close promts too so would not interfere with default application keybindings.

[RedBearAK]

@jonbestdev

This only works in close promts too so would not interfere with default application keybindings.

The limitation of Kinto currently, which is a limitation of xkeysnail, is that if you make a key remap for "Application XYZ", it applies for all windows that have a WM_CLASS attribute of "application-xyz", or whatever the WM_CLASS happens to be (it's often very different from the visible application name). That means the key remap can't really be limited to a child window or modal dialog. It will always apply to the entire application and all related windows.

To see these attributes you can run this command in a terminal and then click with the mouse cursor on the window you want to identify. This only works, and xkeysnail only works, if you are using X11/Xorg instead of Wayland.

xprop -spy | grep -i wm_class

There is also an attribute WM_NAME that will potentially give finer-grained control over which window receives a key remap overlay. That will eventually help in a lot of situations. But the branch with the patch to enable that is not ready yet.

However, even if that branch becomes available, there's still the problem that, yes, this may work well for you in numerous places in macOS because Mac app devs try to conform to Apple's dev guidelines, but there may not necessarily be a specific shortcut that would do the same thing on similar dialogs you'll see in Linux. The Escape key will normally trigger the "Cancel" button on dialogs, that's pretty standard. But unless you can identify a keyboard shortcut that works for this when Kinto is disabled, in all the dialogs where you want it to work, it probably can't be implemented and made to work the way you expect.

Looks like if I hold down the remapped Alt key (physical Win/Super key) while the dialog is showing in Gedit, it shows the "w" character underlined for the "Close without saving" button. So Alt+W (physical Win/Super+W with Kinto active) can activate that button. Maybe that will be applicable to other GTK apps. It's really going to depend on how each type of application you use chose to implement this type of dialog.

So whenever you see one of these dialogs where you would normally use Cmd+D, hold down the Win/Super key (if you have Kinto enabled) and see if it shows you an underlined shortcut key. Keep a list of what you see in each application. That will at least help give some idea of how feasible it will be to make this work.

If you've got the patience you should also run this command and make note if the modal dialog actually has a different WM_NAME attribute than the parent window:

xprop -spy | grep -i wm_name

If the dialog doesn't have a different WM_NAME or the WM_NAME is missing or blank/empty, that's a problem. I just tried this on the Gedit "Do you want to save this?" dialog and the WM_NAME is blank. Not a good sign.

Meanwhile the actual "Save As" dialog has a WM_NAME of "Save As". How about that. So that is a case where the WM_NAME patch to xkeysnail can enable doing some useful things.

But in your case it's not looking likely this can be solved easily.

Probably best to put a pin in this one.

A use case would be the mac mail.app when closing an email draft I'll hit cmd + w followed by cmd + d (not releasing cmd) to close the window and then imediatly discard changes.

Depending on the mail app you've chosen to use in Linux as an alternative to Mail.app, there may be a specific keyboard shortcut to make it work, but it would only apply to that app. But in Thunderbird Ctrl+D puts a new task on the calendar.

I think your best option to live with this in Linux is just to train yourself to hit Tab or Shift-Tab until the right button is highlighted in the dialog, and then hit Space. This should work for basically any standard GTK or Qt (KDE Plasma) dialog, maybe even in Java apps, and lets you activate any button with the keyboard, not just a specific "Don't Save" button. The highlight I'm referring to is usually a thin blue outline, or some other kind of highlight that moves around between buttons as you Tab, but not the button that is filled with color, which usually indicates which button will be activated if you hit Enter.

Sorry I don't have better news.

[RedBearAK]

@jonbestdev

I forgot that you may need to activate a setting in Keyboard preferences in macOS to make sure that you can do this Tab-Tab-Space and activate dialog buttons with the keyboard. But it should work fine in Linux dialogs, and in Windows.

In macOS it's in System Preferences > Keyboard > Shortcuts. Look for a checkbox down at the bottom of the dialog that says something similar to: "Use keyboard navigation to move focus between controls". This is what it says in Big Sur, but it said something a little different in earlier versions of macOS, so you may have to look around for it.

This is a setting that is off by default. You have to always enable it on a new macOS user account or new computer, so it may be something you've never enabled or used before. A lot of Mac users never enable this feature and don't know it exists.

I suspect this might be the case for you or you probably wouldn't be relying on this Cmd+D shortcut. It's convenient, but in most cases Tab+Space will be almost as convenient.