Bug 455350

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

+1 on this issue. Also on Arch

+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

+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.

*** Bug 455539 has been marked as a duplicate of this bug. ***

Report: In KDE Plasma 5.25.1 release works fine for me.

@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

Created attachment 150146 [details]
Example of using desktop grid without present windows in 5.24.4

(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.

(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.

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)

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)

> 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.

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!

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.

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?

I, personally, consider this a regression. So please re-introduce the old behaviour.

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.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2938

Changing back to "confirmed" as of
> wrong bug number
https://invent.kde.org/plasma/kwin/-/merge_requests/2938#note_523348

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

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.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3168

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

In can confirm the old behaviour has been restored as Windows Layout "None" in plasma 5.27.
Thx!

(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.

Also, navigating using the arrow keys suddenly navigates through both deskops and apps on a deskop (was: only desktops).