Bug 455350 - Regression in 5.25: present windows can't be deactivated for desktop grid
Summary: Regression in 5.25: present windows can't be deactivated for desktop grid
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-desktop-grid (show other bugs)
Version: 5.25.0
Platform: Other Linux
: VHI normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
: 455539 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-06-15 17:49 UTC by Christian (Fuchs)
Modified: 2023-02-20 16:25 UTC (History)
14 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.27
Sentry Crash Report:


Attachments
Example of using desktop grid without present windows in 5.24.4 (915.76 KB, image/png)
2022-06-25 13:59 UTC, hqurve
Details
Impacticality of present windows with many windows open (663.63 KB, image/png)
2022-07-15 00:15 UTC, hqurve
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian (Fuchs) 2022-06-15 17:49:38 UTC
SUMMARY

As per https://bugs.kde.org/show_bug.cgi?id=455338

there is no way to deactivate the present windows effect in the desktop grid effect. Therefore it is not possible to arrange windows using that effect. You can pull them on a different desktop, but positioning them is very hard.

STEPS TO REPRODUCE
1.  Update to 5.25
2.  Start Desktop Grid Effect
3.  Try to arrange windows

OBSERVED RESULT
Can't, because present desktop effect is active which places them randomly 

EXPECTED RESULT
Can
Comment 1 Jesus 2022-06-16 22:03:53 UTC
It happens to me too, it is not possible to change a single window to another virtual desktop, it is only possible to move them all, although when you pass the mouse over one a blue border appears, but when you drag they all move.

Plasma 5.25 and Arch linux
Comment 2 Dashon 2022-06-16 22:12:09 UTC
+1 on this issue. Also on Arch
Comment 3 Michał Zając 2022-06-20 15:37:12 UTC
+1

I have two monitors and I dragged a window from screen 1 desktop 1 to screen 1 desktop 3 which resulted in KDE taking all windows from screen 2 desktop 1 to go to screen 2 desktop 3 as well.

