Bug 462702 - Reimplement Window Actions from KHotkeys for Wayland
Summary: Reimplement Window Actions from KHotkeys for Wayland
Status: CONFIRMED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_kwinrules (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: wayland
Depends on:
Blocks:
 
Reported: 2022-12-06 11:55 UTC by Andrew Shark
Modified: 2023-10-01 03:22 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Create new window action (316.67 KB, image/png)
2022-12-08 06:30 UTC, Andrew Shark
Details
Trigger tab and edit window match fields (236.74 KB, image/png)
2022-12-08 06:32 UTC, Andrew Shark
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Shark 2022-12-06 11:55:42 UTC
Due to UX regression when deleting "Custom Shortcuts" on Wayland (see #Bug 455444), there is now no more way to configure actions triggered by windows activating/deactivating.

As an idea, I suggest to add this functionality again. For example to new kcm: System Settings -> Window Management -> Window Actions.

The interface for now I think could be copied from the original kcm.
Comment 1 Nate Graham 2022-12-06 18:43:28 UTC
Window Rules seems like a logical place for this.
Comment 2 Ismael Asensio 2022-12-07 18:34:32 UTC
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.
Comment 3 Andrew Shark 2022-12-08 06:30:23 UTC
Created attachment 154416 [details]
Create new window action
Comment 4 Andrew Shark 2022-12-08 06:32:40 UTC
Created attachment 154417 [details]
Trigger tab and edit window match fields
Comment 5 Andrew Shark 2022-12-08 06:53:44 UTC
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?