Bug 482892 - Feature request: allow disabling "remember virtual desktop separately for each activity"
Summary: Feature request: allow disabling "remember virtual desktop separately for eac...
Status: CONFIRMED
Alias: None
Product: kactivitymanagerd
Classification: Plasma
Component: general (show other bugs)
Version: 6.1.0
Platform: Neon Linux
: NOR minor
Target Milestone: ---
Assignee: Ivan Čukić
URL:
Keywords: qt6
Depends on:
Blocks:
 
Reported: 2024-03-08 16:33 UTC by Kevin Krammer
Modified: 2024-09-24 22:23 UTC (History)
6 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Krammer 2024-03-08 16:33:19 UTC
SUMMARY

After upgrade to KDE Neon 6.0.0 switching between activities also switches the active desktop.

My setup has 6 virtual desktops and 3 activities (one for each different project).
I have my main chat program opened on desktop 1, with special KWin rule to have it on all activities.

When I get pinged I switch to desktop 1 (via keyboard shortcut), see which channel it comes from, and then switch to the most appropriate activity (again via keyboard shortcut).

Until the upgrade to 6.0.0 the activity switch kept me on desktop 1 so I could continue to read the message(s) and react.
Now it also switches the desktop.
Looked random at first but after a week of using it in that state it seems to switch to the desktop that I had been on when switching away from that activity.
Which could have been hours or even days ago and makes no sense in the current context.

STEPS TO REPRODUCE
1. Configure multiple virtual desktops and activities.
2. Switch to second activity and switch to second virtual desktop
3. Switch to first activity

OBSERVED RESULT

First activity becomes active, virtual desktop gets switched to first one

EXPECTED RESULT

First activity becomes active, virtual desktop stays on current/second one

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: KDE Neon 6.0.0
(available in About System)
KDE Plasma Version: 6.0.0 (24.02.0)
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

ADDITIONAL INFORMATION

KWin X11 session
Comment 1 Anders Wenhaug 2024-03-14 00:07:24 UTC
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
Comment 2 Anders Wenhaug 2024-03-14 03:41:55 UTC
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).
Comment 3 Anders Wenhaug 2024-03-14 23:53:02 UTC
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
Comment 4 Kevin Krammer 2024-03-17 13:41:03 UTC
Great find!

Removing the plugin does indeed restore predictable switching behavior.

I've changed the product to point to kactivitymanagerd
Comment 5 Kishore Gopalakrishnan 2024-06-23 12:36:11 UTC
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?).
Comment 6 Ivan Čukić 2024-06-23 13:05:37 UTC
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.
Comment 7 Kevin Krammer 2024-06-23 13:50:51 UTC
(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?
Comment 8 Ivan Čukić 2024-06-23 15:41:11 UTC
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.
Comment 9 Oded Arbel 2024-09-24 08:38:52 UTC
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.
Comment 10 Anders Wenhaug 2024-09-24 09:49:39 UTC
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.
Comment 11 Oded Arbel 2024-09-24 10:41:45 UTC
(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.
Comment 12 Anders Wenhaug 2024-09-24 10:48:11 UTC
(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.
Comment 13 Oded Arbel 2024-09-24 22:23:45 UTC
(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.