Bug 503654

Summary:	Jarring UX with dialogs in Plasma Mobile's docked mode
Product:	[Plasma] kwin	Reporter:	Sebastian Kügler <sebas>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	REPORTED ---
Severity:	normal	CC:	bshah, espidev, nate
Priority:	NOR
Version First Reported In:	git master
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	A popup in Dolphin illustrating the problem

Description Sebastian Kügler 2025-05-02 09:49:45 UTC

SUMMARY
Dialogs (QDialog-based, I guess, but likely pertains more to window type) open fullscreen in non-docked Plasma Mobile leading to a jarring user experience.


STEPS TO REPRODUCE
1. Run dolpin in Plasma Mobile 
2. Trigger any confirmation dialog
 

OBSERVED RESULT
Observe dialog opening fullscreen. Technically logical behavior since we instruct kwin to make windows fullscreen without windeco. From a UX POV, this is jarring:
- dialogs are designed for a specific, smaller size
- in kirigami apps, dialogs are most of the time layers within a window, which doesn't involve kwin, and has them centered on the screen in a size much smaller than the screen. To the user, this seems arbitrary and QDialog-based (or actually kwin-managed dialog windows shouldn't look any different to window-internal dialogs done in QtQuick.



EXPECTED RESULT
kwin-managed dialog windows should look similar to kirigami / QtQuick Dialogs, so not fullscreen. Perhaps an exception for these dialog windows should be made inside kwin, so that they do get a window deco?

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian Sid, everything from Qt up build from git
KDE Plasma Version: master branch, will become 6.4
KDE Frameworks Version: master
Qt Version: 6.8.3

ADDITIONAL INFORMATION

Comment 1 Sebastian Kügler 2025-07-22 13:42:15 UTC

Created attachment 183425 [details]
A popup in Dolphin illustrating the problem

Here's an example, Dolphin's "confirm emptying trash" dialog. The same behaviour happens with the "new folder" dialog (which asks for the folder name to create.

Comment 2 Sebastian Kügler 2025-07-24 08:17:18 UTC

I've discussed this with various people from both Plasma Mobile and kwin teams, here's the strategy we devised along with some background information:

The general consensus is that these dialogs should not be maximized and that their sizing and placement should be similar to the sizing and placement of Kirigami (inline) dialogs. To the user, their difference it purely technical and doesn't matter.

Window placement is done using the following option in kwinrc (especially the Placement = Maximizing is responsible for the jarring behaviour we want to fix):
```
[Windows]
BorderlessMaximizedWindows = true
Placement = Maximizing
```
This is rather a sledge hammer method. Plasma Mobile would be better of handing over the sizing policy to a kwin script that does exactly what is suitable for this platform.

The dialogs we want to tackle are model QDialogs. On the Qt client API side, these are set to QDialog::setModal(true), which on the wayland platform translates to the request xdg_dialog_v1::set_modal ( https://wayland.app/protocols/xdg-dialog-v1#xdg_dialog_v1:request:set_modal ). This was implemented in Plasma 6.1 and Qt 6.8 (see https://blog.david-redondo.de/kde/wayland/qt/2024/04/04/xdg-dialog.html  https://invent.kde.org/plasma/kwin/-/merge_requests/4244  https://codereview.qt-project.org/c/qt/qtwayland/+/490397 )

A script similar to the effect dimming modal dialog's parent windows can then check for modality and special case as needed.