search

RedBearAK / toshy

Keymapper config to make Linux work like a 'Tosh!
https://toshy.app
GNU General Public License v3.0
358 stars 17 forks source link

[BUG] KWin integration does not work on Plasma 6 Wayland #186

Closed ethanc8 closed 7 months ago

ethanc8 commented 7 months ago 
Bare metal or virtual machine: 
(If in VM, which VM software): None

(Try running 'toshy-env' in a terminal.)
(EV) Toshy env module sees this environment:
                 DISTRO_NAME     = 'neon'
                 DISTRO_VER      = '22.04'
                 SESSION_TYPE    = 'wayland'
                 DESKTOP_ENV     = 'kde'

Any DE(s) tried with Wayland?: 

Keyboard type (IBM, Chromebook, Windows, Apple): Windows
Keyboard device name (try 'toshy-devices'): 
List of devices seen by the keymapper (keyszer): 

keyszer v0.7.1
-----------------------------------------------------------------------------------
Device               Name                                Phys
-----------------------------------------------------------------------------------
/dev/input/event0    Lid Switch                          PNP0C0D/button/input0
/dev/input/event1    Power Button                        PNP0C0C/button/input0
/dev/input/event2    AT Translated Set 2 keyboard        isa0060/serio0/input0
/dev/input/event6    Video Bus                           LNXVIDEO/video/input0
/dev/input/event7    Ideapad extra buttons               ideapad/input0
/dev/input/event3    MSFT0001:01 04F3:31BE Mouse         i2c-MSFT0001:01
/dev/input/event4    MSFT0001:01 04F3:31BE Touchpad      i2c-MSFT0001:01
/dev/input/event5    GTCH7503:00 2A94:D64D               i2c-GTCH7503:00
/dev/input/event8    Integrated Camera: Integrated C     usb-0000:00:14.0-8/button
/dev/input/event9    HDA Intel PCH Mic                   ALSA
/dev/input/event10   HDA Intel PCH Headphone             ALSA
/dev/input/event11   HDA Intel PCH HDMI/DP,pcm=3         ALSA
/dev/input/event12   HDA Intel PCH HDMI/DP,pcm=7         ALSA
/dev/input/event13   HDA Intel PCH HDMI/DP,pcm=8         ALSA
/dev/input/event14   HDA Intel PCH HDMI/DP,pcm=9         ALSA
/dev/input/event15   Keyszer (virtual) Keyboard          py-evdev-uinput

These terminal commands may provide helpful info:

Problem observed:

The KWin integration no longer works on Plasma 6 Wayland (KDE Neon User, based on Ubuntu 22.04, Plasma 6.0, Qt 6.6.2). When I do Shift+Alternate+Command+I,I on a window, it cannot detect the WM_CLASS, the application class or window title. image I am still able to use the remapping from Alt -> Command, Win -> Alternate, and Ctrl -> Super. However, all applications are treated the same, so, for example, Command+C (physical Alt+C) in Konsole sends Ctrl+C to the terminal.

RedBearAK commented 7 months ago

@ethanc8

Did you try downloading a new zip and reinstalling? Did you have an older install of Toshy and just had your system update itself to Plasma 6? If that's what happened, you should be able to get a new zip from the main page and reinstall, and the necessary components will be updated. I was able to port the KWin script to Plasma 6 in December, using Neon Unstable.

If this didn't break because you've got an old install of Toshy without the Plasma 5/6 adaptations, I'll have to set up a new Neon User VM and see what the problem is. But as far as I know, any version of Toshy installed during the last few weeks should be working fine on Plasma 6.

Let me know when you can what the exact situation is.

If it's what I think it is, I guess this will be happening to a lot of users that get upgraded to Plasma 6 without reinstalling Toshy first. I don't have any kind of auto-update mechanism or notification so there's not much I can do to alert users when things like this happen. Good thing the error messages are meaningful.

ethanc8 commented 7 months ago

Yes, I believe I am on an older version of toshy. I unfortunately have a heavily modified toshy_config.py, so would it be possible for me to update all parts of toshy except toshy_config.py and bring over my old config, or would I have to reapply my changes to the new toshy_config.py? I don't know how the other components of the toshy system work and their interactions.

ethanc8 commented 7 months ago

I did upgrade from Plasma 5.15, so I think that it would be good to provide an upgrade path for users. I think it would be good to provide an updater that can automatically update, and remind the user if there are conflicts in their toshy_config.py. As a first step, it might be good to document the dependencies between toshy_config.py and the other components of toshy and to document the upgrade process.

RedBearAK commented 7 months ago

@ethanc8

