The current way to get color matching between app color and title-bar color is tedious for users (especially since GTK apps don't follow KDE color schemes). I am wondering if it could be done in a way that requires less user input Some ideas: 1. (KWin feature, invasive, lots of work for developers) A script polls (or examines at first launch) the color under the title-bar - usually in the upper left corner - and sets the appropriate titlebar color, maybe with some user input if at first launch. 2. (KCM, user-input) Setting to change the titlebar color only without having to create a new color scheme. The complementary color values for active/inactive text should be automatically generated based on the the chosen app-specific tile-bar colors and the based on the contrast values implied by the global color scheme.
Separating the app-specific titlebar color from the color schemes may also make it possible to specify the titlebar color at launch, which means app-developers could theoretically define the color value in their launcher script, so things look nice with zero user input. Anyway, sorry if this is a frivolous request.
Can you clarify the goal? You want the titlebar to effectively disappear into the window chrome? Many themes do color-match the titlebar and window chrome, so that might be the way to go. Oxygen does this too.
I personally would prefer the titlebar to look different from the chrome, but with the same base color. Sort of like Adwaita does it. There is trend to have matching colors: android, Gnome, Mac, Windows, they all do it. But yeah the most common use for Kwin color theme rules is to make the bar color match the window chrome for applications that don't follow KDE themes well or at all. With global menu it gets worse, cause the menubar - part that usually follows some system color - gets removed. I think it is logical to decouple app-specific titlebar colors from color schemes. This would make assigning such colors easier for both users (and potentially developers), as it would allow you to set the titlebar color without creating a whole scheme. Ultimately, it could even be automated, but that's a much bigger project.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
info has been provided.
TL;DR. The user should be able to change the titlebar color (to match window chrome or for other reasons) without having to create a whole new color scheme. Most of the time, all you really need is just the active window color. The inactive titlbar color, text color could be inferred from colors and contrast values of the active color scheme. Just pick one color and you're done. If the user wants they can provide these other values they can, but most of the time it's not necessary for what the user is trying to do.
(In reply to leftcrane from comment #6) > TL;DR. The user should be able to change the titlebar color (to match window > chrome or for other reasons) without having to create a whole new color > scheme. Why work around the systemwide color scheme? It seems to me that the only legitimate use case for this is assigning per-app titlebar colors. Is that accurate?
The point is inherit some values regarding contrast from the main theme. That way the user can define as few colors as possible (usually they just need to define one color). - contrast between the active titlebar background, the active titlebar text, the inactive and the inactive titlebar text. - contrast between the titlebar background+text and the window menu background+text. (if you think it's a good idea to color the window options menus based on the titlebar color, your call) So you just define set the active titlebar color to match the window chrome and all the other values are inferred, unless you want to override them. Regarding separation, I guess you're right. These will technically still be defined as regular KDE color schemes on disk. But they shouldn't clutter up the color shemes KCM module, cause they are play a different role for the user.
We need to get more specific regarding the goal before we can jump to implementation ideas. Is the idea here to: - Optionally allow users to choose custom per-app titlebar colors? - Optionally allow allow the window manager/compositor (i.e. KWin) to dynamically color the titlebar according to the window chrome underneath it?
a) Having KWin do all the work would of course be ideal (the user would still be able to override just like they do now with rules). Capture the inactive and active window chrome at every launch, or capture once at first launch? I can see a problem with the second scenario, since themes and dark/light modes change. Maybe also have an API so the app can directly tell KWin what colors to use? (Of course most will never use it, sadly, but some might.) b) Having the user define the color is less than ideal, but if we have the user defining the color, they should only have to define one value (unless they want to define more, for whatever reason). Both options are an improvement on the current way of doing things, your call.
"Capture the inactive and active window chrome" Capture the color of the chrome, i mean.
To be honest I don't see this happening. Having KWin sample the window colors and match them with the titlebar's color automatically opens a huge can of worms. What do we do about games and other "windowed full screen" apps? Or apps that have no chrome and draw multiple colors right below where the titlebar goes? Etc. It just can't work. Adding an API would be pointless since practically nobody would use it, defeating the point. Allowing users to override titlebar colors on a per-app basis doesn't strike me as a feature useful enough to implement outside of the normal color scheme mechanics. The poor-man's way to accomplish that right now is to create custom color schemes that differ only by titlebar colors, and use KWin rules to force specific apps/windows to use them.
Yeah, I see the problem with video players, for example. But these would be these exception. Currently, I have non-matching titlebar/chrome for about 10 apps on my system. To get them to match, I'd have to perform 260 actions with keyboard and mouse using three separate dialogs. With the proposed manual method, it'd be max 50 actions using one dialog (one could optimize it down to 20). So I'd say the proposed manual method would make matching at least doable for the user. But if no then no.
It sounds like you should just use a theme that has matching titlebar and chrome colors then, no? Why try to coerce Breeze into doing this when it's not a design goal?
Oh these apps don't follow any system color scheme (different toolkit, or it's a text editor or terminal). And there is mismatch built into some gtk and kvantum themes, that shows up under certain circumstances, though that's another issue. It all looks pretty bad it's just too much work to fix it using the current method. I think it'd be worth it, as frivolous as it sounds. One of the upsides of Gnome CSD is that the the chrome and decoration are in sync with each other. Looks much more professional and offers some possibilities to developers. Such a thing could be done for SSD too, and it might become even more relevant for KWin if DWD ever materializes.
Oh yeah, I forgot all the dark theme apps. So it's actually way more than ten apps (I have a rule for those though).
CSDs are an anti-solution that regress usability in a million and one ways, and, as implemented, worsen the problem described here. I want what you want too, but given the diversity of toolkits in the Linux world, and the inability of certain toolkit vendors to conform to the standards, it's simply not going to happen anytime soon. :(
you mean DWD? stuff like titlebar coloring doesn't require toolkit support or DWD. it just seemed like it would be relevant to the overall goal of closer integration between the ssd and apps, which seems worthwhile imo. re: discussion of DWD/DWD-like features I sent you a quick message on reddit.
Does anyone think this a good idea? Currently you force a specific title-bar color by creating a whole color scheme, then creating a kwin rule, then setting the color scheme in the rule. Then the color schemes and rules will clutter up your settings. Can't this process be whittled down to fewer actions? As in: Window settings -> force titlebar color -> pick a color -> DONE. It would just set the titlebar color and inherit everything else from the active scheme.
The custom titlebar color feature can really improve the appearance of certain windows, but the amount of work that it requires is just prohibitive.
Instead of building a complicated system to facilitate workarounds, I think it would be better to fix the apps that look ugly. :) We already have a "good enough" workaround system, so IMO any further effort would be better spent fixing the issue itself.
But they are never getting fixed because they aren't designed for KDE and never will be. We are talking mainly about electron apps, different browser profiles (where different colors are the whole point) light and dark apps (gtk theme variants and all terminals) etc. These aren't solvable on the app level. The feature to recolor the titlebar is there so why not make it usable?
Also light-dark variants in Kvantum that don't apply to the window border. It's not an issue with Breeze because breeze doesn't support the user launching apps with different color variants - but that's a deficiency of breeze compared to gtk and kvantum.