Open thiagoa opened 4 years ago
Here's a quick hack that I'm using to trigger the Activities Overview while this problem doesn't have a solution. It's ugly but creative :smiley:
https://github.com/thiagoa/bin/blob/master/gnome_activities_overview
The comments explain how it works. I've disabled the default Overview keybindings and mapped a custom keybinding for it.
Try this:
# -*- coding: utf-8 -*-
import re
from xkeysnail.transform import *
WM_LIST = [
# "konsole",
# "dolphin",
"vlc",
"Kodi",
"ksmserver"
]
define_keymap(None or (lambda wm_class: wm_class not in (WM_LIST)), {
K("EJECTCD"): K("Ctrl-Alt-DELETE"),
K("KEY_AUDIO"): K("a"),
# K("KEY_ANGLE"): K("Ctrl-Alt-Super-l"),
K("KEY_SUBTITLE"): K("l"),
K("KEY_CLEAR"): K("Shift-C-M-d"),
}, "Global")
define_keymap(re.compile("Kodi|vlc"), {
K("EJECTCD"): K("Ctrl-Alt-DELETE"),
K("KEY_AUDIO"): K("a"),
# K("KEY_ANGLE"): K("Ctrl-Alt-Super-l"),
K("KEY_SUBTITLE"): K("l"),
K("KEY_CLEAR"): K("Shift-C-M-d"),,
}, "Kodi e vlc")
define_keymap(re.compile("ksmserver"), {
K("EJECTCD"): K("esc") or K("Alt-f4"),
K("BTN_MISC"): K("esc") or K("Alt-f4"),
K("ENTER"): K("ENTER"),
K("LEFT"): K("LEFT"),
K("RIGHT"): K("RIGHT"),
}, "ksmserver")
@luizoti What is the change you are suggesting?
I've never used the newest KDE, but Gnome Shell widgets do not have a WM_CLASS.
Adopting your example, if Kodi was focused prior to triggering Activities Overview, I would expect the bindings from the first define_keymap
to be active, but WM_CLASS
would still be Kodi
, so the bindings from the second define_keymap
would still apply.
From you example, I imagine you can match against ksmserver
to do the trick in KDE :thinking:
@thiagoa, eae tudo blz, só vi que vc era BR agora, depois de escrever kkk
Adopting your example, if Kodi was focused prior to triggering Activities Overview, I would expect the bindings from the first define_keymap to be active, but WM_CLASS would still be Kodi, so the bindings from the second define_keymap would still apply.
In theory, if kodi were focused, but you opened Activities Overview, WM_CLASS should be changed to Activities Overview OR be recognized as None.
But if I understand you correctly, the Activities Overview doesn't have WM_CLASS right?
From you example, I imagine you can match against ksmserver to do the trick in KDE thinking
Likewise, ksmserver is just another window, WM_CLASS.
What is the change you are suggesting?
Follow my complete configuration via pastebin, notice that in the 'global' config, I define all the keys that will work in plasmashel (None), in the kodi / vlc profile, I repeat all the keys changing only a few that will work only in kodi.
MAYBE (if you haven't already tried) this setting, it can solve your problem, but from your report, I believe it doesn't work.
In my first installation, this part of the configuration solved my problem, if my memory does not fail, when WM_CLASS has no profile and is not in WM_LIST, the profile 'None' applies, I am almost sure that this is the behavior:
WM_LIST = [
"konsole",
# "dolphin", "vlc", "Kodi", "ksmserver" ]
define_keymap(None or (lambda wm_class: wm_class not in (WM_LIST)), {
@luizoti Na paz 🙂
The problem is that xkeysnail detects the WM_CLASS of the background window instead of the Gnome widget's. Therefore, I can't use None
to match the Gnome widget. Thank you for chiming in, anyway.
As is GNOME screen lock.
This sort of makes sense actually... Gnome Activities Overview isn't really a window exactly... If you could raise this as an issue against the Gnome project (asking them how we might go about detecting the activities overview was active) and link to that issue here I'd love to participate in that discussion. Reaching out to them on the libinput issue the other day proved very instructive.
As is GNOME screen lock.
You're saying it has the same issue, as being a non-window and hence WM_CLASS doesn't change?
For some reason, xkeysnail will detect the WM_CLASS of the application that was previously focused after triggering Gnome's Activities Overview. This is not desirable when the user has application-specific mappings, which end up reflecting in Activities Overview depending on the app that was focused before launching it.
The reason might be that the Activities Overview doesn't have a WM_CLASS (it is a root window, maybe?), but I wonder if we could have the software detect these special cases somehow.