[kstyle] Tools area
ClosedPublic

Authored by cblack on Feb 26 2020, 2:02 AM.

Details

Summary

There is now a tools area.

Test Plan

(no border drawn when titlebar and content colours are the same)

Diff Detail

Repository
R31 Breeze
Branch
cblack/toolsarea
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 22945
Build 22963: arc lint + arc unit
There are a very large number of changes, so older changes are hidden. Show Older Changes

I've discovered another bug. When you move a window by dragging on an empty area, all hover effects stop working.

This bug has been here since forever and is not related to the changes in this patch.
It is due to X11 eating one of Qt's mouse release events when starting to drag the window from empty areas.
It was fixed at some point in the distant past, and the re-introduced ...

cblack updated this revision to Diff 78813.Mar 29 2020, 9:54 PM

Rerender toolbar when invalidating cached rects

Nice, that seems to have fixed the issue again.

However I still see a significant performance regression though. Switching tabs in Kate is now quite slow, especially when there are many open and you use a keyboard shortcut to do so. I see the spinning busy cursor all the time. The Tools area also changes its vertical height a bit when changing tabs, which is odd.

Found an issue in Virtualbox: the menubar isn't considered a part of the Tools Area:

Also should we implement this for GTK apps?

Also should we implement this for GTK apps?

Pretty much already there :P

But yes, I'm already investigating how to apply this to menubar+toolbar'd GTK apps.

cblack updated this revision to Diff 78928.Mar 30 2020, 8:08 PM

Change how cache invalidation works

Nice, that seems to have fixed the issue again.

However I still see a significant performance regression though. Switching tabs in Kate is now quite slow, especially when there are many open and you use a keyboard shortcut to do so. I see the spinning busy cursor all the time. The Tools area also changes its vertical height a bit when changing tabs, which is odd.

Any performance regressions when a kate widget is involved (Kate, KDevelop) is likely to due to the fact that tab switching results in a spam of repainting because of incessant toggling of a toolbar's visible property, which results in costly repainting for no reason. I've already optimized what I can from the QStyle side, and anything further will have to be fixed in the offending widget.

Found an issue in Virtualbox: the menubar isn't considered a part of the Tools Area:

I'm going to WONTFIX on this one-VirtualBox is simply a massive PITA with theming, and already breaks badly in many cases with many themes, including "official" ones provided by Qt. Frankly, it's a miracle that this doesn't result in titlebar color on titlebar color.

Hi
I don't think it is very satisfactory to say that the perforrmance hit it is "the apps fault" ... It is not there without the change, and with other widgets styles (or is it ? Did any one check, e.g. oxygen which is quite resource heavy because of gradients and so ?)
You can't expect applcations dev to go optimize their app for the need of a given style. especially if it is not trivial.
I don't see another choice, if such popular apps as kate and kdevelop are affected, than to go do the optimization 'ourself', if indeed this is the issue.
At the minimum someone should try to profile this, using e.g. callgrind, to see where the curlprit is ...

Hi, I made a comparison video performing the same task with oxygen, current breeze, this patch with the option enabled and disabled (in order of appearance). The task is opening kdevelop, opening the same two files, switching between them and then closing the files and the application. As you can see the startup time is much worse and even the disabled option seems to have some impact.


Saying this is the fault of applications is imo unacceptable as it worked fine before and in other styles and is caused directly by this. In my mind the style should not have such a big impact on performance .

cblack updated this revision to Diff 79006.Mar 31 2020, 6:36 PM

More optimization

cblack updated this revision to Diff 79010.Mar 31 2020, 7:49 PM

More optimization

Thanks, that helps a lot. It still feels a little bit slower than before, but it's at least much improved.

gikari awarded a token.Apr 1 2020, 4:39 PM

While working on D28317, I noticed something: when a window becomes inactive, the icons change their colors, but only for the parts of the icon using the text color. Red icons, or parts of icons that are red, don't change at all which is a little weird-looking:

Do we need an inactive red color or something?

Anyway I worked around that in D27669, and I guess it's not really a huge deal for toolbar icons.

