Can't set Ctrl+H but can set Shift+Ctrl+H - Cinnamon DE

[RedBearAK]

Linux Mint Cinnamon 20.1

I am unable to set the minimize window shortcut to Ctrl+H (physical Alt+H after Kinto remapping) in the Cinnamon DE. Haven't had a problem with this shortcut in XFCE or MATE.

When trying to set the shortcut, the Cinnamon keyboard shortcut dialog acts as if I have only pressed Ctrl, while the "H" key brings up some strange little text box that looks like it's trying to help me find something. This same text box appears whenever I just start typing while the keyboard shortcut preferences window is open. It disappears after several seconds.

Anyway, it's acting as if the window that is supposed to register the new keyboard shortcut is not receiving the "H" key press. Instead it registers Control R which I assume is the code for "Right Control key". I have only had this issue before with meta keys, or the Grave key which is defined in kinto.py.

But if I try to set Shift+Ctrl+H it works fine.

There is no function assigned to Ctrl+H in Cinnamon that I can find, so I feel like the secret to fixing this is in kinto.py.

I also ran into all sorts of problems by installing first from Cinnamon rather than from within XFCE, but I was able to fix all that as usual by reinstalling Kinto while logged into XFCE. Again, Linux Mint seems to still encounter major issues with the mappings Kinto installs for Cinnamon, which you apparently don't encounter on stock Ubuntu. But I am at a loss to understand how to get past this problem with setting Ctrl+H to minimize.

[rbreaves]

I have actually been meaning to try Cinnamon DE tbh, it looks nice but I just haven't yet :/. I will try to look at it some time later this week as I will need to create a new VM for it.

I can't imagine it being as complicated at Alt-Tab though - I know KDE and Budgie had difficulties to overcome. I managed to fix KDE w/o having submit a fix to them thanks to xkeysnail, but Budgie was the only one that required me to submit a patch. It was worth doing because Budgie is really awesome.

[RedBearAK]

@rbreaves

I was going to stick with MATE but for some reason I had difficulty getting the main panel to auto-hide. It would let windows expand under it to the full screen size, but the panel would never go away. Couldn't find a way to disable the right and middle click on the touchpad in XFCE, so it was basically unusable on this Acer Aspire 5 Slim. Frankly, Cinnamon is turning out pretty nice.

I'd try Budgie again but that was how I screwed up another laptop Mint install. There are only official meta packages for XFCE, MATE, and Cinnamon. They seem to coexist politely on the same machine.

If you're going to try Cinnamon start with the Cinnamon image for Mint. You should immediately run into the same issues I've been having like not being able to get through the Kinto installer due to the Win key being captured by the Cinnamon application menu. Took me an hour of looking for the keyboard shortcut to remember that it doesn't exist anywhere in the main keyboard shortcut preferences. You have to right-click on the main menu icon and go to its app-specific preferences with the "Configure..." option. That's where you can change the shortcut. Then you can finally get through the Kinto installer.

After that you can deal with the Alt+Tab weirdness and the difficulty assigning Alt+Space (Ctrl+Space) to open Albert. I'm not certain but I think what finally fixed that problem for me this time was switching the keyboard type from Windows to Win/Mac and back. Then suddenly there was no problem assigning Alt+Space, which strangely registered (in Albert) as Alt+F1. shrug emoji Whatever, it works.

That's after you disengage the shortcut from General - Show the workspace selection screen. Which... I think was assigned Alt+F1, but now I can't recall for sure.

[rbreaves]

Well I have no experience installing Budgie besides installing the Ubuntu Budgie distro which works without any major issues or modifications needed. I do install different terminals and tweak the layout a little - but everything via their gui except for hidpi stuff I might do via the terminal, a couple of commands.

[RedBearAK]

@rbreaves

I tried Ubuntu Budgie for a day (secondary physical drive, not a VM). I can see why you like it, it's very clean. Reminds me a lot of elementary OS. But after several hours of use I ran into a number of different stability issues from the software manager to the printer settings (constant lockups of the window) and it just generally didn't feel nearly as stable and well-integrated as Linux Mint.

Also I don't care for how huge the title bars are in Budgie. Lots of vertical screen space wasted, even after hiding the main panel. But Ubuntu Budgie had the main panel at the top and Plank Dock at the bottom, so I really didn't have to do much of anything as far as rearranging the UI. The default setup is really not bad at all.

