I'd be ok with this for Kate.
Regarding the colorscheme to use; I was recently trying out a couple of options:
I'm adding you're ideas to the task to-do list
I am happy to hear that!
I don't know easy or feasible is to map applications to its wmclass string
I was wondering about that. Hopefully there is an easy way. But ye, this is one of the things that can be done any time later I think.
- Only display conditions that are in use: I am a bit unhappy that I solved this differently than with the "Show all rules"-button. I went with the approach of adding/removing conditions because I thought having a checkbox to enable/disable conditions wasn't easy enough to understand. I especially thought this would be a problem when a new rule is created and the user is faced with five unchecked conditions.
I find your approach (Add/Remove) better from an user point of view, although the problem I see is how to present the possible effects that can be added to the user, that is, what happens when you press "+ Add.... Have you something in mind?
I was thinking about this some more but didn't come up with a way to solve this better than in my mockup. I think it might be fine though. For the "conditions" list the "Add conditions" button would have a dropdown with entries like "Add application condition", "Add window title condition", "Add window type condition", … This way no secondary window is necessary to create a rule. I would guess that most of the time only one or two conditions would be added this way and because there are only a few possible conditions to choose from a dropdown is a great fit here.
For the "rule effects" list the current behaviour has the same benefit of not making a secondary window necessary. The big list of possible "effects" needs to be somewhere and putting it in another window that spawns when clicking an "Add …" button wouldn't make the UI more understandable IMO (although this wouldn't be a bad way to solve this either). The workflow of activating effects in a rule by clicking its checkbox also makes sense IMO (contrary to the "conditions" list).
So yea, although it is a bit unfortunate to have two different ways to add objects to a list in the same window it might still be the best solution for the window rule modification/creation.
Tue, Feb 25
Just to repost and add a bit from the darker breeze dark diff:
Hmm, I think you need to rebase to remove unrelated files in this patch e.g. dropjob.cpp ... ?
I felt that the transparency was not working very well with the headerbar on some wallpapers, so I toned down the transparency a bit, going from
Mon, Feb 24
With regards to the default Breeze color scheme, I agree that it doesn't need much. To support the "Tools area" idea, we would need to lighten the titlebar color to a light-medium gray, since this would become the background color for the entire tools area. What we do with other colors is something I'm happy leaving up to you guys.
I really like your mock-up! Some of the ideas also crossed my mind when I first approached the KCM but I couldn't visualize them in a nice way like you did. I'm adding you're ideas to the task to-do list, although maybe they'll have to wait (with some others) until we get a first functional patch, and be added in the "polish" phase.
Any mockups for plasma mobile elisa?
Oh I see what you mean: an alternate background color, not alternating background colors.
What I'm saying is that doing something like what VS Code does could work for making views next to views look good, like a sidebar next to a list view.
One way we could get views next to other views to look right is to use the alternate view background color for sidebars
Sun, Feb 23
This looks much better! Only showing preferences that are part of the rule by default for already existing rules is a good idea too imo.
Let me know if you want me to look at any of these specific tasks.
Sat, Feb 22
There's interest in this. See D24009
Fri, Feb 21
What I'd like to see is a matching design for the lock screen pin and SIM pin fields
I don't know if it would be best at this stage to create a RFC code review or upload it to a new <user> branch.