Closed wdfinch closed 3 years ago
It seems that b5854ee is working properly. This was the prev version I was using.
Perhaps the PR a user made to try and include more jetbrains products was a bad regex. The regex checks out on www.regex101.com though :/ and surely it supports more properly than less. I don't really see anything else in the diff that can explain the problem though.
diff kinto-b5854ee.py kinto.py
110c110
< define_keymap(re.compile("jetbrains-idea", re.IGNORECASE),{
---
> define_keymap(re.compile("^jetbrains-(?!.*toolbox).*$", re.IGNORECASE),{
211a212,220
> K("RC-Key_1"): K("M-Key_1"), # Jump to Tab #1-#8
> K("RC-Key_2"): K("M-Key_2"),
> K("RC-Key_3"): K("M-Key_3"),
> K("RC-Key_4"): K("M-Key_4"),
> K("RC-Key_5"): K("M-Key_5"),
> K("RC-Key_6"): K("M-Key_6"),
> K("RC-Key_7"): K("M-Key_7"),
> K("RC-Key_8"): K("M-Key_8"),
> K("RC-Key_9"): K("M-Key_9"), # Jump to last tab
235c244
< K("RC-Shift-Grave"): K("M-Grave"), # Default not-xfce4 - Cmd ` - Same App Switching
---
> K("RC-Shift-Grave"): K("M-Shift-Grave"), # Default not-xfce4 - Cmd ` - Same App Switching
260a270,272
>
> # Fn to Alt style remaps
> K("RM-Enter"): K("insert"), # Insert
344c356,359
< K("Super-c"): K("LC-c"), # Sigints - interrupt
---
> # K("Super-c"): K("LC-c"), # Default - Terminal - Sigint
> # K("Super-x"): K("LC-x"), # Default - Terminal - Exit nano
> # K("M-c"): K("LC-c"), # Chromebook/IBM - Terminal - Sigint
> # K("M-x"): K("LC-x"), # Chromebook/IBM - Terminal - Exit nano
354a370,373
> # K("Super-c"): K("LC-c"), # Default - Terminal - Sigint
> # K("Super-x"): K("LC-x"), # Default - Terminal - Exit nano
> # K("M-c"): K("LC-c"), # Chromebook/IBM - Terminal - Sigint
> # K("M-x"): K("LC-x"), # Chromebook/IBM - Terminal - Exit nano
449a469,475
> # K("M-Tab"): pass_through_key, # Default not-xfce4 - Cmd Tab - App Switching Default
> # K("RC-Tab"): K("M-Tab"), # Default not-xfce4 - Cmd Tab - App Switching Default
> # K("RC-Shift-Tab"): K("M-Shift-Tab"), # Default not-xfce4 - Cmd Tab - App Switching Default
> # Cmd Tab - App Switching Default
> # K("RC-Tab"): K("RC-backslash"), # xfce4
> # K("RC-Shift-Tab"): K("RC-Shift-backslash"), # xfce4
> # K("RC-Grave"): K("RC-Shift-backslash"), # xfce4
451,452d476
< K("RC-Tab"): K("RC-F13"),
< K("RC-Shift-Tab"): K("RC-Shift-F13"),
Can you reproduce the issues? I can make a screen recording showing the issues as well.
Tbh I have never installed Jetbrains IDE under any Linux distro but I am in a situations where I can easily do so now lol. Odd to support something I've not actually tested first hand but I had the documentation and I did test it under Windows so I felt like it'd be close enough to safely convert to the Linux version, which I do typically test just as thoroughly.
Gotcha. I would really appreciate if you could see if you can reproduce this. Jet Brains IDEs are some of common programs run on Linux so it would be great if we could figure this out. I use it everyday for work.
I can't seem to duplicate your problem unfortunately. I even uninstalled Kinto and reinstalled from the latest master.. no dice. Either version seems to pretty much remap with the same reliability for me over here on Ubuntu Budgie 20.04.
And actually the latest commit has a few more things listed in the diff but nothing breaking and would impact Jetbrains
diff kinto-b5854ee.py kinto.py
13a14,26
> mscodes = ["code","vscodium"]
> codeStr = "|".join(str(x) for x in mscodes)
>
> # Add remote desktop clients & VM software here
> # Ideally we'd only exclude the client window,
> # but that may not be easily done.
> remotes = ["org.remmina.Remmina"]
> remotes = [client.casefold() for client in remotes]
>
> # Add remote desktop clients & VMs for no remapping
> terminals.extend(remotes)
> mscodes.extend(remotes)
>
27,29d39
< mscodes = ["code","vscodium"]
< codeStr = "|".join(str(x) for x in mscodes)
<
> # None referenced here originally
> # - but remote clients and VM software ought to be set here
> # These are the typical remaps for ALL GUI based apps
> define_keymap(lambda wm_class: wm_class.casefold() not in remotes,{
235c257
The additions in the latest latest add support for Remmina (FreeRDP), so that remote sessions can occur without remaps happening so that Kinto can run locally on the Windows or Linux destination (xrdp). Again nothing that I can see as being breaking to Jetbrains :/.
And what do you mean by random? You're just not getting the right keymaps at all, part of the time, reliably the wrong key or do the hotkeys randomly change their function even when you press the same hotkey? That would be wild if the shortcut keys were randomly changing after one press to another, but I don't think that is what you meant when you said random lol.
Ok thanks so much for checking. Maybe I just needed to restart or something. Let me try this again and see I find anything.
So after some more inspection, it seems like running WebStorm (the IDE I'm using) is changing the behavior of Kinto and the keys that it maps to. I've made a screen recording to show what's happening. Maybe this is a WebStorm only issue.
So for example, once I start WebStorm, kinto will map command + G to F3. There are many more keys that have their behavior changed aside from this.
https://drive.google.com/file/d/1XEGH_uCvffAZkTqCnZ2ijHIS9B53J8iY/view?usp=sharing
Edit: I updated the link so anyone can view it. My bad.
To help with your debugging there is a version of xkeysnail that I was working on that has more debug output, but the changes in 0.4.x breaks some things, Alt-Tab specifically I think, I need to patch it or rewrite some of my own contributions.
The main difference is that I have gotten rid of the Anonymous keymap stuff and put in descriptions, added in the transformation happening as well - not just the keys you are pressing as xkeysnail does by default.
Regardless if you do this in the kinto directory and reinstall it you can see more debug output that may tell you what you want to know. Remove the old xkeysnail folder inside the kinto repo folder
rm -rf ./xkeysnail
git fetch origin debug
git checkout debug
./setup.py
Then from the app or system try run the Debug under help. If all goes well you will see your wm_class names, the
When you are done testing though I'd go back to master. Just delete the xkeysnail folder and checkout master and reinstall.
rm -rf ./xkeysnail
git checkout master
./setup.py
Would I send you the logs? I'm not sure I could figure out the issue based on the logs since I'm not very familiar with the internal workings of kinto? Would doing a clean install of kinto help? Is there some issue from an older version?
I don't think I will need logs, installing Webstorm right now and will follow along with the video provided.
Ok thanks so much. Let me know what you find and if there's anything I can do to help.
I think I see the problem and was just taking some time to confirm it before saying it.. but Kinto was actually broken BEFORE in the earlier update, not in its current form however.
You've learned the Linux/Windows hotkeys for Jetbrains, not the macOS ones. I'd suggest that you simply remove the Jetbrains block of code from ~/.config/kinto/kinto.py or fork my project and maybe do a particular type of merge method to consistently apply your modifications on top of my releases?
The point of Kinto is to keep all hotkeys aligning with macOS's version of Jetbrains or any app and when you started to use it I had only applied it to jetbrains-idea wm_class name.. another Kinto user sent me a PR that correctly applies the keymaps I've had in Kinto to all of their products more or less from what I can tell. I do understand that it makes it a little bit confusing though when apps still tell you the old keymap in the GUI menus, not much I can do about that atm. Custom menus for Vala Global Menus would be amazing though.. not that you're using a global menu from that screen share video.
So I will be closing this ticket, perhaps in the future I can provide a checkbox for people to exclude certain apps from gaining macOS keybinds when installing Kinto.
https://www.jetbrains.com/help/rider/Keymaps_Comparison_Windows.html#context_navigation
https://www.jetbrains.com/help/rider/Keymaps_Comparison_Mac.html#context_navigation
A complete list of the IntelliJ macOS keymaps compared to Linux and Windows can be found here in my Universal Keys repo, the original plan was to flesh more of these out and even start cross references against other similar apps to build as the name suggests a Universal way applying any programs keymaps to another in a logical manner.
https://github.com/rbreaves/Universal-Keys/blob/master/Programs/IntelliJ.csv
The project was also going to serve as the basis of dynamically building out all keymaps for Kinto but at the moment I just don't have the time to build out all of the logic needed to leverage Universal keys in an automated fashion. I will update it in the future if, when and before I add additional keymaps to Kinto if it involves a lot of keymaps for a large app however.
I will also note that JetBrains is not like Adobe, they did not make the same efforts to ensure consistent hotkeys btwn OS's besides the Cmd and Ctrl differences. Adobe is literally the same.
I see. I'm not finding this to be true. I tried using the mac os keybinding in WebStorm settings and it still is mapping to the wrong keys. I can't see how mapping command+shift+O to command+shift+N is helpful. So I would essentially need a table to see everything kinto is mapping to. Additionally, a very common use case is to add new keyboard shortcuts. This also is very challenging if the keys we type don't align with what kinto maps to.
To me, this just seems broken. This is also a problem if we want to use other apps while WebStorm is open. For example, I don't want chrome to think command+shift+O is command+shift+N and have to use different keyboard shortcuts if I have WebStorm open.
I understand. So there's a custom keymapping for all the common shortcuts. I guess the issues are:
I totally get this at the OS level, but I think trying to handle this for all the common programs where people have strong muscle memory and there are many shortcuts isn't the best for many users.
Well layering Kinto along with the macOS keybinding template/setting within WebStorm will certainly break things, as Kinto makes no effort to detect any custom keymaps. The only assumption it makes, and it is an assumption, is that you have not made any custom remappings in any of the apps or DE's that it officially supports. It is meant to handle all key remappings for the most part, mixing Kinto's xkeysnail config file with other remaps will likely result in some odd behaviors.
Care is also usually taken to make sure that while remapping from one combo to another that it doesn't leave any other combination out in the cold in some odd way, so I don't think that is occurring, but of course sometimes things happen and something can get missed.
Just randomly going through the list though I do understand there are some wildly different combos btwn the OS's.. I am just not honestly sure what to do about them,, it's how they lined up or rather didn't. Most editors tend to have more consistency, but not always, Sublime Text 3 had some pretty major misalignments btwn macOS and Linux/Windows itself and had it not been for that I am honestly not sure if I would have taken the time to write Kinto or not lol.
Action | Windows | macOS | Linux |
---|---|---|---|
Select configuration and debug | Alt+Shift+F9 | Ctrl+Alt+d | Alt+Shift+F9 |
Generate code | Alt+Ins | Cmd+N|Ctrl+Enter | Alt+Ins |
Shrink selection | Ctrl+Shift+w | Cmd+Alt+Down | Ctrl+Shift+w |
Open corresponding tool window | Alt+[0-9] | Cmd+[0-9] | Alt+[0-9] |
Resume program | F9 | Cmd+Alt+r | F9 |
I totally get this feature and it makes sense. Kinto is awesome at making linux feel more a mac. However, I think trying to handle every key binding for every program will lead to issues due to consistency. Mapping ctrl to command makes sense in all cases. Mapping command shift o to command shift n seems random and confusing.
All apps have the macOS keybinds period to answer your question. Don't know a shortcut? Then google the macOS equivalent, granted I would like to write an app to give users a quick preview for any hotkey - if I do that though it will likely be a separate app and only be mentioned in the readme as an optional thing to install in addition to Kinto.
I don't find that to be inconsistent in the least, of course not every cross platform app can get the attention and care I have given developer tools thus far and I certainly haven't hit all cross platform developer tools nor am I really trying to. I get to what I can, I accept PRs from others that add more mac like keybinds for any app or system level functionality. Kinto is layered in a way to still remap things generally in a macOS like way but I know it will never be 100%, just as close as I can reasonably get it.
I totally get this feature and it makes sense. Kinto is awesome at making linux feel more a mac. However, I think trying to handle every key binding for every program will lead to issues due to consistency. Mapping ctrl to command makes sense in all cases. Mapping command shift o to command shift n seems random and confusing.
You'll get no complaint from me on that point 😂.. it would be confusing to me too. I don't know why JetBrains did it that way but if you were to disable Kinto and apply their macOS layout then our keybinds ought to be pretty identical (although I think technically they still don't get everything right lol). Where they fail though it is largely due to system level shortcuts that would typically get in the way.
Also just to be clear - I am not following some edict from Apple that says all apps must use X, Y and Z hotkeys within their app. I apply the hotkeys the vendors use themselves on that platform, if Google Chrome were to use Cmd+N to open a new tab instead of a new window on macOS while using Cmd+T on Linux and Windows then yes I would use Cmd+N instead. Thankfully that is not the case, but I would implement it as it is, not how I want it to be.
The absolute most custom thing I have in Kinto is Sublime Text 3 keymaps for VS Code, and I don't even include the latest addition to that endeavor that I use locally because it would require some reworking actually. I will eventually add in an even better 1 to 1 remap of the 2, but only as an optional Tweak in the tweaks menu and that is already there just not my personal latest iteration because it involves a 3rd party vs code extension and I need to do some prompting and tooling to get that going.
What you are wanting, if it is gets implemented at some point would best be converted into a checkbox that you can check or uncheck to remove the macOS keybinds for JetBrains under my existing Tweaks menu. That is the only way I'd support it because then if a macOS user that uses JetBrains were to install Kinto on Linux or Windows one day they wouldn't be hit with foreign hotkeys.
Totally understand. I guess it would be awesome if we could opt out of the remapping for certain programs. So for me, I would rather have consistent key mappings (command+shift+o = command+shift+o all the time) even if this goes against the default WebStorm bindings. I guess my solution is just to remap to fix their issues (almost all my WebStorm bindings are custom lol).
I guess some users will want the default bindings kinto provides. Others might want to opt-out and fix issues/inconsistencies themselves via the settings in the app. I personally fall in the second category.
So I would prob just use an older version of the app with the broken bindings until I can opt-out of this rather than relearn all my keyboard shortcuts I've spent too much time memorizing and optimizing lol.
I find it some what funny and ironic that I got you using Kinto in part because it was broken instead of it fully working with all the keymaps I had in it when you first downloaded it 😂.
Honestly, I think I didn't understand the full vision of kinto. I thought the goal of it was to remap keys to make it feel more like a mac. I didn't realize it would go as far as making command + G = f3 in some programs. I get this isn't necessarily a bad thing if you learn the kinto keys from the start. Just makes it hard to switch as someone using WebStorm so long with different keys.
Personally, I have been a pretty heavy mac user for over a decade but started out on Windows and used Linux off and on, but macOS was the perfect blend of the 2. Only recently have I decided to spend a lot more time away from macOS.
In the process though I have felt the only reasonable guide to make something that feels mac like hotkey wise is to simply stick with what the vendors themselves use if it is a cross platform app. If the app has no cross-platform version then I simply don't bother making any customization to it at all - it will simply have the Ctrl to Cmd key swap you'd expect and nothing else. So the rule of thumb users will have to use when using Kinto I guess is to simply be aware of whether or not their app is A) cross platform, B) differs in any major way btwn OS's and C) Have I gotten around to it or another user submitted a PR for that app?
Some of those things are still not ideal as there is no intuitive way to know all of those things, but I guess if the app responds in unexpected ways then that is the first clue that maybe it has a mac equivalent I guess for users that are not coming from a mac lol.
And I think you mentioned Slack? A user submitted a PR for that one too, nothing major, but it does have some custom remaps that do something lol. They made it part of some of my web browser remaps because apparently it aligns perfectly with them.. I just hope that holds true, I will be adding 3-6 more hotkeys to that group soon that includes some context awareness that is unique to macOS and used to be part of Kinto before I updated it to use xkeysnail some months ago. (context awareness being are you on a text field with editable text or just a webpage - they're 2 different things that can result in a few different keymap scenarios)
Actually.. I wonder if I could add a new feature to Kinto.. one where the system tray icon will change colors if you are using a cross platform app that it supports - that way you know for sure what Kinto is doing based on its color. If I did that then I could also place in an option in the drop down menu to then disable that specific app from having custom mac like keybinds applied if that isn't your speed.
It would make a lot more sense to do that than to have an ever growing list of optional keymaps for an unlimited number of programs.. you could just set it when or if you happen to hit a fully supported application. I would still want the changing icon color to be optional, but the option to disable or enable the custom remaps would always be in the dropdown regardless.
I guess if you disable it then the question is to what? Generic macOS style, Terminal style, or normal Win/Linux style - those options might give users the flexibility they'd really like to have.
That makes total sense. After thinking about this more and hearing what you have to say I didn't understand the full mission of what kinto is trying to be.
The goal from how I understand it is to handle as many key mapping as possible so the user doesn't need to rebind keys and mess with settings to get things working how they want.
I guess my experience was this. For most applications and OS shortcuts, all the keyboard shortcuts chosen were great and the logical choice coming from mac OS. I loved how I didn't have to waste time settings things up and it created consistency across machines. Now regarding WebStorm, my issues were
This is where the trap you mentioned would be really helpful. Not only having an easy way to view the shortcuts, but also a way to opt-out when the vendor/kinto version doesn't work for you. So some ideas for the tray are:
This would be a long-term goal, but I think this would cover the major things kinto is missing at least from my perspective (easy to find key mappings and customization options from a GUI).
Just my thoughts though. Now that I understand kinto better, it makes more sense what you were trying to do here. How much customization/control you want to user to have is up to you. Obviously one of the main advantages of kinto is how simple it is to use and setup, but it's also common for users to have more control over the shortcuts/bindings especially in complex programs like jet brains and photoshop.
Thank you for taking the time to explain it to me. I really appreciate how quickly you reply and solve issues. The design decisions make much more sense now.
I just wanted to tack on here (working on making a configuration compatible) but there is a macOS layout available via plugin for all jetbrains IDE (and provided by jetbrains) which inherently conflicts with Kinto at the minute.
Is there a clean way of essentially ignoring all modifications for a certain program running?
You can always just remove or change the wm_class name of jetbrains in the kinto.py file or the equivalent in the kinto.ahk to effectively disable its remapping of the default jetbrains default keymap. Currently I have no plans to add in additional options in the GUI or tweaks menu. I am not against doing so or accepting a PR for it though, but thus far I don't expect anyone will because I have not had any contributions to my GUI front end work or the system tray built in autohotkey. Most contributions I get are in the config file itself or comments and hotkeys being added.
In my mind I work to deal with defaults - so hotkey plugins and the like in jetbrains or other apps are beyond my scope, but again detecting that and supporting it or giving toggles to change the remapping behavior on such apps does make sense and I would accept that PR.
Describe the bug It seems that after upgrading to the latest version of kinto there are some major issues in jet brains IDEs on Linux. Specifically, it seems that when the command key is held down, keys will map to random keys rather than the proper key. For example, command + G is mapping to f3 for me.
Expected behavior Key mapping should work as it did in the previous versions of kinto with predictable mapping.
Install Type: Bare Metal Distro: Ubuntu 20.04 LTS DE: Gnome Branch: master Commit: 06ba71f