This reverts commit ef234aca49.
CCMAIL: uhhadd@gmail.com
CCMAIL: kde@david-redondo.de
This commit was inappropriately reverted with no discussion for the
second time, ignoring the comment recommending against it in
https://invent.kde.org/plasma/breeze/-/merge_requests/82#note_190308.
This is a community project and you are not the maintainer. Please do
not revert this again, and also stop reverting changes you disapprove
of without discussion. This is an inappropruate use of your commit
rights and may result in their revocation if you keep doing it.
Further offenses will be reported to the CWG.
This reverts commit 9f40b17e57.
The idea of a Tools Area separator only makes sense when there is a unibody
Tools Area. When using a color scheme without Header colors, there is no
Tools Area (just a disparate collection of titlebars, manubars, and
toolbars), so the line is just extra visual noise that various people
have objected to following the Plasma 5.21 release. Let's make it
conditional on using a color scheme with Header colors again.
BUG: 433118
FIXED-IN: 5.21.1
If the style is unloaded for example by an application dynamically
switching styles, the listener was still around leading us to call
into destroyed objects when the color scheme was changed.
BUG:432660
This reverts commit ce4e031fc7.
This has been annoying when debugging the tools area, and also causes
many colour schemes that would look good with a tools area border to not
draw one. The cases where this commit improves on are far outweighed by
the ones where this commit causes a visual regression.
This reverts commit 0deecb4d57. This commit
caused many regressions in regards to how the tools area handles changing
toolbars at runtime, and doesn't even properly handle most cases where there
are no changes after application initialisation, as you cannot assume the widget
tree is fully complete at ::polish time.
Never mutate a widget while painting! This causes recursive repaints and makes
prorgams crash. There is a reason why const_casts are discouraged.
BUG:432246
FIXED-IN: 5.21
Effectively do the same as in the past when we do not have a headers group.
Trigger for this is that the line does not work in such cases but we also
do not need to draw the background in any special way then.
It can happen that an application uses a QMainWindow in its widget hierachy for
its features but does not correspond to an actual window. Only alter those
toolbars for the unified look whose QMainWindows are actual windows and as such
have a window decoration.
BUG:427410
Alexander Lohnau
Nate Graham
Jan Blackquill
David Redondo