https://bugs.kde.org/show_bug.cgi?id=381610

Paul Loock <paullo...@t-online.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |---

--- Comment #2 from Paul Loock <paullo...@t-online.de> ---
(In reply to Christoph Feck from comment #1)
> As a workaround use the breeze window decoration.
> 
> *** This bug has been marked as a duplicate of bug 361236 ***

Bug #381610 
Thank You for quick reply. I changed all my KDE-settings to breeze but it
doesn't help.
After several restarts of the system to get a clean memory cache I could nearly
reproduce the prior described window shifting after starting and closing 5 to
20 different programms, some of them starting at position 0,0. The triggering
programm for the window shift is not always the same.
Maybe window positioning is a more common problem as I learned from
QtCreator5.6-help:
----------------------------------------
<qthelp://org.qt-project.qtwidgets.562/qtwidgets/application-windows.html#x11-peculiarities>
X11-Peculiarities
On X11, a window does not have a frame until the window manager decorates it.
This happens asynchronously at some point in time after calling QWidget::show()
and the first paint event the window receives, or it does not happen at all.
Bear in mind that X11 is policy-free (others call it flexible). Thus you cannot
make any safe assumption about the decoration frame your window will get. Basic
rule: There's always one user who uses a window manager that breaks your
assumption, and who will complain to you.
Furthermore, a toolkit cannot simply place windows on the screen. All Qt can do
is to send certain hints to the window manager. The window manager, a separate
process, may either obey, ignore or misunderstand them. Due to the partially
unclear Inter-Client Communication Conventions Manual (ICCCM), window placement
is handled quite differently in existing window managers.
X11 provides no standard or easy way to get the frame geometry once the window
is decorated. Qt solves this problem with nifty heuristics and clever code that
works on a wide range of window managers that exist today. Don't be surprised
if you find one where QWidget::frameGeometry() returns wrong results though.
Nor does X11 provide a way to maximize a window. QWidget::showMaximized() has
to emulate the feature. Its result depends on the result of
QWidget::frameGeometry() and the capability of the window manager to do proper
window placement, neither of which can be guaranteed. 
----------------------------------------

Maybe there is a problem with my linuxMint installation because I left my
home-partition from my last openSuse 13.2 untouched during installation.
OpenSuse 13.2/KDE without nouveau driver and another kernel worked for a long
time without problems on the same hardware. I don't like unresolved problems.
So I will backup my system an then reinstall a linuxMint 18.1/KDE on formatted
partitions. If that would not help I will install openSuse Leap 42.2/KDE both
with the nouveau driver. Perhaps it will take some time until I can post a
result.

Paul

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to