search

rbreaves / kinto

Mac-style shortcut keys for Linux & Windows.
http://kinto.sh
GNU General Public License v2.0
4.27k stars 214 forks source link

Conflict between General GUI and Sublime Text #702

Open joshgoebel opened 2 years ago

joshgoebel commented 2 years ago

Describe the bug

There are conflicting combos:

# General GUI
K("RC-Super-f"):K("Alt-F10"),                   # Default SL - Maximize app (gnome/kde)

And a valid Sublime combo (added myself):

# Sublime Text 4
K("Super-C-f"): K("F11"),                   # full screen

I'm not sure what to do about this. They are both full screen so should we add a small keymap for Sublime in FRONT of the General GUI keymap to grab that keystroke when it's inside Sublime?

Right now keymaps are evaluated in the order they are defined, so it's finding the combo in General GUI and stopping there, but Alt-F10 isn't the combo that Sublime needs.

Expected behavior

The Sublime Text combo works.

joshgoebel commented 2 years ago

I feel like this is a good argument for some more metadata on keymaps... so we might say "this one is broad DE/GUI, etc" and that would allow other keymaps that say "i'm more specific" to automagically lay new keys on top...

Like in this case it's obvious that Sublime Text (a single app) is more specific than "the whole desktop experience"... but we currently have any way to codify that (without extra out-of-order keymaps).

joshgoebel commented 2 years ago

Actually if none of application combos mess with the General GUI combos then really General GUI should come LAST, after all the apps - so that it doesn't override any of them...

I think that would be much safer too. Right now General GUI can send the wrong keypresses into any app "accidentally" even if that app itself handles that key already... are there examples where this could have a really bad outcome? I'm not sure... it seems far safer to let the apps override "General GUI" if you're inside that application - then it's combos win.

I'm not sure if this would break any existing things. There doesn't seem to be any rhyme/reason to the existing order of keymaps (that I can see)...

joshgoebel commented 2 years ago

Or is this a case where the Kinto script (had I run it) would have commented out some of those lines? i didn't know it did that - I assumed it only UNCOMMENTED lines...

RedBearAK commented 2 years ago

@joshgoebel

Actually if none of application combos mess with the General GUI combos then really General GUI should come LAST, after all the apps - so that it doesn't override any of them...

I have argued for this in the past. I've run into this issue with some terminal shortcuts.

At present, in order to get a few terminal shortcuts working, there has to be a small secondary termStr block of "special overrides for terminals" that comes above the "General GUI" block, so that it overrides conflicting shortcuts that also exist in the "General GUI" block. I've never understood why the general block doesn't just come at the very end of the file. There doesn't seem to be any particular reason for terminal stuff (or anything else) to go after that block.

rbreaves commented 2 years ago

And I believe my reasoning has been what sits in General UI ought to be truly universal in that those hotkeys don’t change or get over ridden by other apps in macOS - because developers clearly know what the OS level key maps are & either can’t or won’t supersede them.

Granted that means some apps will seemingly lose their hotkeys in Linux or Windows till they are corrected but things like wordwise hotkeys are non-negotiable & should work throughout.

joshgoebel commented 2 years ago

And I believe my reasoning has been what sits in General UI ought to be truly universal in that those hotkeys don’t change or get over ridden by other apps in macOS - because developers clearly know what the OS level key maps are & either can’t or won’t supersede them.

I feel we're talking about two entirely different things. There are so many different facets here it's hard to discuss.

  1. First, we should separate "OS-level" shortcuts from per-application. (on the Mac side)

Full-screen is not an Mac OS-level shortcut on Apple OS in the same way that say, Cmd-Space is. Apple's own apps have even had different hotkeys for full-screen over the years- not to mention what 3rd party apps do. Apple's own apps have inconsistent shortcuts in other areas as well... this is likely because "full screen" isn't a common experience on Mac OS... there are variations in HOW the app is full screened that only the app can know - does it fill ALL monitors? Does it blank some monitors? etc...

_We should be very careful in differentiating what is "OS-level" - keys that the Mac "window manager" or Dock owns... vs what are merely strong conventions.

  1. We should also realize there are no "OS-level" shortcuts on the Linux side, period. Per DE (and software built with a single toolkit), perhaps. But linux is ~ 100,000 apps, 100 WMs/DEs 20 different GUI toolkits... there are no truly global hotkeys. This is proven by the fact that we need per-application keymaps in the first place - that we can't just map all the conventions at a high level and be done with it.

Finally, we're not talking about "overriding" anything here on the MacOS side... This issue is consistency on the Mac OS side - to deal with the lack of consistency on the Linux side (which is an impossible problem and not something we can change or fix).

What we want it to do:

As I've already pointed out even on Mac full screen shortcuts have not always been consistent... but in this case we're talking about perfect consistency - on the input side - which is what we should be caring about.