I unfortunately have a heavily modified toshy_config.py, so would it be possible for me to update all parts of toshy except toshy_config.py and bring over my old config, or would I have to reapply my changes to the new toshy_config.py?

I made extra effort to do a very complicated thing in the installer script, that makes it possible to upgrade in-place without losing customizations. But this process relies on you keeping your custom overrides inside the "slice marks" that allow the installer script to literally splice those sections from a backup of the original config file into the new config file. If you strayed outside those special marks, you'll need to do some manual work to merge your customizations back in. An app like VSCode with a side-by-side view can be very helpful in this process.

I don't think there have been too many fundamental changes to how the config works, just added shortcuts and some optimized functions. I can help you if you run into some incompatibilities with something that might have changed in the meantime. Unlikely, but you never know.

And if your customizations align well with the goal of making things "Work like a 'Tosh!" we could look at including some of them in the default Toshy config file.

ethanc8 commented 7 months ago

I think that would be a separate issue. In general, my customizations have been trying to get it to behave like a mixture of the Windows-like behavior that is default and the Mac-like mapping of the modifier keys themselves, so that can cause problems. I do have customizations outside of the slice marks. Should I still use the installer script, or is there a separate procedure, such as a git merge, that I am supposed to do?

RedBearAK commented 7 months ago

I did upgrade from Plasma 5.15, so I think that it would be good to provide an upgrade path for users. I think it would be good to provide an updater that can automatically update, and remind the user if there are conflicts in their toshy_config.py. As a first step, it might be good to document the dependencies between toshy_config.py and the other components of toshy and to document the upgrade process.

I'm really of two minds about this. I don't really want to merge in a bunch of code that requires some part of the Toshy components to check something online to see if there are updates. The project is changing in little ways quite frequently, as I find odd bugs or get reports of issues, or add new shortcut fixes. But when there is a big desktop transition like this, things can be a bit rough if Toshy hasn't been reinstalled recently. I'll have to think about that. But this kind of big transition doesn't tend to happen very frequently.

I think that would be a separate issue. In general, my customizations have been trying to get it to behave like a mixture of the Windows-like behavior that is default and the Mac-like mapping of the modifier keys themselves, so that can cause problems. I do have customizations outside of the slice marks. Should I still use the installer script, or is there a separate procedure, such as a git merge, that I am supposed to do?

This has always been the problem with the way things work, which I inherited from branching off of my own highly customized config file for Kinto. You can still use the installer script, and part of the process is that it will take your existing config files and preferences database file and copy them into a backup folder in ~/.config/toshy_config_backups. The Python venv that takes up most of the space gets discarded, and a whole new Toshy folder is created. So the backup folders are pretty small. But it will save your existing config file.

Any changes that happen to be within the slice marks will be saved and restored in the new config file. But all the custom stuff between the slice marks will have to be manually merged back into the new config.

Orrrr.... I'm trying to think whether there would be anything functional that would prevent you from just completely replacing the new config file with the old one entirely. I'm not certain that would work cleanly, but you could try it. I would keep a copy of the "new" config file that has the changes from inside your slice marks merged into it. That would be the file you'd want to merge your custom stuff into, if you need to.

If you knew enough to make working customizations to the config in any kind of extensive way, I feel like it won't be too difficult to do a manual merge back into the new structure. It's still mostly the same as what you would have started out with.

Can you attach a copy? I can try to look it over for any obvious incompatibilities.

Of course when you test replacing the new config file (make a backup of the new file!) you'll want to use toshy-config-verbose-start to run it in a terminal and make sure it works. I assume you already have done that a few times.

ethanc8 commented 7 months ago

Here's my config file. I'll look into trying to upgrade tomorrow.

https://gist.github.com/ethanc8/51a102c2ed2d3f3dcc47be058a127a68

ethanc8 commented 7 months ago

A change that might be relevant for upstream toshy is the changes related to GNUstep, which functions by simply disabling all remappings for GNUstep, and having the user configure "First Command" to "Left Alt", "First Alternate" to "Left Win", et cetera. It might, however, be better to still do the remappings and change the user's configuration accordingly, so that the desktop environment "Super" shortcuts could be preserved. But I think that's a topic for another issue.

For context, GNUstep is a free reimplementation of the macOS APIs, based on an earlier free implementation of the NeXT OPENSTEP APIs. Therefore, its design philosophy is similar to OPENSTEP and early Mac OS X, which shows in its keyboard mappings. GNUstep is often used to create a full OPENSTEP-style desktop environment, when combined with WindowMaker, but is also often used to port macOS apps to X11 or Windows systems.

