Can you explain what "Pulling a window to the current workspace is no longer possible" means? I don't have this usage mode so I'm not familiar with how it used to work.

(In reply to Nate Graham from comment #1)
> Can you explain what "Pulling a window to the current workspace is no longer
> possible" means? I don't have this usage mode so I'm not familiar with how
> it used to work.

Sure, so on the old effect you could bind actions to mouse buttons, activate (obvious), close (obvious) and at least pull to current desktop, maybe others, but these are the ones I used. 

What pull to current desktop does: Say you have 6 virtual desktops, and you are currently on desktop 1, and start the effect: with that mouse button you could pull windows from desktops 2-6 to desktop 1, which is very handy and efficient to manage multiple windows at once, e.g. if you want to pull a code editor and a browser with documentation quickly to the same virtual desktop

A very crude way to get that behaviour again would be to modify the main.qml of windowview to 

            onWindowClicked: {
                if (eventPoint.event.button == Qt.MiddleButton) {
                    window.closeWindow();
                }
                else if (eventPoint.event.button == Qt.RightButton) {
                    window.desktop = KWinComponents.Workspace.currentDesktop;
                }
                else {
                   return;
                }
            }


but imho this should be configurable, as in: users can configure what the left, right and middle button do, possibilities being activate, pull, close, nothing. Plus probably there should be some checks, e.g. I have no idea how currentDesktop behaves in some edge cases / on Wayland, and https://develop.kde.org/docs/extend/plasma/kwin/api/#read-write-properties  is a bit bare. But if you want to see what the functionality would do: the above will do just that.

Thanks, that's helpful. Confirmed. Marking as a bug rather than a wishlist item since the intention was to preserve feature parity with the QML port.

Given that re-adding this feature would require adding new UI and new strings, I'm afraid it'll have to be merged for 5.26 rather than a 5.25 bugfix release.

(In reply to Nate Graham from comment #4)
> Thanks, that's helpful. Confirmed. Marking as a bug rather than a wishlist
> item since the intention was to preserve feature parity with the QML port.
> 
> Given that re-adding this feature would require adding new UI and new
> strings, I'm afraid it'll have to be merged for 5.26 rather than a 5.25
> bugfix release.

That's sad but was somewhat to be expected, I'll have to live with local patches for a good while anyway, since it's not the only thing missing. And thanks to it being QML, people affected can patch it locally with their preferred actions hardcoded, example see above. 

Wrt UI: for the sake of consistency and (half of the) strings: icon only task manager has a UI for exactly this (middle click entries). 
I suggest just using that for each mouse button. I think configuring the plasma desktop -> mouse also has one of these, but that's very flexible (you can add and remove mouse buttons), not sure if we want to go that whole mile, but if so: that would be a good template for it.

Fuchs

This was a pretty obscure feature, assigning random actions to buttons (that one, moving a window to whatever the current desktop was, doesn't seem particularly intuitive) while a drag and drop is not much longer to perform than that.

This is something we want to remove in general (mouse button x on the window thumbnail doing an action which is not activating the window)

to have more immediate features like that, we need some good design analysis beforehand, for now moving as feature request, should be discussed with VDG for further action

(In reply to Marco Martin from comment #6)
> This was a pretty obscure feature, assigning random actions to buttons (that
> one, moving a window to whatever the current desktop was, doesn't seem
> particularly intuitive) while a drag and drop is not much longer to perform
> than that.

They were not exactly random since there was a GUI to configure them and I think it wasn't enabled by default. 
Thus also not proposing to bind it to a fix mouse button, but rather offer the very same configuration GUI we offer for mouse actions on the desktop, which would be consistent and then people would know what buttons do  (including close, which, compared to pull, is a destructive and in many cases not undoable action). 

Drag and drop simply doesn't work because the effect is also used for selecting one window out of many (e.g. when you click on a grouped task in the taskbar) and for the present window effect, where you do not have the virtual desktops shown and so you can't drag and drop. 

A decent usecase to demonstrate is: you have n  (where n >= 2) windows of the same app open, say, konsole, and you open present windows by clicking on the taskbar entry. With that mouse button you could quickly pull all of these windows to your current virtual desktop.

> to have more immediate features like that, we need some good design analysis
> beforehand, for now moving as feature request, should be discussed with VDG
> for further action

I did discuss this in the VDG group as well, as far as memory serves if configurable consistently as other places where we allow custom mouse actions (e.g. the desktop) this would be fine. This would also solve the issue of currently having a (needed, don't get me wrong, it's a good feature) destructive action on one of the mouse buttons with no visual clue to the user that this will happen.