On the plus side, the Kinto install went perfectly, which was surprising because Budgie was using the Win key for the application menu yet didn't block the Kinto installer from seeing it, unlike what happened in Cinnamon. And once again the Alt+Grave function worked perfectly out of the box. Well, the way I expect it to work, anyway, switching within a single application. I believe that also happened when I tried to use Budgie on Mint. And Alt+Space was automatically mapped to open the application menu, so I had a usable app launcher without even installing Albert. So it was a nice experience running Kinto on Budgie.

For now I'm feeling more comfortable in MInt Cinnamon.

[rbreaves]

I likely integrated a check for that specific Win key binding in Budgie & Gnome in general as I think they share the same setting for it. If it exists it is removed & also reversed if uninstalled. It’s likely the only system level hotkey that is modified these days. XFCE might have 2 or 3 still.

May be my preference but I support Ubuntu Budgie & XFCE the best due to GalliumOS & dog fooding them frequently & that’s looking to increase further as I move to running Windows mostly via RDP so I can stay inside Linux the majority of the time. Will likely keep a small & largely unused Windows or macOS partition as well, but I have little interest or need in juggling a triple boot system.

Concerning stability in Ubuntu Budgie I have seen the DE crash unexpectedly & restart. Not enough to deter me from using it though or declare it unusable by any means. It keeps current w/ Ubuntu unlike ElementaryOS & doesn’t put me on rails or pull me away from global menus. All in all I get everything I want & nothing pushed on me in any way. Only thing I might say would be nice is blur transparency for terminals but Budgie just isn’t written in a way to easily allow for that at this time.

Oddly XFCE w/ Compton or whatever they renamed it to support blur just fine.

[RedBearAK]

I likely integrated a check for that specific Win key binding in Budgie & Gnome in general as I think they share the same setting for it. If it exists it is removed & also reversed if uninstalled. It’s likely the only system level hotkey that is modified these days. XFCE might have 2 or 3 still.

I was just reminded recently that MATE is a GNOME 2 fork and Cinnamon is a GNOME 3 fork, so seems like an advisable idea to have that sort of check for bound meta keys in most DEs.

Will likely keep a small & largely unused Windows or macOS partition as well, but I have little interest or need in juggling a triple boot system.

I hope you won't let the Windows version of Kinto fall behind. There are many who are basically forced to run Windows just because of some software they need that is only available in Windows. In fact even though I hate Windows I've been pondering whether I should just give up on trying to escape macOS for Linux because the software landscape is still much worse than I had hoped it would be moving into the third decade of the 21st century. Kinto is one of the main things that would make long term Windows usage tolerable.

It keeps current w/ Ubuntu unlike ElementaryOS & doesn’t put me on rails or pull me away from global menus.

I tried eOS briefly again and was almost immediately reminded of how obtuse they are about wanting to control the panel indicators. Kinto of course would not show up in the tray. Elementary is so slick feeling but they've just made too many controlling compromises. I wiped it out almost immediately.

Oddly XFCE w/ Compton or whatever they renamed it to support blur just fine.

I had the same feeling over the past year, seeing how sophisticated XFCE has become these days. There really is very little practical difference between XFCE, MATE and Cinnamon overall, besides XFCE somehow still using less RAM. If I hadn't had the problem with the touchpad behavior, I would probably still be in XFCE.

Just to annoy you (not really) I think I'm going to try not just stock (GNOME) Ubuntu but also Lubuntu, which has moved from LXDE to LXQt. Will see how Kinto gets along with it and report any issues I encounter.

[rbreaves]

I had a good experience with LXDE once and do need to test against it with Kinto but haven't yet. And no the Windows version will certainly not fall behind, most of my work for clients require that I use Windows so for better or worse I have to use it. It is part of the reason I've finally taken the time to work out the RDP situation as well, so I can stop using it natively on my personal laptops for the most part and just remote into desktops or work laptops with Windows.

In an odd way the more extensible AHK sorta pushes the xkeysnail version forward at times as I can rig things up in AHK in ways that I wouldn't think about if I was only supporting xkeysnail. It's honestly very surprising that I am able to keep both of them mostly in sync with each other lol.

To me that is a much better setup - one where I get to keep what I want on my hardware and offload the things I don't want. It isn't like I even own a gamer laptop atm, and to me that is truly the only reason to have Windows installed on pretty much anything.. Gaming and multimedia work - but again RDP is so good imo there's no reason to have Windows besides maybe a small install for the best possible RDP experience when it matters for gaming. Beyond that though.. Windows isn't something I want to be using daily unless it is via RDP. VMs were fine for awhile but even that.. just drains battery unnecessarily and I have had a NUC pc forever that has gone under utilized, so I am giving it a workout now with Windows lol and I have gamer PC in the cloud for $15 as well. Although I have not yet gamed on it, I know some were wanting me to work on adding fullscreen gaming detection support to Kinto so that it immediately disables itself when a game launches and I would like to add that.

