Bug 442218 - Window rules grouping/sorting
Summary: Window rules grouping/sorting
Status: ASSIGNED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_kwinrules (other bugs)
Version First Reported In: 5.22.5
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: Dominik Kummer
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2021-09-09 10:37 UTC by Dominik Kummer
Modified: 2024-05-02 13:35 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dominik Kummer 2021-09-09 10:37:11 UTC
SUMMARY
Managing windows with a myriad of myriad window rules is great.
However, this rule list can not be filtered/grouped.
How about optional rule grouping by window class, and optional filtering by keyword (similar to shortcuts settings)

STEPS TO REPRODUCE
1. systemsettings5 > windows management >window rules

OBSERVED RESULT
Many added (more than 20) rules cannot be filtered or grouped, so it is hard to manage.

EXPECTED RESULT
Filtering may be most intuitive by keyword, and grouping by window class.
Another report (https://bugs.kde.org/show_bug.cgi?id=416440) suggested sorting by name, but IMHO that would be confusing because the rules can be sorted by execution order, right?

Operating System: archlinux
KDE Plasma Version: 5.22.5
Comment 1 Ismael Asensio 2021-09-09 13:52:37 UTC
Yes, grouping would be a bit difficult/confusing, as the execution order is important in this case.

Filtering by keyword though seems a sound addition for users who manage lots of rules. When filtering, reordering the rules should be probably disabled to avoid conflicts.
Comment 2 Dominik Kummer 2021-09-10 10:21:47 UTC
A tree model could help to group the rules without confusion/conflict because a tree can be processed orderly.

As the rules are unique by name, a filtered list (or tree) could be reordered without conflict. In a list of [A, B, C] which is then filtered to [A, C] then [A] can still be moved behind [C] to result in [C, A]. After unfiltering the list looks like [B, C, A]. But within a tree structure [A] could probably move into another "directory/group". On the other hand the tree structure could still be visible during applied filtering, so a move operation across directories is always transparent and comprehensible.