RedBearAK / toshy

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

(Enh) Config file for Windows-like remaps #233

Open RedBearAK opened 6 months ago

RedBearAK commented 6 months ago

This is an issue to track the development of a new config option to make Linux apps conform to some common Windows shortcut combos, as an alternative to the config file that makes Linux conform to macOS shortcut combos.

Add comments for the apps that will need keymaps, and possibly a general keymap if there is any particular global shortcut that does something in Windows that it doesn't do in Linux.

Good rule of thumb to keep your config file readable: Align things on columns 5, 33, and 65 in the keymaps. A good code editor will show you the column number, a better one will let you set up a plugin that will allow you to quickly "indent to column" to these specific columns. I use an extension in VSCode for this.

keymap("Dolphin", {
    C("Shift-C-n"):             C("F10"),                       # Create new folder (F10), pre-KF6
}, when = lambda ctx: 
    matchProps(clas="^dolphin$|^org.kde.dolphin$")(ctx) and 
    DESKTOP_ENV == 'kde' and 
    DE_MAJ_VER in ['5', '4', '3'] )

This sample keymap demonstrates that keymaps have a "name" argument, then a Python dictionary argument (the curly braces and everything inside them), and then a "when" conditional argument, which is an expression of some kind that evaluates to truthy or falsy to determine when the keymap becomes active. In the sample, the keymap becomes active in Dolphin, in the KDE Plasma desktop environment, and only if the KDE major version is 5, 4, or 3, but not in Plasma 6. Most "when" conditionals don't have to be this complicated, but this shows what can be done.

RedBearAK commented 6 months ago

To illustrate the idea of having some remaps affect the whole application, and some that only affect a specific window or dialog of the application, here's a pair of slightly modified sample keymaps from Toshy's default macOS config file for KWrite. The remaps may need to be modified to make sense from a Windows perspective.

keymap("KWrite text editor - Close Document dialog", {
    C("C-d"):                   C("Alt-d"),                     # [D]iscard file without saving (from Close Document dialog)
    C("C-s"):                   C("Alt-s"),                     # Save file (from Close Document dialog)
}, when = matchProps(clas="^kwrite$|^org.kde.Kwrite$", name="^Close Document.*KWrite$") )

keymap("KWrite text editor", {
    C("C-comma"):               C("Shift-C-comma"),             # Open preferences dialog
    C("C-t"):                   C("C-n"),                       # New tab (new document)
}, when = matchProps(clas="^kwrite$|^org.kde.Kwrite$") )
xcel102 commented 6 months ago

Installing Toshy on KDE, even with the --barebones-config option, disables single-pressing the Windows key (a.k.a. Super/Meta) to open the "Start Menu."

  1. Currently, the user needs to follow the "KDE Plasma and the Meta/Super/Win/Cmd key" section in README.md to undo this change.
  2. In the future if an install option is created to emulate Windows, this tweak should not be applied.
  3. --barebones-config can also consider skipping this tweak.
(EV) Toshy env module sees this environment:
                 DISTRO_NAME     = 'opensuse-leap'
                 DISTRO_VER      = '15.5'
                 VARIANT_ID      = 'notfound'
                 SESSION_TYPE    = 'x11'
                 DESKTOP_ENV     = 'kde'
                 DE_MAJ_VER      = '5'
RedBearAK commented 6 months ago

Currently, the user needs to follow the "KDE Plasma and the Meta/Super/Win/Cmd key" section in README.md to undo this change.

@xcel102

Well, technically you should be able to do:

./setup_toshy.py remove-tweaks

... and that should reverse the change to the Meta-only shortcut. And I think that has already been adjusted for Plasma 6.

But it shouldn't get applied for the barebones config, for sure. I'll work on disabling that.

RedBearAK commented 6 months ago

From the Reddit chat:

  1. I see you provided some examples in the issue, and I can also look at examples in the default toshy_config.py. But is there any reference or documentation for the syntax? For example, what are all the functions/keywords to be used in the dictionary? So far I've seen C(), UC(), isDoubleTap(), ignore_combo, None, and a list like [C(), C()]. How are the non-alphanumeric keys named (for example I see "Grave" but don't know what key that is)? Are the letter keys case sensitive (I see both)? And so on.

There's the documentation for keyszer at https://github.com/joshgoebel/keyszer/, which is relatively sparse but it will explain things like modmap() and keymap(), and there is a sample config file. However I have made a lot of custom functions, and a lot of the functions you see in the default Toshy config file are just shortened aliases to the full function name. Some things like matchProps() are new custom functions sitting in the config file. Most everything else is imported from the config_api.py file in keyszer. But also sometimes aliased even in there, like C() which is short for combo().

The key names can be found in the key.py file in the keyszer repo. "Grave" is the key on a US layout right above Tab, with the Shifted character being "Tilde". You might be used to calling it the "Backtick" key, but that's really the Grave accent, the opposite tilt from the Acute accent [áéíóú]. Grave comes up a lot as the key used in macOS for in-app task switching.

Reference: https://github.com/joshgoebel/keyszer/blob/main/src/keyszer/models/key.py

  1. I found a bug in README.md. Rather than asking you to fix it, I wanna try to contribute. Is the flow in https://git-scm.com/book/en/v2/GitHub-Contributing-to-a-Project relevant? I've used GitLab a little at work, but only direct pushes.

I'm still no expert in git. Basically if you make a fork and apply your changes to the dev_beta branch when submitting a PR, that will be the easiest for me to test before merging with main. I like to work in dev_beta and test things there first. That's about all the guidance I can give at the moment for contributing.

RedBearAK commented 6 months ago

A fix for the installer messing with the Meta-only shortcut when using the barebones config has been applied to the dev_beta branch. When those functions are called they should just print out a message about not doing anything and return.

def apply_tweaks_KDE():
    """Utility function to add desktop tweaks to KDE"""

    if cnfg.barebones_config:
        print('Not doing tweaks due to barebones config flag.')
        return

...

def remove_tweaks_KDE():
    """Utility function to remove the tweaks applied to KDE"""

    if cnfg.barebones_config:
        print('Not removing tweaks due to barebones config flag.')
        return

...

You can test it by downloading the zip from the dev_beta branch and trying a reinstall.

EDIT: I tried it, it doesn't work yet, except for during the main install command. I have to design a function to independently check for the barebones config file (if the --barebones-config option wasn't given). Right now that check only happens in extract_slices() when the installer tries to save your existing config file custom contents. So a basic install won't mess with the Meta-only shortcut, but the apply-tweaks and remove-tweaks will still mess with it.

RedBearAK commented 6 months ago

Fixed the installer thing I tried to fix before. This time it works. The installer shouldn't disable the Meta-only shortcut anymore if the barebones config file or flag is detected.

Thanks for noticing that. Good thing you found the FAQ entry to fix it.