Created attachment 85792 [details] screenshot See screenshot. Steps to reproduce 1) place a very little window like xterm at left top corner 2) now open widget explorer Extra fun 1) now close it, and move window a little 2) start widget explorer 3) Find it attached to window.
Same with activity switcher, moving to kwin.
Why does the widget explorer take part in placement? Does it not set an explicit position? I doubt there's a difference in the activity switcher and widget explorer clients.
(In reply to comment #2) > Does it not set an explicit position? It sets I think..
Well, i doubt so - try a more explicit placement strategy (eg. zero cornered)
Does eg. yakuake still show up at the correct position?
I don't have Yakuake installed.. CC'ing notmart
kwrite --geometry +20+80
Hmm, it appears at right place.
but what I noticed is windows started by plasma-shell are at not right place if another window is at 0x0 Example, 1) desktop settings 2) Widget explorer 3) Activity chooser
the default (smart) placement strategy starts searching for a free slot in the upper left corner - try a more explicit one (zero cornered, centered - kcmshell4 kwinoptions, last tab)
(In reply to comment #10) > the default (smart) placement strategy starts searching for a free slot in > the upper left corner - try a more explicit one (zero cornered, centered - > kcmshell4 kwinoptions, last tab) kcmshell4?? :O this is kwin5 and I don't have any kcmshell5.. :O
nevermind found it"
okay so setting it to "Zero-cornered" worked. now I get widget explorer at correct place. Can you explain me what was wrong with smart option?
nothing - the window gets placed and that should not happen. as placement avoiding in general (still) works (passing ang explicit geometry), this means the client does not request a position -> plasma bug, it's not in kwin by 99.9% chance.
I think I have an idea about this, I'm on it.
Erm, wrong bug, I meant to post this on bug 332850, sorry. Note that I looked into this as well, the widget explorer does not set explicit position afaics, maybe it should?
Git commit ada24e2bc7978dd23a1b6bc7b57d68967fea1cc3 by Marco Martin. Committed on 02/04/2014 at 17:36. Pushed by mart into branch 'master'. explicitly move at topLeft of availableRect Related: bug 332850 M +4 -1 desktoppackage/contents/views/Desktop.qml http://commits.kde.org/plasma-desktop/ada24e2bc7978dd23a1b6bc7b57d68967fea1cc3
Now we have the position being set from that QML and from the dialog in updateVisibility -> syncToMainItemSize -> popupPosition Having two bits of code doing things is a bit messy and will cause problems down the line.
hmm, no, it doesn't have a visualparent, so shouldn't ever do popupPosition()
It definitely used to... probably why this bug resurfaced Lets close this and reopen if this bug ever comes back.
That fixed it but only too some extent... If I restart plasma-shell and try to reproduce this with steps given I can still reproduce it but only *once*..
Still happens in today's build, follow the steps in #1 to reproduce.
periodical ping: does anybody can still reproduce? I can't anymore (followed steps of #1)
yes, still valid.
happens here too
Flags on the window have changed This /might/ have fixed it. Please reopen if you ever see this again.
*** Bug 336747 has been marked as a duplicate of this bug. ***
Steps to reproduce - 1. Open System Settings in "Windowed-mode" (not maximized) 2. While System Settings is still open open the widgets explorer. It will be opened to the right of the System Settings.
Still a problem on my system.
I /hope/ 62d240b7d652539d9fc52dd464c049d4befa8055 in plasma-framework has fixed this. I haven't seen it since.
Sadly not yet solved, if you have window at 0, 0 it will open at wrong place..
Only fix I have for it is to make a window rule, set plasmashell, dock window type, initial placement top left corner, and force keep above,
*** Bug 341881 has been marked as a duplicate of this bug. ***
*** Bug 347338 has been marked as a duplicate of this bug. ***
Steps to reproduce in plasma 5.3: 1. Reboot system 2. Open some program/window 3. Open activity switcher or widget explorer This happens only on clean boot. After popping up for the first time on wrong place (next to the opened window), next time(s) they pop up on expected place.
Seems kwin is moving it in a method called KWin::Placement::placeSmart gdb trace. #0 KWin::Client::move (this=0xf3b2b0, x=1656, y=0, force=KWin::AbstractClient::NormalGeometrySet) at /home/david/projects/kde5/src/kde/workspace/kwin/geometry.cpp:2059 #1 0x00007ffff773a9b8 in KWin::Placement::placeSmart (this=0x7c1b30, c=0xf3b2b0, area=...) at /home/david/projects/kde5/src/kde/workspace/kwin/placement.cpp:342 #2 0x00007ffff7739ad4 in KWin::Placement::place (this=0x7c1b30, c=0xf3b2b0, area=..., policy=KWin::Placement::Smart, nextPlacement=KWin::Placement::Unknown) at /home/david/projects/kde5/src/kde/workspace/kwin/placement.cpp:102 #3 0x00007ffff77398f1 in KWin::Placement::place (this=0x7c1b30, c=0xf3b2b0, area=...) at /home/david/projects/kde5/src/kde/workspace/kwin/placement.cpp:76 #4 0x00007ffff7775cf8 in KWin::Client::manage (this=0xf3b2b0, w=41943053, isMapped=false) at /home/david/projects/kde5/src/kde/workspace/kwin/manage.cpp:399 #5 0x00007ffff76e0239 in KWin::Workspace::createClient (this=0x6aaae0, w=41943053, is_mapped=false) 342 c->move(x_optimal, y_optimal); (gdb) frame 1 (gdb) print c->x() $11 = 0 (gdb) print x_optimal $12 = 1656 client position is 0 when kwin starts processing it, then it gets moved elsewhere interestingly the second time we have: #0 KWin::Client::move (this=0xf33830, x=0, y=0, force=KWin::AbstractClient::NormalGeometrySet) at /home/david/projects/kde5/src/kde/workspace/kwin/geometry.cpp:2059 #1 0x00007ffff7775499 in KWin::Client::manage (this=0xf33830, w=41943053, isMapped=false) at /home/david/projects/kde5/src/kde/workspace/kwin/manage.cpp:334 #2 0x00007ffff76e0239 in KWin::Workspace::createClient (this=0x6aaae0, w=41943053, is_mapped=false) at /home/david/projects/kde5/src/kde/workspace/kwin/workspace.cpp:485 so it's taking a different path in manage(), one that sends it through the (quetionably named) smart placement.
and the difference is... m_geometryHints.hasPosition returns false the first time.
Found it! Deep deep down in the Qt XCB backend there is a line: if (qt_window_private(window())->positionAutomatic) tell kwin the position and size else tell kwin the size positionAutomatic starts true and is set to false on any call to setGeometry(); so if you explicitly set geometry to 0,0 it will till the WM we have a position. However, setX, setY have a check before to see if it's doing a no-op, so this flag never gets unset. IMHO it's a bug in QWindow there, and I'll write a patch for Qt there. It only happens once because afterwards kwin moves the window, which ends up calling a setGeometry in QWindow. However, I think we want an early bodge. Either I set X to -1 before we show it and set it back to 0 in Desktop.qml or we put a random setGeometry call into dialog.
Git commit 544e98da26ffc6a71f9a0a8f1c38ce505cb930d1 by David Edmundson. Committed on 24/08/2015 at 10:01. Pushed by davidedmundson into branch 'Plasma/5.4'. Fix widget explorer sometimes opening on the wrong side of the screen. Work around a Qt bug. If there is no setGeometry call on QWindow the XCB backend will not pass our requested position to kwin as our window position tends to be 0, setX,setY no-ops and means we never set a position as far as QWindow is concerned by setting it to something silly and setting it back before we show the window we avoid that bug. Qt patch also filed (https://codereview.qt-project.org/123989) so hopefully this can be removed in future if that gets merged. REVIEW: 124869 M +7 -0 desktoppackage/contents/views/Desktop.qml http://commits.kde.org/plasma-desktop/544e98da26ffc6a71f9a0a8f1c38ce505cb930d1