[RedBearAK]

Initial experience with trying to run Kinto in Lubuntu is not going well. Tray and GUI won't run, xkeysnail service has to be started manually after setup (but reports as running and active after that). Some remapping is happening, but nothing works as expected. Can't even find a way to fix the app switcher shortcut in their rudimentary keyboard shortcuts app.

I'll start a new thread and try to give some specific logs and error messages.

So far LXQt feels much more primitive than even XFCE. Much closer to something ancient like IceWM. Yet RAM usage is 1.3GiB with nothing but a terminal running. At this point I'm not sure why anybody would want to choose this over Xubuntu.

[rbreaves]

Probably is just missing dependencies, the installer only goes so far by design. If I've not tested the distro and DE out then I don't start guessing a whole lot at what dependencies may be needed as I can't possibly know that without jumping through it, but that's very likely the only type of issue you or anyone would run into when trying out a combination I've not tried.

Wayland is the only thing that knocks things out, and while I have started that conversation and some preliminary work at xkeysnail's repo I have not gotten any engagement on the issue yet.

[RedBearAK]

Oh, good old Wayland. Maybe it will be usable for everything that works in X in only another 10 years. LOL. This will remind me to stay away from it for now. I hear Ubuntu are already trying to make it the default though, unfortunately.

I just submitted issue #402 with a report (as detailed as I know how to make it) on what happens when trying to install and run Kinto on Lubuntu/LXQt 20.04.2. Leave a note there if you want more info.

[RedBearAK]

@rbreaves

Used xbindkeys -mk to see what the Ctrl+H shortcut was doing, and got this result (in XFCE):

"(Scheme function)"
    m:0x14 + c:105
    Control+Mod2 + Control_R
"(Scheme function)"
    m:0x50 + c:43
    Mod2+Mod4 + h
"(Scheme function)"
    m:0x54 + c:105
    Control+Mod2+Mod4 + Control_R
"(Scheme function)"
    m:0x50 + c:133
    Mod2+Mod4 + Super_L

Does this provide you with any insight at all as to why I can't map Ctrl+H to minimize windows? I'm now having this issue also in XFCE. But both XFCE and Cinnamon will accept Shift+Ctrl+H as a substitute with no problem.

The first two key code blocks above happen when pressing Ctrl+H, the latter two blocks will only appear after releasing the Ctrl key. But when I try to bind Ctrl+H to minimize window, the keyboard shortcut keystroke capture dialog immediately disappears after I press "H". The keyboard dialogs never complained that Ctrl+H was used by something else, they just don't recognize that I'm even pressing the "H" key. Or, somehow pressing the "H" key kicks me out of the dialog and just registers "Control R" alone.

I tried swapping the RC-H mapping in kinto.py with the xfce4 version, it changes the keycodes but doesn't seem to help with whatever is blocking the mapping of the shortcut.

[rbreaves]

I don’t have time to look atm, but you can checkout a different branch of my xkeysnail fork (may break Alt-tab, so it’s not ready yet).

In the Kinto source folder.

cd ./xkeysnail
git checkout debug
git pull origin debug
cd ..
./setup.py

Now when you run Debug for Kinto you’ll get the translations happening w/o the need for a key listener like xbindkeys & it tells you what chunk of code is being applied as well (although that already should be happening as I’ve added descriptions to each code section).

[rbreaves]

Additionally the translation that should be happening on Cmd+H is mentioned in the translation table here #44 (aka it translates to Alt+F9 according to that and I am sure it is reasonably reflected in the kinto.py config file w/ K("RC-H"):K("M-F9") in it somewhere or whatever media key translates to F9, sometimes the F keys do not behave as one would expect so the media key name has to be used instead.

I mention #44 now too because xfce is clearly a supported DE and there is documentation for that as well as the expected entries in the config file to support it. If there is a problem with that then I will need to address it.

[RedBearAK]

@rbreaves

Additionally the translation that should be happening on Cmd+H is mentioned in the translation table here #44 (aka it translates to Alt+F9 according to that and I am sure it is reasonably reflected in the kinto.py config file w/ K("RC-H"):K("M-F9") in it somewhere or whatever media key translates to F9, sometimes the F keys do not behave as one would expect so the media key name has to be used instead.