RedBearAK commented 7 months ago

so that the desktop environment "Super" shortcuts could be preserved

If you're talking about stuff like the workspace movement shortcuts, I haven't had much luck with that. Too much variation between DEs and distros.

For context, GNUstep is a free reimplementation of the macOS APIs

Oh, that's why it seemed familiar. Haven't really heard much about it in a long time. I'll have to try to understand what you've got going on there.

Seems like there's a "accidental paste" kind of typo in there: 

}, when = matchProps(clas="^konsole$|^org.kde.Konsole$^konsole org.kde.konsole$"))

Unless you really ran into some windows that had an app class of "konsole org.kde.konsole"? Even so, there would be a missing pipe character.

This other one seems to be correct, if that app class exists: 

}, when = matchProps(clas="^Konsole$|^org.kde.Konsole$|^konsole org.kde.konsole$"))

That's something I could add to the default config. That would be a strange one though, the only other app class I've ever seen with spaces is "Angry IP Scanner". I think spaces violate the spec, at least with X11.

There are a number of things that are just commented out, that could potentially be placed in the User Apps slice marks as overrides (and would then survive re-installs). But that would be extra trouble to go to. And an interesting question of why you needed to comment those out, including all the ignore_combo lines that seem to be commented out.

Like this one: 

keymap("GenTerms overrides: Fedora", {
    # C("RC-H"):                  C("Super-h"),                   # Hide Window/Minimize app (gnome/fedora)
}, when = lambda ctx: matchProps(lst=terminals_lod)(ctx) and DISTRO_NAME in ['fedora', 'almalinux'] )

Actually I think I might have fixed what your problem is in that case by restricting that keymap to GNOME? 

keymap("GenTerms overrides: Fedora GNOME", {
    C("RC-H"):                  C("Super-h"),                   # Hide Window/Minimize app (gnome/fedora)
}, when = lambda ctx: matchProps(lst=terminals_lod)(ctx) and DISTRO_NAME in ['fedora', 'almalinux'] and DESKTOP_ENV in ['gnome'] )

But then you also have Cmd+H blocked in the KDE Neon keymap. And Xfce4? Hmm.

Curiouser and curiouser, said Alice.

Commented out the emacs and wordwise stuff in general. That's interesting. Once again, could be overrides in the User Apps slice. Maybe.

Anyway, I am not seeing anything ringing alarm bells where you might not have a working config if you just tried to use this one after updating Toshy. You'll miss out on some enhancements and fixes for the diagnostic dialog, some new keymaps that may not even affect you, some new app classes (browsers particularly), some dialog Cmd+W additions, and some comment cleanup. Mostly superficial stuff. GNOME 45 transition adaptations, changing "new folder" in Dolphin to Shift+Ctrl+N instead of F10. That one might affect you.

Do let me know if you run into a real problem with your upgrade attempt. I'll try to be responsive.

ethanc8 commented 7 months ago

No, the "^konsole$|^org.kde.Konsole$^konsole org.kde.konsole$" was due to my attempts at troubleshooting before I discovered the KWin issues.

RedBearAK commented 7 months ago

No, the "^konsole$|^org.kde.Konsole$^konsole org.kde.konsole$" was due to my attempts at troubleshooting before I discovered the KWin issues.

Ah, gotcha. Of course if you still have the X11/Xorg session available and it won't be missing any obvious features you need, you could pop over there and Toshy should still work, for now. Forgot to mention that. The KWin script and the KDE D-Bus service are only relevant for the Wayland solution.

RedBearAK commented 7 months ago

In case it's not obvious, if you want to override something in the User Apps slice you just have a keymap that will be active under the same conditions (or more general conditions), and then if you want something like Cmd+H to not be remapped to something else, but also not be ignored/canceled out, you'd just remap it to the exact same combo. So it would still go through the keymapper but just end up being itself after the transform. Should work for a lot of the things you have commented out. If I understand why you commented them out.

RedBearAK commented 7 months ago

There are some new keymaps in the config you might want to check: 

keymap("GenTerms overrides: KDE", {
    C("RC-H"):                  C("Super-Page_Down"),           # Hide Window/Minimize app (KDE Plasma)
}, when = lambda ctx: matchProps(lst=terminals_lod)(ctx) and DESKTOP_ENV in ['kde', 'plasma'] )

keymap("GenGUI overrides: KDE", {
    C("RC-H"):                  C("Super-Page_Down"),           # Minimize app (KDE Plasma)
}, when = lambda ctx: matchProps(not_lst=remotes_lod)(ctx) and DESKTOP_ENV in ['kde', 'plasma'] )

