Bug 482892

This also affects my workflow. I would very much like to see an option to turn on the old behavior. I am using two activities: Work and private. I mentally keep track of which virtual desktop I am at, but when changing activities I have to reorient myself every time since I am very likely not at the same virtual desktop that I switched from.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch KDE 6.0.2
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

ADDITIONAL INFORMATION
Using Wayland

I did some digging in the source code and it seems like there's a plugin that's responsible for this behavior, however the plugin seems to be shipped and enabled by default (at least on my distro). I found no way of disabling the plugin via configuration, but removing the plugins .so worked. On my system it can be found at `/usr/lib/qt6/plugins/kactivitymanagerd1/org.kde.ActivityManager.VirtualDesktopSwitch.so`.

There's a related issue, but this issue was complaining about the *lack of* the exact behavior we are now complaining of existing: https://bugs.kde.org/show_bug.cgi?id=435743
This comment (https://bugs.kde.org/show_bug.cgi?id=435743#c6) indicates the availability of disabling the plugin via the config file of kactivityd (`~/.config/kactivitymanagerdrc`), however I was not able to get it to work by adding `org.kde.ActivityManager.VirtualDesktopSwitchEnabled=false` under `[main]` (just guessing, I didn't find any docs for the configuration options for this file at all).

I submitted an MR with a patch that adds a configuration parameter for controlling whether the plugin is enabled or not: https://invent.kde.org/plasma/kactivitymanagerd/-/merge_requests/69

Great find!

Removing the plugin does indeed restore predictable switching behavior.

I've changed the product to point to kactivitymanagerd

I remember there being a GUI setting to configure this in the past, but can't find it now (perhaps it got lost in the activities KCM redesign?).

There was the usual plugin-page in settings similar to the rest of applications. Someone decided (forgot who, was a long time ago) that it just confuses the users, so we got rid of it.

(In reply to Ivan Čukić from comment #6)
> There was the usual plugin-page in settings similar to the rest of
> applications. Someone decided (forgot who, was a long time ago) that it just
> confuses the users, so we got rid of it.

As long as the config option exists on the file level this should be fine.
Having to deleting the plugin after every update would become really annoying, really fast.

However, I am bit puzzled that would consider users to be confused for these plugins but perfectly fine when it comes to other plugins, e.g. KRunner, Kwin effects and others.

Was it more an issue of the way to UI was done that was confusing?

Seems like my comment went to ether. Trying to remember what I wrote:

> Having to deleting the plugin after every update would become really annoying, really fast.

Plasma 6 disabled checking for whether a plugin should be enabled (and VD one was disabled by default) since 76a786d2a4d8f93df2330f1c47c8cc45cd0e961f and now all the plugins are loaded.

> Was it more an issue of the way to UI was done that was confusing?

The UI was the same as in KRunner. I agree a few checkboxes instead of them being showed as plugins would have been better, but I don't think the UI was confusing. And it served a purpose.


Looks like there will be some larger changes to activities:
https://invent.kde.org/plasma/kactivitymanagerd/-/merge_requests/69#note_975471

I used to have a similar setup as you. But, due to some ideas various people had a few years ago for radically changing activities or even removing them, I switched to a future-proof workflow that can work even with window managers that don't support activities explicitly (for the case if KWin removes activities, or if the tiling scripts for KWin stop working).

I've moved the applications that semantically belong to all activities (Kontact, chat applications, music player etc.) to a dedicated activity, let's call it Common. Alt+Tab serves as a switch between this Common activity and the proper 'current' activity. And other shortcuts are there to activate another proper activity. You should give it a go, I don't miss the old setup.

I am confused by this report - the behavior of "remember the virtual desktop per activity" is an old feature that I relied on since KDE 4. The relevant ticket is bug #241864 (and there was an issue with the remember feature being broken in Plasma 5 for a bit - bug #439183).

If I understand the OP correctly, maybe the requirement is "when switching to another activity where the current active window is also shown on the destination activity - stay on the same virtual desktop with the active window". Please correct me if I'm wrong.

Having this feature optionally disableable is also a good compromise, IMHO.

Oded:

I am not the OP, but I believe me and OP have the same request/problem with this: We navigate the activities/virtual desktops by moving along one dimension in the cube at a time. Remembering the virtual desktop breaks this since moving along the activities dimension also moves us in the virtual desktop x/y dimension. When you keep track of your location in your head this gets messy.

From our point of view the "remember virtual desktop" is a regression, while it seems that it was always intended to work that way. In Plasma 5 this didn't work (did it work for you?), but it seems that that behavior was a bug; A bug that became a feature for us.

So yeah, being able to disable the behavior would be nice. Currently we work around this by just deleting the plugin that's responsible for the behavior.

(In reply to Anders Wenhaug from comment #10)
> From our point of view the "remember virtual desktop" is a regression, while
> it seems that it was always intended to work that way. In Plasma 5 this
> didn't work (did it work for you?),

It does work for me - mostly OK. As noted in the second bug report I linked, it is sometimes unstable - though in Plasma 6 it has been much better (I don't recall being annoyed by it, but this could be my flaky memory) - as in: better for my use case.

My use case is that activities are fully separate activities (specifically I most often just have a "personal use" activity vs. a "paid work" activity) but with similar setups - web browsing is always on Desktop 4, terminal on 1, chat on 2, etc. When I switch activities - I switch context to another thing, and when I switch back - I want to keep doing what I was doing previously in that context. If I'm writing a work email, then I get a personal message - I want to switch to the personal activity, switch to desktop 2 for the chat, then when I switch back to the work activity - I want to be back in my email app regardless in which VD it was.

This is basically 2-dimensional "last recently used" switching - which we all know and love.

(In reply to Oded Arbel from comment #11)

> This is basically 2-dimensional "last recently used" switching - which we
> all know and love.

Your way of working makes sense and I totally get how it can be nice to work that way, it's just that me and OP prefer the other way.

(In reply to Anders Wenhaug from comment #12)
> Your way of working makes sense and I totally get how it can be nice to work
> that way, it's just that me and OP prefer the other way.

Granted. Then this ticket is a feature request for a configuration flag. I've update the subject accordingly.