[BUG] Failure installing dbus-python on Fedora 38 KDE

[gregmolnar]

Bare metal or virtual machine: Bare metal
(If in VM, which VM software): None

(Try running 'toshy-env' in a terminal.)

Linux distro name: Fedora
Distro version: 38
X11/Xorg or Wayland: X11 
Desktop environment(s):  KDE

DE(s) tried with Wayland?: KDE 

Problem observed:
Installer fails with this output:

Collecting dbus-python
  Using cached dbus-python-1.3.2.tar.gz (605 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Preparing metadata (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [93 lines of output]
      + meson setup /tmp/pip-install-tpa6ei6l/dbus-python_a4d6ffde4dfa49c8a31d89145537f780 /tmp/pip-install-tpa6ei6l/dbus-python_a4d6ffde4dfa49c8a31d89145537f780/.mesonpy-t244uvq1/build -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md --native-file=/tmp/pip-install-tpa6ei6l/dbus-python_a4d6ffde4dfa49c8a31d89145537f780/.mesonpy-t244uvq1/build/meson-python-native-file.ini
      The Meson build system
      Version: 1.1.1
      Source dir: /tmp/pip-install-tpa6ei6l/dbus-python_a4d6ffde4dfa49c8a31d89145537f780
      Build dir: /tmp/pip-install-tpa6ei6l/dbus-python_a4d6ffde4dfa49c8a31d89145537f780/.mesonpy-t244uvq1/build
      Build type: native build
      Project name: dbus-python
      Project version: 1.3.2
      C compiler for the host machine: cc (gcc 13.1.1 "cc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2)")
      C linker for the host machine: cc ld.bfd 2.39-9
      Host machine cpu family: x86_64
      Host machine cpu: x86_64
      Compiler for C supports arguments -fno-common: YES
      Compiler for C supports arguments -Wno-missing-field-initializers: YES
      Compiler for C supports arguments -Wno-declaration-after-statement: YES
      Compiler for C supports arguments -Wno-inline: YES
      Compiler for C supports arguments -Wno-redundant-decls: YES
      Compiler for C supports arguments -Wno-switch-default: YES
      Compiler for C supports arguments -Wno-write-strings: YES
      Compiler for C supports arguments -Wcast-align: YES
      Compiler for C supports arguments -Wdouble-promotion: YES
      Compiler for C supports arguments -Wduplicated-cond: YES
      Compiler for C supports arguments -Wfloat-equal: YES
      Compiler for C supports arguments -Wformat-nonliteral: YES
      Compiler for C supports arguments -Wformat-security: YES
      Compiler for C supports arguments -Wformat=2: YES
      Compiler for C supports arguments -Winit-self: YES
      Compiler for C supports arguments -Wlogical-op: YES
      Compiler for C supports arguments -Wmissing-declarations: YES
      Compiler for C supports arguments -Wmissing-format-attribute: YES
      Compiler for C supports arguments -Wmissing-include-dirs: YES
      Compiler for C supports arguments -Wmissing-noreturn: YES
      Compiler for C supports arguments -Wnull-dereference: YES
      Compiler for C supports arguments -Wpacked: YES
      Compiler for C supports arguments -Wpointer-arith: YES
      Compiler for C supports arguments -Wshadow: YES
      Compiler for C supports arguments -Wswitch-enum: YES
      Compiler for C supports arguments -Wundef: YES
      Compiler for C supports arguments -Wunused-but-set-variable: YES
      Compiler for C supports arguments -Wjump-misses-init: YES
      Compiler for C supports arguments -Wmissing-prototypes: YES
      Compiler for C supports arguments -Wnested-externs: YES
      Compiler for C supports arguments -Wold-style-definition: YES
      Compiler for C supports arguments -Wpointer-sign: YES
      Compiler for C supports arguments -Wstrict-prototypes: YES
      Configuring _dbus-python-config.h using configuration

      Executing subproject dbus-gmain

      dbus-gmain| Project name: dbus-gmain
      dbus-gmain| Project version: undefined
      dbus-gmain| C compiler for the host machine: cc (gcc 13.1.1 "cc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2)")
      dbus-gmain| C linker for the host machine: cc ld.bfd 2.39-9
      dbus-gmain| Compiler for C supports arguments -fno-common: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wno-missing-field-initializers: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wcast-align: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wdouble-promotion: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wduplicated-branches: YES
      dbus-gmain| Compiler for C supports arguments -Wduplicated-cond: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wfloat-equal: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wformat-nonliteral: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wformat-security: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wformat=2: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Winit-self: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wlogical-op: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-declarations: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-format-attribute: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-include-dirs: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-noreturn: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wnull-dereference: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wpacked: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wpointer-arith: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wredundant-decls: YES
      dbus-gmain| Compiler for C supports arguments -Wshadow: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wswitch-default: YES
      dbus-gmain| Compiler for C supports arguments -Wswitch-enum: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wundef: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wunused-but-set-variable: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wwrite-strings: YES
      dbus-gmain| Compiler for C supports arguments -Wdeclaration-after-statement: YES
      dbus-gmain| Compiler for C supports arguments -Wjump-misses-init: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-prototypes: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wnested-externs: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wold-style-definition: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wpointer-sign: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wstrict-prototypes: YES (cached)
      dbus-gmain| Found pkg-config: /home/linuxbrew/.linuxbrew/bin/pkg-config (0.29.2)
      dbus-gmain| Found CMake: /usr/bin/cmake (3.26.4)
      dbus-gmain| Run-time dependency dbus-1 found: NO (tried pkgconfig and cmake)

      ../../subprojects/dbus-gmain/meson.build:107:11: ERROR: Dependency "dbus-1" not found, tried pkgconfig and cmake

      A full log can be found at /tmp/pip-install-tpa6ei6l/dbus-python_a4d6ffde4dfa49c8a31d89145537f780/.mesonpy-t244uvq1/build/meson-logs/meson-log.txt
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

dbus-python is installed on my machine, but the virtual python env fails to install it for some reason. Do you have any ideas how to resolve this? Thanks!

[RedBearAK]

@gregmolnar

Strange. Can't replicate it yet, and can't imagine why it would happen.

I've been testing specifically in F38 KDE periodically, in a fresh VM that I keep resetting to a clean starting point. Just did it again and had no such issue. And I haven't seen that for a while on any distro I've tested.

The dbus-1 thing is often covered by a different native package from the other D-Bus stuff. Don't ask me what it is exactly, or why it's separated. But on Fedora it should be taken care of by dbus-devel if I remember correctly.

When did you download the zip, and did you get it from the main branch? Try downloading it again, it had some fairly recent changes.

Anything odd about your distro, or is it the usual Fedora 38 KDE spin ISO?

This kind of feels like your system might have just failed to install the necessary native package on the way through the install process. Happens sometimes, 404 errors or mirror issues are still pretty common even on a well-supported distro like Fedora. If that was what happened a second attempt should succeed.

[RedBearAK]

If you've been to the main page before (in the same browser and more than a few hours ago), try to make sure you refresh the page so that the browser isn't showing you a link to an older (cached) state of the repo, and possibly downloading an older zip file. Right now you should see "466 commits" in the corner of the main files box, right under the green "Code" button.

[gregmolnar]

I cloned the repository and run the install script from that. I have dbus-devel, python3-dbus installed, and my system python can use them. I managed to go through the installation by changing toshy_setup.py to use my system python and the keymappings seem to be working in chrome but they don't work in Konsole. This is the output of toshy-service-log:

Jun 04 07:33:15 riddler systemd[2888]: Starting toshy-config.service - Toshy Config Service...
Jun 04 07:33:15 riddler systemd[2888]: Started toshy-config.service - Toshy Config Service.
Jun 04 07:33:15 riddler bash[54859]: keyszer v0.6.92
Jun 04 07:33:15 riddler bash[54859]: Traceback (while executing your config):
Jun 04 07:33:15 riddler bash[54859]:   File "/home/gregmolnar/.config/toshy/toshy_config.py", line 53, in <module>
Jun 04 07:33:15 riddler bash[54859]:   File "/home/gregmolnar/.config/toshy/lib/settings_class.py", line 6, in <module>
Jun 04 07:33:15 riddler bash[54859]: from watchdog.observers import Observer
Jun 04 07:33:15 riddler bash[54859]: ModuleNotFoundError: No module named 'watchdog'
Jun 04 07:33:15 riddler systemd[2888]: toshy-config.service: Main process exited, code=exited, status=1/FAILURE
Jun 04 07:33:15 riddler systemd[2888]: toshy-config.service: Failed with result 'exit-code'.

Oddly, whatdog is installed:

[~/Downloads/toshy-main] pip3 install watchdog
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: watchdog in /home/gregmolnar/.local/lib/python3.11/site-packages (3.0.0)

I will try to debug it further, thanks for your help!

[gregmolnar]

I was wrong, the toshy keymappings do work in Konsole too, except copy+paste still requires shift too and I got rid of that before, but probably messing with something on my own. And I forgot to mention above that my Fedora 38 is the usual one, but I upgraded from 36 yesterday and I have a bunch of things customized, some I don't even remember to until they stop working :)

[RedBearAK]

@gregmolnar

keymappings do work in Konsole too, except copy+paste still requires shift

That means it's not actually working correctly.

There is an illusionary state that happens when the keymapper can't obtain the window context information (application class, window name/title). If you still need Shift in Konsole, this probably means only the remap of the modifier keys is working, which is only a small fraction of what the config file does. It's not recognizing that Konsole is a terminal, which would change a number of remaps so that Cmd+X/C/V and other things would work as expected.

Funny story, I don't think I've ever actually tested the installer from a git clone, I've only ever tested it from the zip downloaded from the Code button, since one of the things the installer does is install git. It's made to run on a fresh Linux install where git is often not installed yet.

I am looking into whether you could be somehow trying to install from an older state of the files when doing it that way, but I really don't know that much about git. I would advise you to instead download the zip file from the Code button, unzip it and try to install from the resulting folder.

Everything is really set up at this point to work from a Python virtual environment, so Python packages you might have installed system-wide or in ~/.local/lib should be irrelevant if the Toshy installer is working the way it is supposed to.

[RedBearAK]

I reset the VM and tested from a git clone (after installing git myself, since it's not installed by default). Still can't replicate the install issue, but it's on an otherwise fresh Fedora 38 KDE install.

Just merged some new minor code changes into main before that, maybe that helped get the repo back into a consistent state. It should really work if it's a clone or a downloaded zip. Don't really know what else to look at.

Modifying the installer to use the system python instead of letting it work inside the venv is probably never going to do good things for you.

[gregmolnar]

I figured it out. I have homebrew(linuxbrew) installed, and that causes some issues probably because removing it from my path makes the installer work. The services are running now, I see the tray, but I still need CMD+SHIFT+C to copy in a Konsole. Are you sure that should work with just CMD+C? Does that work in your test VM? I used Kinto before, and I have a vague memory of changing those mappings manually in Konsole's config.

[RedBearAK]

Hmm, maybe I should take a close look at what paths some commands in the installer will end up using, and try to mitigate that with more absolute paths for the commands. Homebrew and other similar things that might be in the path are not that uncommon.

Both Kinto and Toshy should recognize Konsole as a "terminal", and most Linux terminals are still sticking with the idea that normal shortcuts need "Shift", so the config compensates for that with a group of remaps specific to all recognized terminals as a group.

I even updated the application class identifier for Konsole to include what usually comes up on Wayland: 'org.kde.Konsole', so Konsole has been working like a charm for me in testing, in both X11/Xorg and Wayland+KDE. If things are working correctly, you will be able to use those shortcuts in any known terminal app just like you would in macOS Terminal.app. That is kind of the entire point of Kinto/Toshy.

One of the most obvious tests of whether the application matching is working is trying the preferences shortcut in Firefox. This is in the README on the front page (somewhere), but it's really simple. If you open Firefox and use Cmd+comma it should open a new tab, type in "about:preferences" and hit the Enter key, leaving you with the Firefox preferences open in the tab.

If the matching is not working, the only shortcut remaps that will ever be active are ones in the the "General GUI" shortcuts, because they apply to all windows regardless of a specific class/name/title attribute.

So we really need to nail down how to get through the installer sequence successfully. I hope you'll have a bit of time to help me work through it. I really want this to be a robust installer.

[gregmolnar]

Konsole has been working like a charm for me in testing, in both X11/Xorg and Wayland+KDE.

I am using X11+KDE.

If you open Firefox and use Cmd+comma it should open a new tab, type in "about:preferences" and hit the Enter key, leaving you with the Firefox preferences open in the tab.

This works for me.

I just checked toshy-services-log:

Jun 04 19:00:24 riddler bash[4704]: (EE) Desktop may be misidentified: 'kde'
Jun 04 19:00:24 riddler bash[4704]: 'gnome' was detected and will be used instead.

Maybe this is the issue, since I am on KDE. I will try to figure out why it thinks it is misidentified.

So we really need to nail down how to get through the installer sequence successfully. I hope you'll have a bit of time to help me work through it. I really want this to be a robust installer.

I am happy to test it if you change how paths are handled.

[gregmolnar]

After a restart of the services I don't see the gnome line in the logs, but Konsole still doesn't work without me customizing the shortcuts.

[RedBearAK]

Desktop may be misidentified: 'kde'

Uh, OK, that happens when a secondary process list check sees gnome-shell in the list of processes. Perhaps I should rework that so that it only takes effect if the desktop environment is completely unidentified by that point in the environment module code.

Question is why is it seeing gnome-shell in the process list when you are using KDE? That's curious.

This works for me.

Ah, of course it does, you're not using Wayland+KDE. I was thinking about the wrong problem. So... now I'm not sure why your Konsole wouldn't be behaving like you expect. That doesn't make much sense.

Can you run this and show the output when you click on the Konsole window?

xprop WM_CLASS _NET_WM_NAME

It should look like this:

WM_CLASS(STRING) = "konsole", "konsole"
_NET_WM_NAME(UTF8_STRING) = "~ : xprop — Konsole"

[gregmolnar]

[~] xprop WM_CLASS _NET_WM_NAME

WM_CLASS(STRING) = "konsole", "konsole"
_NET_WM_NAME(UTF8_STRING) = "gregmolnar : zsh — Konsole"

Maybe zsh causes the trouble?

[RedBearAK]

That's normal output, and the shell should have thing to do with anything. I've been using zsh for quite a while with no issues.

But you say that you still can't do things like copy/paste with Cmd+C/V keys? That's really, really strange at this point.

Run the manual config command and look at what it does when you use those shortcuts, and when you open new tabs and use something like Shift+Cmd+Left_Brace (and Right_Brace) to do tab navigation. That's the square bracket keys, the naming is odd in the keymapper's key definition file.

The manual command:

toshy-config-start-verbose

[gregmolnar]

(II) in LEFT_ALT (press)
(DD) modmap: LEFT_ALT => RIGHT_CTRL [Cond modmap - Terms - Win kbd]
(DD) on_key RIGHT_CTRL press
(DD) suspending keys [RCtrl<Key.RIGHT_CTRL>]

(II) in C (press)
(DD) on_key C press

(DD) WM_CLASS: 'konsole' | WM_NAME: 'gregmolnar : zsh — Konsole'
(DD) DEVICE: 'AT Translated Set 2 keyboard' | CAPS_LOCK: 'False' | NUM_LOCK: 'False'
(DD) ACTIVE KEYMAPS:
     'User hardware keys', 'Wordwise - not vscode', 'Konsole tab switching',
     'GenTerms overrides: Fedora', 'GenTerms overrides: Ubuntu/Fedora', 'General
      … Terminals', 'GenGUI overrides: not Chromebook', 'GenGUI overrides: Fedora',
     'GenGUI overrides: KDE', 'General GUI'
(DD) COMBO: RCtrl-C => Ctrl-Shift-C in KMAP: 'General Terminals'
(DD) spent modifiers [<Key.RIGHT_CTRL: 97>]
(DD) resuspending keys
(DD) suspending keys [RCtrl<Key.RIGHT_CTRL>]
(OO) press LEFT_CTRL 1685912369.0404367
(OO) press LEFT_SHIFT 1685912369.0404658
(OO) press C 1685912369.0506802
(OO) release C 1685912369.0507202
(OO) release LEFT_SHIFT 1685912369.0659506
(OO) release LEFT_CTRL 1685912369.0660546

(II) in C (release)
(DD) on_key C release

(II) in LEFT_ALT (release)
(DD) on_key RIGHT_CTRL release
(DD) silent lift of spent mod RIGHT_CTRL

Hopefully it means something for you :)

Thanks a lot for looking into this by the way!

[RedBearAK]

That looks good. The window is being recognized as Konsole, the terminal keymaps are active, and it is remapping Cmd+C onto Ctrl+Shift+C as it should, as the COMBO line shows.

(DD) WM_CLASS: 'konsole' | WM_NAME: 'gregmolnar : zsh — Konsole'
(DD) DEVICE: 'AT Translated Set 2 keyboard' | CAPS_LOCK: 'False' | NUM_LOCK: 'False'
(DD) ACTIVE KEYMAPS:
     'User hardware keys', 'Wordwise - not vscode', 'Konsole tab switching',
     'GenTerms overrides: Fedora', 'GenTerms overrides: Ubuntu/Fedora', 'General
      … Terminals', 'GenGUI overrides: not Chromebook', 'GenGUI overrides: Fedora',
     'GenGUI overrides: KDE', 'General GUI'
(DD) COMBO: RCtrl-C => Ctrl-Shift-C in KMAP: 'General Terminals'

So, when you say that you changed the Konsole shortcuts, does that mean that you changed the shortcuts in the actual Konsole preferences dialog? Because that would mean the remaps are now remapping onto shortcuts that Konsole is no longer looking for (and thus ignoring). In which case you're going to want to reset the Konsole shortcuts to their defaults.

The Kinto and Toshy config files are designed to work with the default shortcuts of the applications it has keymaps for, so that the user has no need to mess with the defaults in individual applications. If you've changed them... 😱 🙀

But just reset them to defaults and everything should be good henceforth.

[RedBearAK]

And you can get back to running from the background services by restarting the services from the tray icon menu (not the script, the "services"). That restart process should automatically terminate the manual script running in the terminal.

[RedBearAK]

I set a standard path within the scope of the installer script that should overcome the issues you were having with Homebrew being in the path. But since I was never having that problem my testing won't reveal whether it solves the issue. The beta installer worked after the update, but that's all I can say about it from my end.

If you can get the Homebrew path back into your path variable in the same way as it was previously before testing the new installer, that would be good.

This change is only in the dev_beta branch for now. You can go to the main page and switch to the dev_beta branch before downloading the zip file, or you can do git checkout dev_beta in your clone and git pull to receive the updates (I think that should work) and then try the install again.

[RedBearAK]

And I moved that whole process double-check in the environment module into an if that stops it from doing anything unless the desktop environment is still unidentified by the other checks, which is probably how it should have worked anyway. 👍🏽

Also still just part of the dev_beta branch for now.

[gregmolnar]

I had reset the keyboard shortcuts to the default in Konsole when testing:

But it still doesn't work for some odd reason, even though from the verbose logs it should map exactly to that:

 (DD) COMBO: RCtrl-C => Ctrl-Shift-C in KMAP: 'General Terminals'

Very weird, likely due to some customization I have somewhere.

I will test the dev_beta branch shortly.

[gregmolnar]

Hm... when I set my custom shortcut in console, I get Alt+Shift+C, shouldn't (DD) COMBO: RCtrl-C => Ctrl-Shift-C in KMAP: 'General Terminals' map to the same?

[RedBearAK]

Yes, it should map onto Ctrl+Shift+C, theoretically, just like it said in the logging. Are you sure Toshy wasn't disabled at the time? (In GNOME the tray icon changes to reflect the status of the services, but that doesn't work in KDE yet.)

You haven't messed with your keyboard type in the main KDE control panel, or tried to use the macOS keybindings option in your Konsole profile, have you?

Your keyboard has the same device name as the keyboard on my Acer laptop, it should be getting identified as the correct type (Windows). Try pressing the physical Ctrl+Shift+C keys when you set the shortcut, instead of Cmd+C.

(But actually, just clicking the Defaults button and "OK" should get everything back to what it should be.)

I just ran through installing Homebrew and then running the Toshy installer in F38 KDE and had no issues, but I haven't actually installed any additional brew packages that might interfere. 🤷🏽‍♂️

[gregmolnar]

My keyboard type is set to default in Konsole:

Try pressing the physical Ctrl+Shift+C keys when you set the shortcut, instead of Cmd+C.

That shows Alt+Shift+C.

[gregmolnar]

I tested the installer from the dev_beta branch and it works smoothly now even with homebrew on my path. Thanks for fixing it!

[RedBearAK]

I tested the installer from the dev_beta branch and it works smoothly now even with homebrew on my path. Thanks for fixing it!

That's excellent.

But did it do anything to fix the weirdness in Konsole?

That Alt+Shift+C thing is quite odd. If you run the manual command again to see the verbose logging, you should see some lines with modmap: when you tap modifier keys that are affected by an active modmap.

(DD) modmap: LEFT_ALT => RIGHT_CTRL [Cond modmap - Terms - Win kbd]

To make it much simpler to see you can of course grep for them:

toshy-config-start-verbose | grep -i "modmap:"

I'd like to see what those lines are when you tap the physical Ctrl key, the Meta/Super/Win key, and the Alt key. Something is just really not right. What kind of computer/laptop or keyboard are you using?

If you have the time and interest it might also be good to try the installer in a new test account. Just be aware that if you leave a manual instance of the keymapper running and use "Switch User" it can interfere with the other user's keyboard and keep you from starting the keymapper in the other user account. They will both try to use the same uinput device, and it's an exclusive thing. But running in both accounts from the paired systemd services will theoretically prevent that problem, because one service monitors whether your session is "active" on the screen and shuts down the other service while you aren't "active".

I'm really curious if your problem is system-wide somehow, or just in your account.

[gregmolnar]

It didn't fix the issue in Konsole, but I am not sure things work as expected everywhere else, either. Should I be able to jump words with physical alt and the arrow keys? I think that worked before, but not sure if I did something or Kinto did that.

Physical control key: (DD) modmap: LEFT_CTRL => LEFT_CTRL [Cond modmap - Terms - Win kbd] Win key: (DD) modmap: LEFT_META => LEFT_ALT [Cond modmap - Terms - Win kbd] Alt key: (DD) modmap: LEFT_ALT => RIGHT_CTRL [Cond modmap - Terms - Win kbd]

I am using a Framework: https://frame.work/

I will create a separate account later today to test that.

[RedBearAK]

Yes, Option+Left/Right (physical Win+Left/Right on a PC keyboard) should navigate word boundaries as it does in macOS.

That output shows the correct modmaps being active (Windows keyboard type) and the correct remaps of the physical modifier positions for that keyboard type. Alt becomes RC, Meta/Super/Win becomes the Option/Alt key, and in terminals there is no Meta/Super/Win key in the modmap, so Left_Ctrl stays Left_Ctrl. That's all correct. So... I can't even think of what else to look at, at the moment.

But as long as you're willing to continue trying to figure out what is going on, I'll keep throwing out ideas when I think of something. I think the new account (must have access to sudo) is the logical next step.

I assume you're using a standard US keyboard layout. But even if you weren't that shouldn't generally have an effect on the modifier keys.

Is there a snowball's chance you have some other keymapper running at the same time?

[gregmolnar]

Is there a snowball's chance you have some other keymapper running at the same time?

I tried to reinstall Kinto after the upgrade but it failed so I run the uninstall script of it, then tried toshy. Maybe there is some leftover somewhere and that messes up things. I will try to check that.

[gregmolnar]

I created a new account and toshy works perfectly there, so it must be something messed up with mine.

[RedBearAK]

I created a new account and toshy works perfectly there, so it must be something messed up with mine.

Thank goodness for that. Now we just need to figure out what the heck is going on in your main account. Check your ~/.config/autostart folder, the KDE Autostart control panel, anything you can think of.

I’ll have to check back on this later.

[gregmolnar]

I checked both of the autostart stuff but other toshy and enpass, I have nothing there, and I disable enpass too to make sure that doesn't interfere. I also disable the "Input actions" and "keyboard daemon", but no luck. I removed my whole ~/.config folder, but that didn't make a difference either. I checked the list processes, but nothing seems related. I will try to think about other things to check. The easiest would be just to move my .config to a new account and if that still works, I could just move over all my stuff, but this thing bugs me :D

[gregmolnar]

I figured it out! I am such an idiot. I had a custom .Xmodemap file for my account with remappings and that interfered with toshy probably. I got rid of it and finally I feel home on my laptop! I probably made that file to tweak something with Kinto, but I don't remember.

Thanks a lot for your help and for this tool! I am closing this.

[gregmolnar]

I still have some issues :(.

• As far as I recall super+click on a link should open links in a new tab, but maybe I need to configure that for the browser.
• Once I start toshy, my KWin shortcuts stop working. If I stop toshy, they work as expected.

Do you have any pointers to resolve these?

[gregmolnar]

I figured out the KWin issue. The shortcuts I had set were already used somewhere else, so there was a conflict. I changed them and now it works as expected.

[RedBearAK]

@gregmolnar

had a custom .Xmodemap file for my account

Aha! The "keymapper" I was looking for, and operating on a different level so keyszer (forked from the xkeysnail that Kinto uses) would have no idea what was happening. I'm guessing it remaps later in the input stack, which is why everything looked perfect in the Toshy/keyszer logging. If I understand correctly that probably wouldn't have worked in a Wayland session (but maybe its somehow independent of the X server, I'm no expert in that area).

I figured out the KWin issue. The shortcuts I had set were already used somewhere else, so there was a conflict. I changed them and now it works as expected.

And another layer is peeled back. Almost there.

super+click on a link should open links in a new tab, but maybe I need to configure that for the browser.

It should be Ctrl+click that does that on Linux/Windows browsers, and this should remap as designed onto the Cmd+click location, which on a PC keyboard is physical Alt+click. Alt becomes Right_Ctrl, which does the Cmd stuff in the config file, regardless of whether you're using a PC or Apple physical keyboard.

If you are not using an external mouse on the laptop, you are probably running into the issue I've always had with the keyszer "suspend" timeout feature, which tries to "hide" mod key presses from applications that are problematic with letting menus steal focus when you press something like Alt. This feature doesn't work well with touchpads/trackpads. For some reason the "events" from clicking or tapping on a touchpad are too different from mouse button clicks, so keyszer doesn't know how to catch them and disable the suspension of the modifier key press.

This is all in the FAQ section of the README, but the README is very long at this point. I don't expect most people to read it.

So here's the deal, last night I finally figured out one of the main things I've always wanted to fix, which is that user customizations of the config file will be retained when re-running the installer. This is done through a complex process of slicing up the contents of the existing config file and putting anything you've changed between certain marks into the newer config file. If you've done a reinstall recently enough, you should have the necessary "markers" in your config file to make this work. If not, you'll need to download the latest zip from dev_beta and run the install one more time to get the marks.

If you do have the marks, you can edit between the lines marked with keyszer_api and those changes should be retained from now on even if you re-run the Toshy install. What you need to try is changing the suspend timeout from 1 (second) to zero or 0.1, which will cause the suspend to be reverted fast enough to make Mod+clicking work on a touchpad.

It should end up looking like this:

timeouts(
    multipurpose        = 1,        # default: 1 sec
    suspend             = 0.1,        # default: 1 sec, try 0.1 sec for touchpads
)

You'll need to save this and then restart Toshy services from the icon menu, or the preferences GUI app (or with toshy-services-restart) to make a change like this work.

Do let me know if this solves your Mod+click issue. Shift+click selections of text, or Alt+click selections in something like VSCode, should also be something that starts working correctly.

Here's the FAQ entry about touchpads and suspend:

https://github.com/RedBearAK/toshy#touchpadstrackpads-and-keyszer-suspend-timer

And there's an entry right below it on how to fix the focus stealing menu problem in Firefox and VSCode(s):

https://github.com/RedBearAK/toshy#vscodes-and-firefox-menu-stealing-focus-when-hitting-optionalt

[RedBearAK]

Reopening issue until we can be sure everything is working as expected. Closing kind of messes with the way GitHub sends out notifications of new comments.

[RedBearAK]

Also, since you're on a bare metal install, and using X11/Xorg, you can try reducing the default throttle_delays settings down to 1 ms each. I have the delay defaults set to about 8/12 because there are often issues with Mod+key timing especially on Wayland, and it would be hard for most users to initially diagnose what was happening. But the delays can cause unwanted buffered repeating of keys that are held down for more than a brief time.

# Delays often needed for Wayland (at least in GNOME using shell extensions)
throttle_delays(
    key_pre_delay_ms    = 8,      # default: 0 ms, range: 0-150 ms, suggested: 1-50 ms
    key_post_delay_ms   = 12,      # default: 0 ms, range: 0-150 ms, suggested: 1-100 ms
)

throttle_delays(
    key_pre_delay_ms    = 1,      # default: 0 ms, range: 0-150 ms, suggested: 1-50 ms
    key_post_delay_ms   = 1,      # default: 0 ms, range: 0-150 ms, suggested: 1-100 ms
)

I don't really recommend setting them to zero anymore. There are just too many situations where that has been a problem, and it's an intermittent problem, so it's frustrating to troubleshoot when it's happening.

FAQ entry on this:

https://github.com/RedBearAK/toshy#option-key-special-character-entry-or-macros-acting-weird

[RedBearAK]

@gregmolnar

I've added a very obvious alert/warning that will immediately display when you run the installer, if the user has an .Xmodmap file in their home folder. If you want to test it, you can just touch ~/.Xmodmap to make a new file if you've removed the one you had, or you won't see the warning. It's not checking the contents, so the file can be empty.

I think it's relatively common for Linux users to still be using that file to change their keyboard behavior, so it was good to run into this problem and be forced to find a mitigation. This way the user will need to read the warning and enter a random code to acknowledge the awareness of the file and how it might cause issues with Toshy. 👍🏽

Once again this is only in the latest commits to the dev_beta branch, so you'll need to re-download the zip. It is working well in testing.

Re-running new installers at this point should not damage any customizations you've made to the config file, or settings you've changed via the tray icon menu or preferences GUI (which get saved into an sqlite3 database file).

[RedBearAK]

Everything has been merged into main at this point. The dev_beta branch has been deleted until I need to work on something else.

[gregmolnar]

Thank you so much! I will test the Xmodmap change and will tweak my throttle_delays later today.

[RedBearAK]

I kind of did a "release" because I improved a number of things including some KDE related stuff (but that's mostly about fixing Wayland+KDE support).

If you have further problems, open a new issue thread and let me know what's going on. Thanks!

[gregmolnar]

Thank you! I will test the update and open an issue if I find any problems.