Summary: | Reimplement Window Actions from KHotkeys for Wayland | ||
---|---|---|---|
Product: | [Applications] systemsettings | Reporter: | Andrew Shark <ashark> |
Component: | kcm_kwinrules | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | CONFIRMED --- | ||
Severity: | wishlist | CC: | dashonwwIII, isma.af, mariusz.libera, nate, plasma-bugs |
Priority: | NOR | Keywords: | wayland |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=455444 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Create new window action
Trigger tab and edit window match fields |
Description
Andrew Shark
2022-12-06 11:55:42 UTC
Window Rules seems like a logical place for this. What does/did Window Actions do? Window Rules implementation does not work as it intuitively might seem from the configuration. They just act as a filter/block for some properties of the window which are set/forced/limited to certain values when modified, and their use is scattered around the KWin codebase to be as close as possible to where those properties are set. So depending on the actual functionality of the feature it may/may not be the right place for it. If it's about launching custom scripts on response to certain window changes, I think the scripting API is more suitable (and powerful) to reimplement it. Even as a 1st-party buit-in/add-on script. Created attachment 154416 [details]
Create new window action
Created attachment 154417 [details]
Trigger tab and edit window match fields
Yes. Window Actions can run one of three things: arbitrary command, dbus command, simulate keyboard input. See screenshots. In Trigger tab you can choose when to trigger: window appears, window disappears, window looses focus, window gets focus. And you have a list of window match rules (by class, by title, by something called window role (I do not know what it is), by window type). How I used it. I created a rule that match steam games, and when window gets focus, run a command to change my physical monitor color preset to Game. And oppositely, when steam game looses focus, revert monitor preset to Comfort View (yellowish colors). My project is https://gitlab.com/AndrewShark/monitor-commander. The downside is that in trigger tab we do not have trigger by window changing monitor (see Bug 436062) and you have to make the same list of windows to match two times (for the gets focus and for the looses focus). I can agree that maybe such window actions module is not something to be in system settings. Also because of downsides I said above. I happily will implement it in my app/widget, but how can I do it? Is there something like I can listen to window actions from kwin (events like the window with such title just got focus and so on). What is the starting point of programming this? So the resolution of current bug will be Resolved Intentional, right? |