Bug 507507 - Qt 6.10 causes Qt application windows to appear at 0,0/top-left ignoring KWin rules.
Summary: Qt 6.10 causes Qt application windows to appear at 0,0/top-left ignoring KWin...
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: general (other bugs)
Version First Reported In: 6.3.5
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://bugreports.qt.io/browse/QTBUG...
Keywords: X11-only
: 510566 (view as bug list)
Depends on:
Blocks:
 
Reported: 2025-07-26 13:03 UTC by Chiitoo
Modified: 2025-10-29 12:22 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: Qt 6.10.1
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chiitoo 2025-07-26 13:03:04 UTC
SUMMARY

After going from Qt 6.9 to 6.10 back in June 2025, I noticed that the KWin 'Window Behaviour' / 'Window placement' setting seems to be completely ignored for Qt applications, and new windows will open at 0,0, or in other words, top-left of the left-most screen on a three-screen set-up running X11.

Perhaps likely a Qt bug, or at least changed behaviour, but filing here first for visibility and such until I get to look deeper into the matter myself.

STEPS TO REPRODUCE

1. Run KWin X11 on LXQt in a three-display set-up (probably should see this on full Plasma, and single-display set-up too).
2. Set 'Window placement' to anything other than 'top-left corner'.
3. Make sure 'Allow apps to remember the psoitions of their own windows, if they support it' is disabled.
4. Run a Qt application, something like 'kcalc' for example, and observe it being placed at 0,0, or top-left corner instead of, for example, randomly or centred.

OBSERVED RESULT

New Qt application windows always appear at 0,0, or top-left corner, if they don't remember their last position.

EXPECTED RESULT

Windows are placed according to the KWin 'Window placement' setting.

SOFTWARE/OS VERSIONS

Linux/KDE Plasma: Gentoo Linux (Not a full Plasma install, but using KWin with LXQt.)
KDE Plasma Version: 6.4.3
KDE Frameworks Version: 6.16.0
Qt Version: 6.10 (838d543cd2adddce6419faa91647192653d71088)

ADDITIONAL INFORMATION

Wayland behaviour not tested at all.
Comment 1 Bug Janitor Service 2025-07-26 13:33:41 UTC
Thank you for the bug report!

However Plasma 6.3.5 no longer receives updates or maintenance from KDE; active versions are 6.4 or newer. Please upgrade to an active version as soon as your distribution makes it available to you. Plasma is a fast-moving project, and bugs in one version are often fixed in the next one.

If you need help with Plasma 6.3.5, please contact your distribution, who bears the responsibility of providing help for older releases that are no longer receiving updates from KDE.

If you can reproduce the issue after upgrading to an active version, feel free to re-open this bug report.
Comment 2 Chiitoo 2025-07-26 14:25:31 UTC
I suppose the "version first reported in" is a bit confusing to me here.

Re-opening as this is happening with a current release still.
Comment 3 Nate Graham 2025-09-23 17:49:22 UTC
Likely a Qt bug indeed. Were you ever able to report it to the Qt folks or investigate it there?
Comment 4 Chiitoo 2025-09-23 18:16:12 UTC
Unfortunately no, have not gotten to it yet.
Comment 5 Luke Horwell 2025-10-12 21:35:24 UTC
Since Qt 6.10.0 landed in the Arch Linux repositories, I have noticed my "Minimal Overlapping" window placement setting stopped working and always position themselves in the top-left corner. Can confirm this bug under X11, single HiDPI monitor user. Doesn't happen on Wayland.

Applications affected in particular: Dolphin, Konsole, KWrite, Kate, System Settings, Info Centre.  It doesn't seem to be just KDE apps, my own Qt 6 app ends up positioned at 0,0 too if the app is configured to "let the window manager decide".

My workaround is to add a window rule to "Ignore requested geometry" = "Yes" for these applications, then it's back to normal. Strangely, the dialog box for KWrite's "Close Document - Saved Changes?" prompt ends up in the top-left too, but Kate's version centers as expected.
Comment 6 StolenByte 2025-10-15 21:46:54 UTC
Confirmed as a Qt bug.

Link to related bug report over on qt.io for reference/tracking: https://bugreports.qt.io/browse/QTBUG-141099
Comment 7 Zamundaaa 2025-10-17 09:56:31 UTC
*** Bug 510566 has been marked as a duplicate of this bug. ***
Comment 8 kaminata 2025-10-17 10:36:40 UTC
Same problem here on Arch Linux. As I can understand it's up to the Qt team and not KDE?
Comment 9 TraceyC 2025-10-17 18:47:47 UTC
(In reply to kaminata from comment #8)
> Same problem here on Arch Linux. As I can understand it's up to the Qt team
> and not KDE?

Yes. You can follow https://bugreports.qt.io/browse/QTBUG-141099 if you would like to track their progress.
Comment 10 kaminata 2025-10-17 21:23:16 UTC
(In reply to TraceyC from comment #9)
> (In reply to kaminata from comment #8)
> > Same problem here on Arch Linux. As I can understand it's up to the Qt team
> > and not KDE?
> 
> Yes. You can follow https://bugreports.qt.io/browse/QTBUG-141099 if you
> would like to track their progress.

Thank you very much!