Unlock toolbar position of Kate, Dolphin, etc. change it position animation is with desktop rect. Reproducible: Always Steps to Reproduce: 1. Open Kate (Dolphin, etc KDE app) 2. Rigtht cllick on toolbar area 3. Un check 'Lock Toobar Positions' 4. Change postion of unlocked toolbar in the app panel Actual Results: Compositor animates with desktop rect Expected Results: Compositor to animate with client rect
I'm not sure what you see or expect, but the toolbar doesn't behave anything special here. The screenshot seems to show an ARGB toolbar on 0/0 a) check whether this is actually the compositor or the client => cause the problem, suspend the compositor (SHIFT+Alt+F12) Is the toolbar still where it was w/ the compositor running? b) check whether this is (induced by) the compositor at all => Suspend the compositor first, then try to cause the issue c) check whether it's related to the apparent ARGB condition of the toolbar. => Resume the compositor and run QT_STYLE_OVERRIDE=fusion kate Ensure this causes a new instance (which looks different from the other since it's now using the fusion style) and try to cause the issue.
a) issue present with compositor and not without b) no issue without compositor c) no issues with other styles that Breeze (Oxigen, Fusion, etc)
please attach the output of qdbus org.kde.KWin /KWin supportInformation (with! running compositor, ideally under the wrong condition)
Created attachment 96316 [details] kwin output
Created attachment 96317 [details] Broken toolbar One of the many funny things that can happen when moving the toolbar around alongside manipulating the orientation. The behavior is completely odd and apparently random I also saw what you saw and it expectedly remained after suspending the compositor because the toolbar kicked an extra unmanaged window there. There is NO WAY that your answer to (a) was NOT a blatant lie. You can file a bug against kxmlgui, maybe Qt, but a) it's not a bug in kwin b) I'm now seriously pissed.
How can i blame kxmlgui, when this happend in pure Qt5 apps like LibreCAD.
It'll likely be in QToolBar. I assume the widget flag update (for some reason it changes between managed and unmanaged windows and the sane ones are all managed while the insane one was not) "fails" Ultimately QWidget::hide for the unmanaged floater (it *does* show up in the 0,0 corner - but this seems to only happen with the breeze style?) will fail and you end up with a zombie window (though this is rare here, the typical result is two qwidget representations *in* the window as in my uncomposited screenshot) - the compositor should not see/render an extra window in your screenshot anymore at all (the kate window is one big opaque block from the WM/Compositor POV) There certainly is a bug, but it's not in the compositor. The client has problems to control its windows mapping states (it clearly forgets to close/hide one of the widgets) - the 2nd widget in my shot reacted "live" (ie. reflected input, also on the other widget) and your description sounds as if the zombie toplevel behaves the same?! The compositor *might* trigger this (less/slower syncs, more delay between map request and success, the redirection, something else), but that would boil down to "your system is to slow to correctly handle toolbars" and be no excuse.
It's not only on Breeze, after more tests it happens on every theme. Can you fire bug in QToolBox or compositor to stop trigger this syncs :) It's not a big bug, but when we see it, maybe it's best to resolve it :)
I knew I know this bug. About filing a bug against Qt, I frankly would not know how to do that w/o using terms like "sick", "stupid" or "insane" - the entire code is incredibly fragile and needs some overhaul - or a timer driven (...) sanity check :-( The problem will be that the toolbar changes the WId under the hood and looses connection between the X11 drawable and the QWidget. It seemed heftily related to the inited "locked" condition back then (try to drag a toolbar out, close kate and restart it), but given the present state of QWidget maintainance, I don't expect a bugfix (what probably implies a complete rewrite - it's really badly broken for a long time) https://bugreports.qt.io - feel free to try your luck.