Ah, now this actually presents a ray of hope. F9 on this machine is the mute key. I will try changing it in kinto.py to mute. Whatever that might be, specifically.

The only app I've seen that reads it as Alt+F9 is that generic GNOME settings app that pops up when I use Edit - System Settings via the Kinto GUI. But it still didn't work even though it showed the right key codes.

Cinnamon and the GNOME settings app both read that key as "Audio mute". Not sure how to enter that in kinto.py.

OK, so this is... hilarious? Well, at least it's some sort of progress. I can set the minimize shortcut to Alt+F9 by pressing (physical keys) Win+Fn+F9. Then when I press physical Alt+H (logical Ctrl+H), it works. It minimizes the window.

So there seems to be some kind of volume control daemon interfering. What's weird is the volume mute key kept working even after I removed the shortcut in the Cinnamon keyboard shortcuts app. As if something else was also bound to the same shortcut. Then when I tried to reassign it in the Cinnamon app, it complained that something else called "Volume Mute (Quiet)" was using the shortcut. I said go ahead and use it. Then I unassigned it again, and now the mute key doesn't mute the audio. And it still won't allow me to set the shortcut by actually pressing Alt+H. I have to use the mapped Alt/Win key, and Fn+F9 to set the shortcut to show "Alt+F9".

But then it works on Alt+H. I haven't actually changed anything in kinto.py besides the fact that I'm using the one generated by installing from Xfce. Which I unfortunately had to remove from this machine. So now I can only install new versions of Kinto from within Cinnamon, and that really doesn't work well. Good thing I made a backup.

[rbreaves]

Look at xkeysnail key.py file for the names of supported media keys

[RedBearAK]

@rbreaves

