Wrong _NET_WM_WINDOW_TYPE(ATOM) at dialogs. IS: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL Should be: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG Tiling window managers works wrong (tiling, not making float) with these dialogs, cause their wrong _NET_WM_WINDOW_TYPE(ATOM). Reproducible: Always Steps to Reproduce: 1. Start coping (moving, extracting) of big folder or file, to see the dialogue. 2. Use xprop at dialogue, watch the output. 3. If you are using any tiling wm, watch the tiled dialogue even if your wm set to make dialog floating. Actual Results: Tiling window managers works wrong (tiling, not making floating) with dolphin`s dialogs. Expected Results: Floating dialogs in tiling wm`s.
I`ve got some advises at unixforum.org (popular russian site about for nix-like systems users): 1. To change not type, but role, like 'roster' in im`s. Dolphin`s windows have no role now. 2. To make titles looking like «coping» but not like «coping (7MiB of 12GiB)» or «coping 12%».
Which dialogs? And is this still an issue in KDE Frameworks 5.45?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
This is still a valid bug in Framework 5.72 Missing correct _NET_WM_WINDOW_TYPE on different plasma items. What makes it worse is that everything related to plasma has same WM_CLASS "plasmashell" and _NET_WM_NAME "Plasma". Thus making different elements indistinguishable.
I still don't know which dialog you are referring to. Can you include a screenshot
Created attachment 130479 [details] plasma panel xproping on panel
Sorry last reply was sent by mistake. By dialogs I mean the dropdowns that are open when clicking on some elements in plasma. For example Status and Notifications widget. This widget TYPE is identified as _KDE_NET_WM_WINDOW_TYPE_OVERRIDE As far as I can see from the code this is `indicates a toplevel menu (AKA macmenu)...`. And this creates multiple problems: 1. Using anything but KWin (awesomeWM for example) is buggy because one can't make rules to properly place this "menus" on the screen. Plasma without KWin failing to do it by itself most of the time. 2. this "dialogs" are also the widget selector sidebar for example. It is TYPE'd as "DOCK" hence it acting as "DOCK" and not allowing focus thus effectively not allowing input which denies using of the search bar. This problem is with any "dropdown" or "dialog" that plasma is using. It's either TYPE'd incorrectly or have custom TYPE which provides nothing outside of kframeworks
Created attachment 130483 [details] "Dialog" or "Dropdown" in question This is the "dialog" in question As you can see it also not placed properly
Info was my provided
It appears that the original report and the comment from 4k1r4.rulez may be about different bugs. For the original bug, I tried copying a folder to see a dialog, and looked at its atoms with xprop. The dialog has `_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_NORMAL`, which seems fine. For 4k1r4.rulez's bug, I looked at the system tray's popup with xprop. The system tray has `_NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_APPLET_POPUP`, which I don't necessarily see an issue with. It's not a standard dialog, nor is it a normal window, it's a shell popup. Since the original bug report seems to be about actual dialog windows, I'm marking this as fixed.