One thing I notice is that the bottom separator line for the titlebar isn't drawn for 3rd-party apps where there is no Tools Area. Maybe to do this, we could have the decoration theme draw the line by default unless specifically told not to by the widget theme, and then the widget theme could tell it not to because it will be drawing the separator underneath the menubar or toolbar (as appropriate).

Thoughts?

ndavis added a comment.Apr 1 2020, 9:55 PM

While working on D28317, I noticed something: when a window becomes inactive, the icons change their colors, but only for the parts of the icon using the text color. Red icons, or parts of icons that are red, don't change at all which is a little weird-looking:

Perhaps we shouldn't change the text color on inactive windows? We can already change the background color. It would only require changes to the default color schemes.

Do we need an inactive red color or something?

It should be possible to make an inactive version of NegativeText based on the inactive color.

Lightening the stuff on the Tools Area is a nice effect though, IMO. Implementation-wise, we could also use the Fade inactive window effect in the color scheme itself for this. However it's a bit buggy as various apps have widgets that don't respect it (I've filed bug reports and can dig them up if needed) and it affects more than just the tools area. Still, that might be the more technically correct way to lighten things for inactive windows.

Anyway I worked around that in D27669, and I guess it's not really a huge deal for toolbar icons.

One thing I notice is that the bottom separator line for the titlebar isn't drawn for 3rd-party apps where there is no Tools Area. Maybe to do this, we could have the decoration theme draw the line by default unless specifically told not to by the widget theme, and then the widget theme could tell it not to because it will be drawing the separator underneath the menubar or toolbar (as appropriate).

Thoughts?

Apps liiike? The QStyle should draw a decoration line regardless of the presence of a toolbar/menubar area.

Anyway I worked around that in D27669, and I guess it's not really a huge deal for toolbar icons.

One thing I notice is that the bottom separator line for the titlebar isn't drawn for 3rd-party apps where there is no Tools Area. Maybe to do this, we could have the decoration theme draw the line by default unless specifically told not to by the widget theme, and then the widget theme could tell it not to because it will be drawing the separator underneath the menubar or toolbar (as appropriate).

Thoughts?

Apps liiike? The QStyle should draw a decoration line regardless of the presence of a toolbar/menubar area.

Like every 3rd-party app not using Qt or GTK. ...Which are principally Electron apps these days, I guess. But there are a handful of important apps not using Qt, GTK, or Electron, such as Blender. I've got a few others installed like ChiTuBox and SpiderOak One. Also Telegram, which is a Qt app, doesn't get a line below its titlebar.

My idea to have the decoration theme draw the separarator line unless explicitly told not to because the QStyle or breeze-GTK theme is drawing it itself is intended to avoid having to play whack-a-mole with all the different 3rd-party apps out there.

cblack added a comment.Apr 4 2020, 4:16 PM

Anyway I worked around that in D27669, and I guess it's not really a huge deal for toolbar icons.

One thing I notice is that the bottom separator line for the titlebar isn't drawn for 3rd-party apps where there is no Tools Area. Maybe to do this, we could have the decoration theme draw the line by default unless specifically told not to by the widget theme, and then the widget theme could tell it not to because it will be drawing the separator underneath the menubar or toolbar (as appropriate).

Thoughts?

Apps liiike? The QStyle should draw a decoration line regardless of the presence of a toolbar/menubar area.

Like every 3rd-party app not using Qt or GTK. ...Which are principally Electron apps these days, I guess. But there are a handful of important apps not using Qt, GTK, or Electron, such as Blender. I've got a few others installed like ChiTuBox and SpiderOak One. Also Telegram, which is a Qt app, doesn't get a line below its titlebar.

My idea to have the decoration theme draw the separarator line unless explicitly told not to because the QStyle or breeze-GTK theme is drawing it itself is intended to avoid having to play whack-a-mole with all the different 3rd-party apps out there.

I don't really consider it important to attempt to bring the Tools Area to third-party apps with their own strong branding

If we're going to consider the titlebar a part of the tools area, then it needs a separator line underneath it whether it's drawn on a Blender window or a Plasma config window The idea was always to draw a separator line under the bottom-most element of the Tools Area in all apps, whether that bottom-most element was a menubar, toolbar, or the SSD titlebar drawn by KWin.

ngraham accepted this revision.Apr 15 2020, 6:26 PM

This is probably fine as-is, and we can fine-tune it later if need be.

We should wait to land it until the companion patches for Breeze GTK (https://invent.kde.org/kde/breeze-gtk/-/merge_requests/2), Kirigami (TBD) and QQC2-desktop style (TBD) have also landed.

Needs a rebase

ngraham requested changes to this revision.Apr 19 2020, 7:42 PM

Found an interesting issue today: When you hide and show the menubar in Dolphin, this happens:

. It goes away if you interact with anything in the toolbar.

Can reproduce in Kate too, and it goes away after interacting with the toolbar or switching tabs. Cannot reproduce in Konsole.

This revision now requires changes to proceed.Apr 19 2020, 7:42 PM
cblack updated this revision to Diff 80594.Apr 19 2020, 10:39 PM

Rebase on master

cblack updated this revision to Diff 80597.Apr 19 2020, 10:46 PM

Properly rebase

cblack updated this revision to Diff 80603.Apr 19 2020, 11:36 PM

Fix menubar quirks

ngraham accepted this revision.Apr 20 2020, 12:32 AM

Much better, thanks.

davidre added inline comments.Apr 20 2020, 6:51 AM
kstyle/breezestyle.cpp
890

Stray qdebug

ngraham requested changes to this revision.Apr 20 2020, 1:49 PM

Now all of my QtWidgets apps are crashing with a backtrace like this one:

Application: Spectacle (spectacle), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
29	  return SYSCALL_CANCEL (poll, fds, nfds, timeout);
[Current thread is 1 (Thread 0x7f4a76a76800 (LWP 22804))]

Thread 1 (Thread 0x7f4a76a76800 (LWP 22804)):
[KCrash Handler]
#6  QRasterPaintEngine::transformChanged (this=0x7f4a700076c0) at painting/qpaintengine_raster.cpp:941
#7  0x00007f4a795f4e5a in QPainterPrivate::updateMatrix (this=0x7ffdb8f85530, this@entry=0x5628c5e23790) at painting/qpainter.cpp:664
#8  0x00007f4a795f7e31 in QPainter::setWorldTransform (this=this@entry=0x7ffdb8f85660, matrix=..., combine=combine@entry=false) at painting/qpainter.cpp:8389
#9  0x00007f4a79f6c7a6 in QGraphicsDropShadowEffect::draw (this=<optimized out>, painter=0x7ffdb8f85660) at effects/qgraphicseffect.cpp:1067
#10 0x00007f4a79c09f8e in QWidgetPrivate::drawWidget (this=0x5628c5b48b60, pdev=0x5628c5cbb720, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5301
#11 0x00007f4a79c0a883 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=<optimized out>, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at ../../include/QtCore/../../src/corelib/tools/qpoint.h:124
#12 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=0, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#13 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=1, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#14 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=2, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#15 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=3, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#16 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=4, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#17 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=5, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#18 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=6, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#19 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=7, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#20 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=8, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#21 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=11, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#22 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5ae4910, pdev=0x5628c5cbb720, siblings=..., index=13, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#23 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=this@entry=0x5628c5ae4910, pdev=pdev@entry=0x5628c5cbb720, siblings=..., index=14, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#24 0x00007f4a79c0919c in QWidgetPrivate::drawWidget (this=0x5628c5ae4910, pdev=0x5628c5cbb720, rgn=..., offset=..., flags=..., sharedPainter=<optimized out>, repaintManager=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qlist.h:176
#25 0x00007f4a79c0a883 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5b786d0, pdev=0x5628c5cbb720, siblings=..., index=<optimized out>, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at ../../include/QtCore/../../src/corelib/tools/qpoint.h:124
#26 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=0x5628c5b786d0, pdev=0x5628c5cbb720, siblings=..., index=0, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#27 0x00007f4a79c0a766 in QWidgetPrivate::paintSiblingsRecursive (this=this@entry=0x5628c5b786d0, pdev=pdev@entry=0x5628c5cbb720, siblings=..., index=1, rgn=..., offset=..., flags=..., sharedPainter=0x0, repaintManager=0x5628c5c8dbb0) at kernel/qwidget.cpp:5589
#28 0x00007f4a79c0919c in QWidgetPrivate::drawWidget (this=this@entry=0x5628c5b786d0, pdev=0x5628c5cbb720, rgn=..., offset=..., flags=..., flags@entry=..., sharedPainter=sharedPainter@entry=0x0, repaintManager=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qlist.h:176
#29 0x00007f4a79be08a9 in QWidgetRepaintManager::paintAndFlush (this=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qpoint.h:122
#30 0x00007f4a79be119e in QWidgetRepaintManager::sync (this=0x5628c5c8dbb0, exposedWidget=0x5628c5b48910, exposedRegion=...) at kernel/qwidgetrepaintmanager.cpp:749
#31 0x00007f4a79c2dbb4 in QWidgetWindow::handleExposeEvent (this=<optimized out>, event=0x7ffdb8f872f0) at ../../include/QtGui/../../src/gui/kernel/qevent.h:468
#32 0x00007f4a79c2e778 in QWidgetWindow::event (event=0x7ffdb8f872f0, this=0x5628c5cbd190) at kernel/qwidgetwindow.cpp:342
#33 QWidgetWindow::event (this=0x5628c5cbd190, event=0x7ffdb8f872f0) at kernel/qwidgetwindow.cpp:238
#34 0x00007f4a79bcdcaf in QApplicationPrivate::notify_helper (this=this@entry=0x5628c5a03af0, receiver=receiver@entry=0x5628c5cbd190, e=e@entry=0x7ffdb8f872f0) at kernel/qapplication.cpp:3684
#35 0x00007f4a79bd6df0 in QApplication::notify (this=0x7ffdb8f87a90, receiver=0x5628c5cbd190, e=0x7ffdb8f872f0) at kernel/qapplication.cpp:3430
#36 0x00007f4a78f20002 in QCoreApplication::notifyInternal2 (receiver=0x5628c5cbd190, event=0x7ffdb8f872f0) at ../../include/QtCore/../../src/corelib/kernel/qobject.h:153
#37 0x00007f4a7933a83f in QGuiApplicationPrivate::processExposeEvent (e=0x5628c5c42ff0) at kernel/qguiapplication.cpp:3188
#38 0x00007f4a7933aa6b in QGuiApplicationPrivate::processWindowSystemEvent (e=e@entry=0x5628c5c42ff0) at kernel/qguiapplication.cpp:2009
#39 0x00007f4a7931453b in QWindowSystemInterface::sendWindowSystemEvents (flags=flags@entry=...) at kernel/qwindowsysteminterface.cpp:1163
#40 0x00007f4a74bc1a6a in xcbSourceDispatch (source=source@entry=0x5628c5ac7c80) at qxcbeventdispatcher.cpp:105
#41 0x00007f4a77421048 in g_main_dispatch (context=0x7f4a70005000) at ../glib/gmain.c:3216
#42 g_main_context_dispatch (context=context@entry=0x7f4a70005000) at ../glib/gmain.c:3881
#43 0x00007f4a774213d0 in g_main_context_iterate (context=context@entry=0x7f4a70005000, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3954
#44 0x00007f4a7742145f in g_main_context_iteration (context=0x7f4a70005000, may_block=may_block@entry=1) at ../glib/gmain.c:4015
#45 0x00007f4a78f76bee in QEventDispatcherGlib::processEvents (this=0x5628c5ad26f0, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#46 0x00007f4a78f1eb9b in QEventLoop::exec (this=this@entry=0x7ffdb8f875d0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:136
#47 0x00007f4a78f26972 in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:118
#48 0x00005628c5925bbb in ?? ()
#49 0x00007f4a7aa10ceb in __libc_start_main (main=0x5628c5923d90, argc=1, argv=0x7ffdb8f87da8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdb8f87d98) at ../csu/libc-start.c:308
#50 0x00005628c592631a in ?? ()
[Inferior 1 (process 22804) detached]

It only happens when I'm running with this patch.

This revision now requires changes to proceed.Apr 20 2020, 1:49 PM
cblack updated this revision to Diff 80819.Apr 21 2020, 11:44 PM

Remove stray qDebug

The crash is still happening for me. It's instantly reproducible with Spectacle. I open it and it immediately crashes.

Affected apps:

  • Spectacle: crashes as soon as it launches
  • Telegram: crashes when I click on a chat in the sidebar

Other unusual behavior noticed:

  • Opening open/save dialogs and settings windows in Dolphin and Kate causes the parent apps to hang for a few seconds. Maybe an issue with QDialogs?
mart added a subscriber: mart.Apr 23 2020, 9:01 AM

Is on the right track but I think the technical approach needs more discussion, i think something needs to be encoded into KColorScheme, like a new color group (probably independent from titlebars actually)

ndavis added a comment.EditedApr 24 2020, 5:50 AM

I'm seeing a lot of this message when I run GDB on oxygen-demo5 and I switch from a different QStyle such as Fusion back to Breeze via the Style combobox:

QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it?

I also see this sometimes:

QWidget::repaint: Recursive repaint detected
kstyle/breezetoolsareamanager.cpp
128

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.

cblack updated this revision to Diff 81123.Apr 24 2020, 5:44 PM

Address tooling warnings

ndavis added inline comments.Apr 24 2020, 7:50 PM
kstyle/breezetoolsareamanager.cpp
128

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

ndavis added inline comments.Apr 24 2020, 7:51 PM
kstyle/breezetoolsareamanager.cpp
128

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

cblack updated this revision to Diff 81133.Apr 24 2020, 8:03 PM

Disconnect signals on destruction

That fixes the crashes as well as the performance issues I was seeing. However every app with a menubar now shows a lighter-colored rectangle to the right of the menu area:

cblack updated this revision to Diff 81137.Apr 24 2020, 8:59 PM

Re-add empty drawing for menu bar

ngraham accepted this revision.Apr 25 2020, 4:04 AM
ndavis added a comment.EditedApr 26 2020, 4:45 AM

The only remaining problem I can find is this where text and icons use the inactive color with certain kinds of menu buttons. TBH, I'd be in favor of not using the inactive color effect on toolbar button text and icons. It looks odd because text and icons that aren't in the toolbar don't have the same effect. It also makes it look like the buttons are disabled which is not true.

ndavis added a comment.May 6 2020, 6:43 AM

Reposting here so that it won't be forgotten. Some windows are lacking the underline:


For some reason, the settings window for KDevelop takes roughly 4x longer to load with this patch. I'm not sure why that is and I don't see any suspicious messages that seem related to this patch in GDB.

Reposting here so that it won't be forgotten. Some windows are lacking the underline:


Can confirm this with the current state of the patch.

I think this should land early in the 5.20 cycle so we have a lot of time for testing. However I think we need to land it alongside the new colorscheme so people don't get a bad first impression, or else re-work it to pull the color from a new "toolsarea" color set that we add to KColorScheme.

cblack updated this revision to Diff 83075.May 19 2020, 10:39 PM

Properly determine if tools area should be drawn on QDialogs with auto set

Now disabled toolbar items don't use the disabled text color when disabled.

what are some ways the issue of toolbar colors not being perfectly in sync with titlebar colors could be fixed or worked around?

The line seems to stop just short of the sidebar:

cblack added a comment.Jun 9 2020, 2:11 AM

what are some ways the issue of toolbar colors not being perfectly in sync with titlebar colors could be fixed or worked around?

When animating? Wayland.

This revision was not accepted when it landed; it landed in state Needs Review.Jun 9 2020, 2:50 AM
Closed by commit R31:ea978ea6eb36: [kstyle] Tools area (authored by cblack). · Explain Why
This revision was automatically updated to reflect the committed changes.