Registered Member
|
Ahoj VDG,
I've just upgraded to Plasma 5.2 beta and loving the new or returned features. It's much smoother too but... This is the first time I've used the Breeze windeco. I thought there was a bug but actually it turns out it's a feature that I don't understand. By default, the breeze windeco config option 'Display window borders for maximised windows' is disabled. This seems to remove the top few lines of pixels from the windeco when windows are maximised. The buttons and text don't look vertically centred- it's really annoying to look at. Who is this feature aimed at and why is it this configured this way by default? P |
KDE Developer
|
This is (IMO) more a bug of the maximised borderless implementation of the decoration than the problem of a default setup.
|
Registered Member
|
Yes indeed it is. Not drawing borders around maximized windows by default absolutely makes sense as they serve no purpose then, this just wasn't considered when designing and implementing the Breeze windeco. Thank you for pointing this out to us, pepedopolous, we're on it! |
Registered Member
|
Hi
Text vertical centering can be easily fixed. Button vertical centering is more problematic. The idea with removing the top few pixels is Fitt's law: you move your mouse against a corner, and a button must be hit, not an inactive border. So unlike unmaximized windows there must be no (software) margin between button and maximized deco border. So either: - remove the botton margin too, but that would likely make the decoration too skeezed - add a 'fake' virtual margin inside the button, to extend the hit area without breaking vertical centering. I'll work on the second, but it requires a bit of testing Not sure what to be done with horizontal positionning (putting a fake margin here will be even more complex because this would affect all buttons, and then, you'd need to squeeze the 'spacing' between buttons accordingly) Hugo |
Registered Member
|
OK, so I guess this needs more discussion...
One more thing about the windeco... I use the Breeze Light colours so the windeco colour matches the window colour. However, there is a blue line between the windeco and window itself. is there any easy way (e.g. editing a config file) to remove this blue line so the windeco and window are totally contiguous? Cheers, P |
Registered Member
|
Nope, asside from modifying the code. The blue line (for active windows only), is part of the design. |
Registered Member
|
[quote="hugo.pereira@free.fr"][quote="pepedopolous"]OK, so I guess this needs more discussion...
One more thing about the windeco... I use the Breeze Light colours so the windeco colour matches the window colour. However, there is a blue line between the windeco and window itself. is there any easy way (e.g. editing a config file) to remove this blue line so the windeco and window are totally contiguous? P[/quote] Nope, asside from modifying the code. The blue line (for active windows only), is part of the design.[/quote] More precisely, you can, by setting the "text selection" color of the color palette to the window background. |
Registered Member
|
P[/quote]
The blue line (for active windows only), is part of the design.[/quote] Fair enough, but (apart from when I use the Breeze Light colour scheme), this line is so thin I can barely see it. This is on a 13.3 inch 1080p laptop screen. With the standard Breeze colour scheme, the difference between active and inactive is obvious without this almost-invisible line. Then as a side effect, it spoils the use of the Breeze Light colour scheme. P |
Registered Member
|
Actually the blue line was meant to be configurable for just this reason. The QML version of the decoration had a config option to disable the active highlight. So, if it's not already there, it would certainly be desirable to have that option again in future. |
Registered Member
|
Oh I was not aware about this ! I sure can make it configurable. Now, question: would it make more sense, not to add an option, but instead automagically hide it when the active decoration color matches the window background ? and render it in all other cases ? Your call ... Hugo |
Registered Member
|
PS: the nice thing about the second option is that it can go also in plasma 5.2, since it introduces no new string (and can be considered a bug fix)
|
Registered Member
|
Madly hunting for 'Like' button! P |
Registered Member
|
Sure why not try it! Ideally the active highlight would disappear for a active titlebar color close to the window background color, but for simplicity, let's just go with matching (and call it a bugfix for the 5.2 branch since it's pretty low risk). |
Registered Member
|
|
Registered Member
|
Awesome way to solve this, Hugo!
If an automatism yields the optimal results in 99% of cases anyway, it is indeed superior over yet another config option. |
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan