Summary: | Window positioning unstable | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Fonkle <fonkle> |
Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | kde |
Priority: | NOR | ||
Version: | 5.18.5 | ||
Target Milestone: | --- | ||
Platform: | Kubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
xprop output for the Krita Manage Resources dialog: wrong placement
xprop output for the Krita Manage Resources dialog: ok placement |
Description
Fonkle
2020-06-18 14:03:30 UTC
But still within the screen correctly? Sort of the same behaviour if you were to open a new app?
>Positioning inside both QWidget::exec() and QWidget::open() both seem to be affected.
That's spoken like a dev, is the transient parent set?
Before I recompile all of krita, can I have the output of xprop and clicking on the newly popped out window.
Created attachment 129498 [details]
xprop output for the Krita Manage Resources dialog: wrong placement
Created attachment 129499 [details]
xprop output for the Krita Manage Resources dialog: ok placement
I have attached the output for both a good and bad positioned Manage Resources dialog in Krita. The only property that is different is the 'user specified location'. I have filed this bug with Krita before (https://bugs.kde.org/show_bug.cgi?id=423097) and suggested its devs to fix it by explicitly specifying the position when exec-ing the dialog. That however turned out to be not-done in Krita, since it leaves positioning to the window manager. Strangely, the other dialogs in Krita work as intended. Setting the parent of the dialog to the current MainWindow was committed in the krita/4.3 branch on 2020-06-07: https://invent.kde.org/graphics/krita/-/commit/09cd150ba44bd8d81eb4a499349730b682b38524) But that didn't fix the issue. Can't reproduce it with krita 4.4.4. If the issue is still present for you, please report it to krita developers. krita should not place the dialog itself. It should just set the transient parent information and let the window manager place the dialog. Bug seems to have been resolved (for a while?). Resolved in <= 5.1.5. Great! |