I looked for the key name in key.py and it appears to be just "MUTE = 113" right above "VOLUMEDOWN = 114" and "VOLUMEUP = 115". So I set the mapping to "M-MUTE" (capitalization doesn't seem to matter) which in my constant confusion I believe should be the "Alt+Mute" key codes.

All this really accomplishes is that instead of needing to press Win+Fn+F9 to set the shortcut, I have to press just Win+F9, and the shortcut reads as "Alt+Audio mute" rather than "Alt+F9". I can still trigger the shortcut afterwards by pressing physical Alt+H after setting it, but in either case I still can't actually set the shortcut by pressing Alt+H. That will still set the shortcut to just "Control R".

So while using the media key name in kinto.py rather than the "F9" name technically "works", it doesn't do anything to bypass whatever is interfering with the main physical Alt+H (logical Ctrl+H) key combination.

The only "sound" or "mute" or "volume" background process I can find via ps -ax | grep -i is something called csd-sound which appears to be part of a group of plugins specific to Cinnamon.

From https://github.com/linuxmint/cinnamon-settings-daemon:

sound
This plugin is use to play sound files or theme sounds via PulseAudio.

It's available via dbus at org.cinnamon.SettingsDaemon.Sound.

Its configuration is org.cinnamon.desktop.sound.

[RedBearAK]

@rbreaves

I did a diff between the kinto.py that was installed by the 1.2-6 version run under Cinnamon, and the one created by the 1.2-5 version of setup that I ran under Xfce. The main difference that seems to get everything working fine in Cinnamon is really just activating the "xfce4" mappings rather than the "non-xfce4" mappings. I know that doesn't make much sense in your experience, but this always appears to be necessary on Mint.

As I mentioned I had to remove most of the xfce4-* packages from this install of Linux Mint. My Xfce desktop inexplicably imploded back to generic factory (non-Mint) defaults, and I went too far and did the wrong thing in trying to fix it. This is the third machine and third version of Mint where Xfce has done this, basically "eaten" its own user settings somehow, for reasons unknown. It's really starting to sour me on using Xfce at all.

So if I ever lose track of this backup copy of my kinto.py, I'm going to have a serious problem trying to use Kinto on Linux Mint Cinnamon until there is a way to just choose to try the Xfce4 bindings even on non-Xfce4 DEs. Without a diff like this I can't keep track of which lines to manually modify to get Kinto working in Cinnamon. Back in the v1.1 days I could just go in and modify about four lines and call it a day. It doesn't seem to be quite that simple anymore.

Simplest solution at the moment would be to have the setup script save backup copies of kinto.py both with and without the xfce4 bindings. That way the appropriate backup could be copied over kinto.py and Kinto would work after a restart.

[rbreaves]

I am thinking about doing the install with 2 kinto.py files, an original from the setup and then have duplicate copy that is will be in use, so kinto.py.org and kinto.py. This way if you re-run the install I can diff out the differences first that will contain your changes, and then in theory re-apply those change to a new install.

Either that or write a parser to go through it more carefully and abstract changes. I almost think maybe setting up a website where people could share their changes and add descriptions would be useful too, add ratings and reviews as well so it is like a plugin site for Kinto. That might encourage a community of people to work with Kinto a lot more when broken out of it being a github only affair.

[RedBearAK]

@rbreaves

Either that or write a parser to go through it more carefully and abstract changes. I almost think maybe setting up a website where people could share their changes and add descriptions would be useful too, add ratings and reviews as well so it is like a plugin site for Kinto. That might encourage a community of people to work with Kinto a lot more when broken out of it being a github only affair.

Yes.

I've basically been submitting a lot of these bug reports as a way to document the fixes so that I can always get Kinto working wherever I go. There really should be a wiki or something where a community can form and work toward making sure there are always known solutions (like working kinto.py examples) available for every possible DE and distro. I would be very much in favor of that. A wiki site or a forum with some pinned posts that are able to evolve into one-stop starting points to fix things for a given distro/DE.

A very important thing: Detailed instructions for "fixing" the mappings in the native keyboard shortcut apps. That's still an ongoing problem and quite confusing for someone not familiar with how and where to fix keyboard shortcuts for any given DE. I think KDE and Budgie are the only DEs that ever seemed to really work perfectly right after Kinto setup was done, without some manual intervention for things like Alt+Tabbing. At least, on the distros that I've been testing over the past year.

Oh, and that also reminds me: I was going to try Manjaro for a while but I realized it's using Wayland by default, so it wouldn't work with xkeysnail. That's going to become an increasing problem as major distros start trying to use Wayland on their production releases. Unless xkeysnail can work with XWayland, maybe? Otherwise, there will be an increasingly pressing need in the next few years to port the functionality over to something that will work with Wayland. It's taken a long time but I think we're nearing the tipping point where X is going to start to finally be left behind. Everyone says Ubuntu is going for it on their next release.

[rbreaves]

Xwayland is still only a half measure even if that would work, it'd be half broken. And no that has always been at the forefront of my mind before I even wrote the first line of code for Kinto to be completely honest. It almost made me not start the project at all, but I felt since I felt like I had a fairly good idea of how to do it with x11 already and that effort could reasonably be applied to most DE's whereas the technical challenges of Wayland would make it as though I am having to rewrite a big part of Kinto for every individual DE.. it only made sense to go ahead and write it for x11 and tackle Wayland later.

Kinto is so dependent on xkeysnail to work that as far as Wayland support goes my focus will be to figure out how to get Wayland support (per DE most likely) added to xkeysnail directly and based on the most popular DE's first. I've started the conversation in a ticket with xkeysnail, but so far I have seen little engagement on the topic - I am sure as it becomes more popular to use Wayland the problem will be addressed by someone.. if not by me.

[RedBearAK]

@rbreaves

Yeah, I think it will be possible to switch from Wayland to X11 in things like Manjaro or Ubuntu for quite some time, so don't fret too much just yet. But good to know we are on the same page about how fast the transition might be coming.

For now I will have to stick to distros that at least have X11 as an option. I know xkeysnail is far from the only software that isn't yet ready for Wayland, so there will be X11 options for a good while. Keep the faith.

[RedBearAK]

@rbreaves

I've discovered what the "Volume Mute (Quiet)" (Cinnamon) or "Volume mute quietly" (MATE) is all about. It adjusts the sound level without invoking the volume feedback sound (if enabled). So it's a built-in alternative set of keyboard shortcuts in some DEs.

The keyboard shortcuts are just Alt added to the Mute, VolumeUp and VolumeDown keys. This is the source of the interference with your Alt+F9 mapping from Ctrl+H. When I disable it completely, I can easily set the minimize shortcut by pressing Ctrl+H, no weird contortions necessary. At least in MATE desktop. I'll test whether I can finally get rid of the conflict in Cinnamon.

Edit: No such luck. The corresponding shortcut is definitely disabled but there is still a conflict in Cinnamon. Have to use Alt+Fn+F9 to set the shortcut to Alt+F9. Very strange.

Cinnamon hides its Quiet Keys away in a normally hidden submenu under the main Sound and Media shortcuts. Finally found it now that I know what I'm looking for.

[RedBearAK]

Resolved.