They seemed to fix the hiding shortcut in KDE, but I'll leave it disabled for your config.

I feel like all the disabling of Cmd+H lines for different desktop environments might represent a misunderstanding of something. Surely you aren't using all those different DEs on the same machine.

I can't promise anything, but this is a spliced together config file with new stuff and your own changes and additions melded together, as well as I can. It may be usable as a replacement config after the re-install.

toshy_config_ethan_custom.zip

ethanc8 commented 7 months ago

Ok, thanks so much! The reason for all the disablements was because I wanted to use Cmd+H for replace, not for hide. I disabled it for all the desktop environments because I thought I might move to a different desktop or publish my config, so I didn't want to make it KDE-specific.

RedBearAK commented 7 months ago

I see. Makes sense if you wanted to redistribute, maybe. But you now have some idea how integrated the config file is with the rest of the app, and how it's not necessarily simple to keep a variation working over the long term without completely forking the project and maintaining it.

For personal use, a general override of the Cmd+H remaps so that they stay Cmd+H would be easier, and would keep working after updating Toshy. Same with the other disabled stuff (emacs, wordwise).

A new marked slice or two could also be introduced in the modmap and lists areas, to more easily facilitate the customization of modmaps and adding new elements to the lists. I think that would pretty much cover your issues with doing a re-install, by consolidating your changes into those marked slices.

The algorithm that pulls the data from the marked slice areas doesn't care how many there are. I can literally just add new ones wherever it makes sense to allow more user customization locations. I started with parts of the config file where I knew users would almost always need to change something, like the suspend timeout value. But there could be more.

RedBearAK commented 7 months ago

If you are bothered by the diagnostic dialog being a GTK dialog (Zenity, usually), I just merged some changes into the main branch default config file that allow the function to use kdialog on Qt-based desktops like KDE Plasma, or LXQt, if that utility is available.

It seems to make an alert sound that there is apparently no easy way to disable. I'm not sure how much I like that. We'll see what users say.

ethanc8 commented 7 months ago

I haven't had time to upgrade toshy, but I think using Gtk dialogs is fine. It uses the Breeze theme and native window decorations, with the user's preferred color scheme, and only appears on-screen for a few seconds anyway. KDE users have to deal with a ton of Gtk apps anyways.

RedBearAK commented 7 months ago

As an interesting exercise, I've added three new marked slices to the default Toshy config file, in strategic locations. Then I shuffled your customizations around into those slices as a demo. I can't promise it will work immediately, there might be a typo somewhere and I haven't tested the config yet. But if it works it should perform the same way and yet all your customizations will remain after a re-install if you start with this file.

Except for this comment line: 

    # Compose key on RCtrl mapped to LCtrl

Don't really have anywhere to put it. That would disappear after a re-install. 😄

toshy_config_ethan_custom_new_slices.zip

You would need to put this file in place (before attempting to upgrade Toshy) in your existing config folder, replacing your current toshy_config.py file, and then get the latest zip from the main Toshy branch and run the setup script. The Toshy installer will replace the necessary components to make things work again in Plasma 6, and all your custom stuff should still work.

Hope it works out when you have a chance to play with it. All the things that were commented out like the wordwise shortcuts should simply remap to themselves, becoming transparent. This works because the "User Apps" section comes before everything but the Option-key special character stuff, so a Cmd+H that triggers in that location will keep any Cmd+H from being used further down in the file.

RedBearAK commented 7 months ago

It works. No typos. But needed a little bit of a fix for Cmd+Delete in file managers. Since the custom stuff comes before the original Finder Mods keymaps now.

toshy_config_ethan_custom_new_slices1.zip

ethanc8 commented 7 months ago

It seems to work for me. I think we can close this.

RedBearAK commented 7 months ago

It seems to work for me. I think we can close this.

Have you double-checked all your custom stuff? Is it clear how/why I moved some things around in your config file?

ethanc8 commented 7 months ago

No, I haven't double-checked all my custom stuff. However, the stuff I use daily seems to work -- this includes Cmd+H for replace and compose key on Right Ctrl.

RedBearAK commented 7 months ago

OK, I’ll close this out. You’ll have to “@“ me or open a new issue if you have a problem again.

The Compose key thing is a preference setting kept in the sqlite3 database file, that deactivates some modmaps. But the Cmd+H is from the config. 👍

ethanc8 commented 7 months ago

@RedBearAK Ok. Thanks for being so helpful and patient!

RedBearAK commented 7 months ago

@RedBearAK Ok. Thanks for being so helpful and patient!

@ethanc8 - I was about to say the same! LOL. 😂 We did good. 👍