Differential D27669 Diff 76435 kstyle/breezetoolsareamanager.cpp

Changeset View

Standalone View

View Options

kstyle/breezetoolsareamanager.cpp

  • This file was added.
1​#include "breezetoolsareamanager.h"
2​#include <QObject>
3​#include <QWidget>
4​#include <QToolBar>
5​
6​namespace Breeze {
7​ ToolsAreaManager::ToolsAreaManager(QObject *parent) : QObject(parent) {}
8​
9​ void ToolsAreaManager::registerWidget(QWidget *widget)
10​ {
11​ connect(this, &ToolsAreaManager::toolbarUpdated,
12​ widget, [widget]() {
13​ widget->update();
14​ });
15​ auto toolbar = qobject_cast<QToolBar*>(widget);
16​ if (toolbar) {
hpereiradacostaUnsubmitted
Done

This is not needed. Since all animations are created as children of the ToolsAreaManager, they should be deleted automatically when this one is destroyed.
This way you can simply remove the class destructor altogether and rely on the default one (from QObject).

hpereiradacosta: This is not needed. Since all animations are created as children of the ToolsAreaManager, they…
17​ connect(toolbar, &QToolBar::visibilityChanged,
18​ this, [this]() {
19​ emit this->toolbarUpdated();
20​ });
21​ connect(toolbar, &QToolBar::orientationChanged,
22​ this, [this]() {
23​ emit this->toolbarUpdated();
24​ });
25​ connect(toolbar, &QToolBar::topLevelChanged,
26​ this, [this]() {
27​ emit this->toolbarUpdated();
28​ });
29​ }
30​ }
31​}
32​No newline at end of file
hpereiradacostaUnsubmitted
Done

As far as I have followed the code you need an "unregisterWidget" for when widgets are unpolished and to remove windows from the map.
You also need a connection to the destroyed signal to cleanup the map when a widget is deleted, otherwise you will keep accumulating an ever growing map of dangling pointers.

hpereiradacosta: As far as I have followed the code you need an "unregisterWidget" for when widgets are…
hpereiradacostaUnsubmitted
Done

you can break here once one widget is found. no need to loop over the remaining widgets.
alternatively you can use std::any_of or (better) std::none_of

hpereiradacosta: you can break here once one widget is found. no need to loop over the remaining widgets.
davidreUnsubmitted
Done

This needs at least a comment why we have this hack for telegram

davidre: This needs at least a comment why we have this hack for telegram
ngrahamUnsubmitted
Done

This seems to make the window content move vertically when the window loses focus

ngraham: This seems to make the window content move vertically when the window loses focus
cblackAuthorUnsubmitted
Done

Eh? What application do you see this behaviour in?

cblack: Eh? What application do you see this behaviour in?
ngrahamUnsubmitted
Done

All of them with anything besides a titlebar in their Tools area: Dolphin, Gwenview, Okular, Kate, Konsole...

ngraham: All of them with anything besides a titlebar in their Tools area: Dolphin, Gwenview, Okular…
ngrahamUnsubmitted
Done

ngraham: {F8168127}
cblackAuthorUnsubmitted
Done

That's odd—the margin shouldn't be shifting based off of window status. Will investigate.

cblack: That's odd—the margin shouldn't be shifting based off of window status. Will investigate.
cblackAuthorUnsubmitted
Done

I believe this is due to how it determines "should draw tools area" conflicting with your colourscheme.
When active, the window and the titlebar colours are different, thus causing the tools are to be drawn. When inactive, the window and the titlebar colours are the same, causing the tools area to not be drawn.

cblack: I believe this is due to how it determines "should draw tools area" conflicting with your…
hpereiradacostaUnsubmitted
Done

That's still needs fixing though. You cannot have things floating around depending on which color scheme is used. right ?
There are many color schemes of all types in the wild. The widget style must work for all.

hpereiradacosta: That's still needs fixing though. You cannot have things floating around depending on which…
cblackAuthorUnsubmitted
Done

This is intentional—if a window's titlebar and content colours are the same, the window is drawn as a homogeneous window instead of a window with a tools area.

cblack: This is intentional—if a window's titlebar and content colours are the same, the window is…
hpereiradacostaUnsubmitted
Done

I was not refering to the rendering of the separator, but rather to the fact that the widgets margin change between active and inactive. This should not happen (disregarding the color scheme).
All in all, whether you need to draw the separator or not you need to add the margin always (or follow David's suggestion)
Unless I misunderstood the actual issue reported by Nathan of course.

hpereiradacosta: I was not refering to the rendering of the separator, but rather to the fact that the widgets…
davidreUnsubmitted
Done

Maybe the decision whether to do this could only be made based on the colors of the active state so it's consistent with the inactive one.
Also this happens because the separator line? Do we actually need it? Currently there is no separator between titlebar and window and/or between toolbar and other window content?

davidre: Maybe the decision whether to do this could only be made based on the colors of the active…
hpereiradacostaUnsubmitted
Done

the this-> here are all unnecessary.

hpereiradacosta: the this-> here are all unnecessary.
hpereiradacostaUnsubmitted
Done

you should also remove the widget from widgetsWithPaletteForToolsAreaSet

hpereiradacosta: you should also remove the widget from widgetsWithPaletteForToolsAreaSet
hpereiradacostaUnsubmitted
Done

more unnecessary "this->"
Please try to remove them all.

hpereiradacosta: more unnecessary "this->" Please try to remove them all.
hpereiradacostaUnsubmitted
Done

Unused

hpereiradacosta: Unused
hpereiradacostaUnsubmitted
Done

Did you check that this chunk of code (changing the contents margins of the QMainWindow) has any effect ? I had my doubt so I changed the margin to 100 instead of 1, added a printout to make sure that this line of code is called, then ran dolphin and
1/ the code is indeed called
2/ it changes nothing, on dolphin, okular, ...
if you can confirm, then just drop it.

(in fact, I don't understand the login in the first place: why would you need to add one pixel on top of everything in the QMainWindow ?)

hpereiradacosta: Did you check that this chunk of code (changing the contents margins of the QMainWindow) has…
cblackAuthorUnsubmitted
Done

This only triggers when the window has no items in the tools area—it's used in conjunction with line 878 of breezestyle.cpp in order to render a border at the top of the window.

cblack: This only triggers when the window has no items in the tools area—it's used in conjunction with…
hpereiradacostaUnsubmitted
Done

Clear enough ! Sorry for the noise ! (and not having read the code with enough attention).

hpereiradacosta: Clear enough ! Sorry for the noise ! (and not having read the code with enough attention).
ndavisUnsubmitted
Not Done

When I run GDB on oxygen-demo5, sometimes it tells me that oxygen-demo5 crashes on this line. I'm not sure how to make it happen reliably, but it usually involves changing QStyles with the Style combobox or color schemes with the Color Scheme combobox.

ndavis: When I run GDB on `oxygen-demo5`, sometimes it tells me that `oxygen-demo5` crashes on this…
ndavisUnsubmitted
Not Done

Now I can consistently get oxygen-demo5 to crash on this line by switching to Fusion and then Oxygen.

ndavis: Now I can consistently get oxygen-demo5 to crash on this line by switching to Fusion and then…
ndavisUnsubmitted
Not Done

I misclicked. It's this line with _helper->_invalidateCachedRects = true;

ndavis: I misclicked. It's this line with `_helper->_invalidateCachedRects = true;`