Video: https://www.file.io/vWkF/download/sZU8lfl7GB8K
Comment 4 Muhamed H. Asadi 2022-06-20 21:02:48 UTC
+1
I have the same issue on Arch Linux after upgrading to 5.25.
I can't move a window to other virtual desktop using desktop grid and drag-and-drop. They all move to other virtual desktop which is an unwanted behavior.
Comment 5 Nate Graham 2022-06-21 17:18:02 UTC
*** Bug 455539 has been marked as a duplicate of this bug. ***
Comment 6 Muhamed H. Asadi 2022-06-23 16:44:31 UTC
Report: In KDE Plasma 5.25.1 release works fine for me.
Comment 7 hqurve 2022-06-25 13:56:16 UTC
@Jesus, @Michał Zając and @Muhamed H. Asadi, I believe the bug you are referring to is https://bugs.kde.org/show_bug.cgi?id=455268. This bug refers to how desktop grid is shown. Previously, it was possible to have the desktop grid effect not use the present windows effect. That is, when you open the desktop grid, the virtual desktops appear as scaled versions of each virtual desktop with the position of windows untouched (possibly overlapping and so forth). This is no longer possible with 5.25
Comment 8 hqurve 2022-06-25 13:59:42 UTC
Created attachment 150146 [details]
Example of using desktop grid without present windows in 5.24.4
Comment 9 Christian (Fuchs) 2022-06-25 15:21:43 UTC
(In reply to hqurve from comment #7)
> @Jesus, @Michał Zając and @Muhamed H. Asadi, I believe the bug you are
> referring to is https://bugs.kde.org/show_bug.cgi?id=455268. This bug refers
> to how desktop grid is shown. Previously, it was possible to have the
> desktop grid effect not use the present windows effect. That is, when you
> open the desktop grid, the virtual desktops appear as scaled versions of
> each virtual desktop with the position of windows untouched (possibly
> overlapping and so forth). This is no longer possible with 5.25

correct.
Comment 10 Vlad Zahorodnii 2022-07-14 14:09:22 UTC
(In reply to Jesus from comment #1)
> It happens to me too, it is not possible to change a single window to
> another virtual desktop, it is only possible to move them all, although when
> you pass the mouse over one a blue border appears, but when you drag they
> all move.
> 
> Plasma 5.25 and Arch linux

This should be already fixed.

---

> there is no way to deactivate the present windows effect in the desktop grid effect. Therefore it is not possible to arrange windows using that effect. You can pull them on a different desktop, but positioning them is very hard.

Can you elaborate on this? I don't fully understand why you want to disable present windows layout.
Comment 11 hqurve 2022-07-15 00:13:44 UTC
Not OP, but disabling the present windows is very useful when there are many open windows per desktop. For example, say I want to move a window to another desktop. Without present windows, it is much easier to select the window as I know exactly where it would be and it is easily accessible. However, with present windows enabled, I need to first search for the window and then attempt to grab it. See screenshot 2 of what desktop grid currently looks like with my open windows (I have many pdfs open)
Comment 12 hqurve 2022-07-15 00:15:32 UTC
Created attachment 150635 [details]
Impacticality of present windows with many windows open

See comment 11 (didn't realize I could have added a comment here)
Comment 13 Christian (Fuchs) 2022-07-15 09:57:34 UTC
> Can you elaborate on this? I don't fully understand why you want to disable
> present windows layout.

Sorry for brevity, on short holiday: 

as others wrote, the idea is indeed to manage windows when you have a lot of them, similar how you would when using the pager applet, but decently sized and with a live preview. You obviously can't drag windows to the position you want them to while present windows is active, since their position and size does then not represent their actual position and size, you can only place them on different workspaces.

This was possible with the desktop grid pre 5.25 and now no longer is, as present windows is forced to be activated. This is therefore a regression and breaks the usecase of "ordering" windows.
Comment 14 Bug Janitor Service 2022-07-30 04:35:43 UTC
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
mark the bug 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!
Comment 15 Jedd 2022-08-02 09:40:44 UTC
In addition to making relocation of windows between virtual desktops harder, the change means that the Desktop Grid feature is much slower on machines with many virtual desktops, and many applications open on each.

I'm working with 6 virtual desktops and 16-20 windows on each of those.

Rendering time with previous (effectively a bitmap of each desktop's layout in miniature) was fast.  However, with the forced change for Present Windows to be only 'Natural' or 'Closest' (rather than 'None') it's a much more sluggish action to show the Desktop Grid.
Comment 16 ratijas 2022-08-19 11:05:52 UTC
I wonder, would introducing of search/filter text field solve the issue, or should we re-introduce a configuration option to disable the so-called "present windows" layout in desktop grid effect?
Comment 17 Martin van Es 2022-08-19 11:13:36 UTC
I, personally, consider this a regression. So please re-introduce the old behaviour.
Comment 18 ratijas 2022-08-19 11:21:53 UTC
With all the time and effort developers put into this new QML rewrite, I don't think it would be just reverted to previous status quo by default. However, having it as an option is plausible.

I believe that there is no "one size fits all" solution, and what looks cool and feels usable for small number of virtual desktops may become a clutter for numerous desktops and countless windows.
Comment 19 Bug Janitor Service 2022-09-13 13:43:10 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2938
Comment 20 postix 2022-09-13 14:45:21 UTC
Changing back to "confirmed" as of
> wrong bug number
https://invent.kde.org/plasma/kwin/-/merge_requests/2938#note_523348
Comment 21 David Edmundson 2022-09-15 08:42:37 UTC
From a technical POV, the best implementation will be doing this as a  new "Windows Layout" mode in WindowHeap. It'll be self-encapsulated and without needing to change the QML which already proxies along the mode.

In terms of the code, it should be just window->naturalWidth scaled to the window heap size. Hopefully
Comment 22 ratijas 2022-09-16 11:21:24 UTC
I gave it a thought, and here are my conclusions:

> From a technical POV, the best implementation will be doing this as a  new "Windows Layout" mode in WindowHeap. It'll be self-encapsulated and without needing to change the QML which already proxies along the mode.

If you mean by that extending ExpoLayout, then it would be the cheapest option in terms of CPU calculations.

However, that's not everything to it. I bet in in this mode we don't want any icons or labels or highlight on hover: it should just show the desktops as they are — just scaled down.

I believe this is doable by slightly modifying WindowHeapDelegate: one new state "active-unorganized", one new property `targetActiveState` that gets its initial value from effect's settings, a bunch of edits for `visible:` bindings, and to account for x/y in drag&drop.
Comment 23 Bug Janitor Service 2022-11-04 11:18:32 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3168
Comment 24 Marco Martin 2022-11-04 12:37:13 UTC
Git commit a8d0d7f8a561a3342ede29e3c67832534606df66 by Marco Martin.
Committed on 04/11/2022 at 11:15.
Pushed by mart into branch 'master'.

Option for WindowHeap to not alter the layout

Bring back the DesktopGrid option to not alter window position
so that the grid look like perfect screenshots of each desktop

M  +5    -0    src/effects/desktopgrid/desktopgrid_config.ui
M  +13   -0    src/effects/private/expolayout.cpp
M  +2    -0    src/effects/private/expolayout.h

https://invent.kde.org/plasma/kwin/commit/a8d0d7f8a561a3342ede29e3c67832534606df66
Comment 25 Martin van Es 2023-02-20 14:11:38 UTC
In can confirm the old behaviour has been restored as Windows Layout "None" in plasma 5.27.
Thx!
Comment 26 Christian (Fuchs) 2023-02-20 15:24:18 UTC
(In reply to Martin van Es from comment #25)
> In can confirm the old behaviour has been restored as Windows Layout "None"
> in plasma 5.27.
> Thx!

Almost, the layout is indeed as it was before and works nicely, unfortunately dragging around windows to change their position (not their workspace) doesn't work, as they "snap back" into a certain position.
Comment 27 Martin van Es 2023-02-20 16:25:04 UTC
Also, navigating using the arrow keys suddenly navigates through both deskops and apps on a deskop (was: only desktops).