I don't see how this is "overriding" any thing at all... The fact just is that there is nothing magical about Alt-F10 on LInux... at BEST it's a common convention that some (not all) WMs have agreed upon... it's obviously not universal when it comes to applications, or this topic wouldn't have come up.

Moreover, we already acknowledge this inside "General UI" that LInux shortcuts are NOT consistent at an OS level... take for example:

    # K("Super-Right"):K("Super-Page_Up"),          # SL - Change workspace (ubuntu/fedora)
    # K("Super-Left"):K("Super-Page_Down"),         # SL - Change workspace (ubuntu/fedora)
    # K("Super-Right"):K("Super-C-Up"),             # SL - Change workspace (popos)
    # K("Super-Left"):K("Super-C-Down"),            # SL - Change workspace (popos)

Pop OS and Fedora have very different keys for "change workspace"... but we shoudln't care about that... what we should care about is the "mac side" experience... which we achieve by mapping those keys to the correct keystrokes in linux. I don't see why this would be true at the DE level but not true at the application level. My understanding is that if it's possible with the keymapper the goal is highest fidelity (vs a real Mac)...

That is exactly what this issue is proposing - that we fix our Mac side to behave exactly as it does (most often) on a real Mac. I'm not sure what the argument would be against that - I thought that was the entire point of the project? And it's all done withing the keymapper...

joshgoebel commented 2 years ago

I'll acknowledge there is a small technical issue here that changing the sequencing might potentially allow apps to override "General GUI" in the future in negative ways - ways that would break the consistency of the "Mac side" experience. Though that is clearly not what is requested here.

To that objection I'd simply point out that we own the file. Making sure someone doesn't come along later and add a Super-Tab keystroke to Sublime Text 4 and frack everything up - that's our job as maintainers/contributors to the project when we review PRs.

I don't really see that becoming a huge issue, and it's also something we could easily police with software if we were truly worried... just off the top of my head, split General GUI into:

Things like app-switching behavior could remain in the OS-level keymap (at the top of the stack)... things that were looser conventions that sometimes apps need to override could be moved into "common conventions" at the bottom.

That's not the only solution, but would be an easy one - if we were super afraid that just managing this during PR review was going to be problematic.

joshgoebel commented 2 years ago

Worse yet right now we're super consistent.

All these are allowed to potentially override General GUI (and in some cases do) - why is Sublime Text 4 excluded from the party?

It's clear there are plenty of things in "General GUI" right now that are not OS level... because we already allow some applications to override them... like "RC-Left" (just to give one example).

joshgoebel commented 2 years ago

Sorry I get passionate and wordy about things. :)

joshgoebel commented 2 years ago

Seems this is not consistent across time and the larger matter (going full screen) requires a new issue, which I'm making now.

RedBearAK commented 2 years ago

@rbreaves @joshgoebel

Sorry I get passionate and wordy about things. :)

Welcome to the club. It's good to get fired up sometimes. You must type at least 100wpm too.

You're absolutely right that the goal is to provide the same consistency we enjoy while using an actual Mac. And Kinto has generally done a remarkable job at that.

Anyway.

As we all acknowledge in different ways, there are collisions and inconsistencies when trying to bring Mac shortcuts into Linux/Windows. But for the moment there is a simple solution to this kind of overlap that is stopping the Sublime override from working. The "General GUI" block should be at the very end of the config file.

There's really very little overlap with other blocks, even the terminal block has only needed a couple of overrides, everything else in that block works fine, hence there is no conflict with the general block, so reversing the order shouldn't be an issue. So there's no good reason that I know of not to move everything above "General GUI" until a more flexible method of precedence can be developed. It's not really going to harm the "General GUI" shortcuts. Unless I'm really missing something.

And leave a note at the end of the file that no new keymaps for specific apps should go at the end of the file, but rather somewhere above "General GUI". To avoid this kind of failure to override a general shortcut.

There should actually be a clearly designated area somewhere in the config file where users are encouraged to place their own custom app keymaps. When I put mine in I just sort of picked a spot with somewhat related apps. Like when I stuck the Finder Mods in right above the browsers keymaps.

Yeah, people may make mistakes when adding custom shortcuts and somehow step on a general shortcut, but our job is just to avoid those mistakes in the default config file so things at least start out making sense. And come up with a better solution for protecting specific system-wide shortcuts later.

Keep it simple. Re-order the blocks with "General GUI" last and everything will be fine. For now.

joshgoebel commented 2 years ago

To be clear I don't think #709 is a blocker for this issue.

rbreaves commented 2 years ago

I’ll try & get around to doing more testing later & re-arrange the code blocks to see what I think. I can’t really get as wordy at the moment in my response but I’ve mostly read your argument & yes the point of Kinto is to be mac accurate & for the user to not need to concern themselves w/ which distro or de they are using.

joshgoebel commented 2 years ago

Re-arranging should have no visible/noticeable effect at all unless you already have other broken/overlapping keystrokes (below General GUI) - in which case they would start working... otherwise (if there is no combo overlap) the order shouldn't change any behavior.