kactivitymanagerd: activity switcher shows all activities instead of only those which are active

https://bugs.debian.org/1118361

I wonder whether this issue should better be in "Activities in general" component?
I first noticed it in the activity switcher applet. However as I can also not start or
stop activities, the bug may be more general.

I am switching it to "Activities in general". Of course feel free to adjust as needed.

Also choosing Debian Sid aka Unstable as closest match to Devuan Ceres.

Just to confirm: "/usr/lib/x86_64-linux-gnu/libexec/kactivitymanagerd" is running just fine.
I think it is started by its DBUS service as included in the kactivitymanagerd package.

According to "ldd" it also finds all its library dependencies.

This is an intentional change:  https://blog.davidedmundson.co.uk/blog/upcoming-changes-to-activities-in-plasma-6-5/

A decision was made to show every activity so no activity that was stopped is lost.

Thanks for developing Plasma.

Seems that is intentional¹. That is sad.

I relied on the functionality to start and stop activities and it worked very well for me.

For example for a writing task or working on a project or on development / packaging. For example I can have Kate, Dolphin and Okular open with some PDFs and on X11 when suspending the activity and resuming it again it all appears exactly where I left it, including the exact page in the PDF or the exact cursor location in the text file. And even with Wayland it could work, probably at the moment without restoring the window position. I cannot test anymore, cause while Plasma 6.5 appears to be the first Plasma version I can use with Wayland on my main laptop I cannot start and stop activities anymore.

I was really grateful for this feature. It helped me a lot.

This was perfect for activities I do not use all the time but sometimes. After upgrading from Plasma 6.3 to Plasma 6.5 I had >20 activities in my activity switcher which is

1. very unpractical
2. and a possible privacy violation when switching between activities while screen sharing in a video conference. Cause I may not be wanting to share with everyone what projects I work on.

My only sensible option for now was to actually *delete* all the activities I do not use all the time and thus their settings, like backgrounds, applets, open apps and so on. Cause anything more than 3 to 5 activities does not make sense to me when I need to keep them open at all times. I do not like to scatter my attention like this.

This was quite a loss for me.

Being able to start and stop activities is a very important feature for me. It helps me to focus on what is important in the moment by just having those activities open that I use at a given time. I do not want all of them open at all times cause I do not want to work on all of the tasks or engage with all of the activities at all times. Basically now I do not even get the point of activities anymore. Cause with that virtual removed I can just use virtual desktops!?

The genius of that feature was basically to have a session management within a session management. For me that was the whole point of it.

For me a major reason on why to use activities is gone. With what I had in Plasma 6.3 and all versions before that worked similar I finally was able to use them as a power feature that AFAIK no other desktop environment had. I was bragging about it: "Look, what Plasma can do!". Now that is broken. Now I have to start all the apps for an activity again, position their windows, open the files I was working on and so on.

Please reconsider.

One note regarding Flatpak: I did not use a single Flatpak app in such a context. I use Flatpaks. But only for apps that my distribution does not provide or where I see a benefit of containerization for security. I used start/stop with distribution packaged KDE apps *only*. And there it worked like a charm. I also understood to only stop activities that have windows that where not shared between activities. I used sharing between activities only for two reasons:

1. Make an email I opened as an extra window in KMail available in another activity for reference or cut and paste temporarily.

2. Apps that should appear on all activities. Like Basket for note taking or KeepassXC for passwords.

Am I the only one who understood how to use that start/stop feature of activities in that way?

For sure I hope whatever you come up with: Keep it then. Do not change functionality in a way that breaks workflows users rely on.

Or am I rely only one who has used activities in such a way? Activities used this way was one of the most underestimated and underrated features of Plasma. Sure discoverability was not great. But once I got it I thought: Wow!

I really appreciate the stability work for Plasma 6.5. Thanks for that! And I would like to see more of it. But change for the sake of change is not going to make things better. A slower pace with change and more focus on rough edges is what I would like to see.

Over the lifetime of activities you² changed them over and over and over again. Whatever you do, please come up with something and then *stick with it*. For a long time. Cause otherwise I am not sure how to determine whether I can rely on a given feature for implementing the workflows that suit me best. That it what I like to be able to: Rely on features to be there in years to come so I can base workflows I create for myself and others on it.

So this time, please think this through to the end.

Of course I respect that those who do the work get to decide. But this is my feedback.

[1] https://blog.davidedmundson.co.uk/blog/upcoming-changes-to-activities-in-plasma-6-5/

[2] As in whoever was developing for activities at any given time.

(In reply to David Redondo from comment #3)
> A decision was made to show every activity so no activity that was stopped
> is lost.

Thanks for giving this information. I missed your comment before I wrote my previous comment.

I never lost an activity that was stopped, so I do not get the point.

What happened quite a while ago that Plasma session management was broken in a way that it would not restore any saved session, including a stopped activity. But as that was solved, starting and stopping activities worked just like a charm again. I had complete workflows like writing for a book I contributed to organized in that way. All of that is lost.

I won't reopen the issue. But I certainly do not agree with that change. For me basically a major selling point for using activities is gone. I explained the reasoning in my previous comment and hope you may reconsider. Basically by now you could just remove activities altogether and I could probably just switch to virtual desktops. They are still not exactly the same. But a major aspect that made activities unique is lost. So what is even the point of activities now?

These power features are what for me make Plasma unique. They allowed me to implement the workflows that supported me to be as productive as I was. Gladly enough other power features are still available. But this is a loss nonetheless.

> I never lost an activity that was stopped, so I do not get the point.

the ability to start/stop activities was removed. as far as I understand stopped activities then would have had no way to "start" them again so every activity was made active.

I want to confirm that Martin Steigerwald is not alone with his situation: A feature which worked well within the specific constraints (working, e.g., around broken Firefox session management) was removed and the reasons to do so are not convincing. "The feature did not work so we removed it" is hard to follow when it worked so well and did no harm. I agree with Martin that now there is no point in keeping activities at all.

I have the feeling that the people who decided this did not really use and maybe did not even fully understand the feature.

"The end result is one that's inconsistent and unpredictable which is a state worse than not existing so we're dropping this feature."
No, this is a reason do document the feature, maybe warn before using the feature and maybe improving the feature. If we drop everything which is not fully consistent and predictable, the world will be empty.

"Will I see an impact? […] you can still switch between them as before […]".
No, we can't. Cycling between two elements and between > 20 elements is not only a small difference, it's the difference between "keeps the flow" and "unusable".

This is also no nice-to-have feature, but an integral part of a power-user's workflow. And there is no alternative, because Plasma was the only desktop with this feature. Everyone depending on activities to get work done now needs to stay with an older Plasma version or needs to compile more or less the whole Plasma themself due to the SONAME changes and the dependencies. What a disservice to the users and what a waste of resources.

(and yes, I know that the developers are volunteers and I am thankful for everyone helping out with Plasma, it's just that it looked like if the infamous KDE 4 times were finally over and now the fear of updating starts again)

>Please reconsider.

If the situation changes so that it actually works reliably, we will happily reconsider. 
But that needs to be a solution that covers the edge cases for everyone out of the box. 

There is a new proposed specification for session restore that  will work for flatpaks that we should see that get adoptions within a year. If that lands we should be able to surface some advanced session management to the user. Potentially via some other mechanism.

It doesn't address the root cardinality problem of what happens if an app is already running and doesn't support multi-instance. 
The only way I can see that part working if we only allowed apps to exist on one activity at a time which would also upset people. The activities cardinality doesn't work on paper.

>I have the feeling that the people who decided this did not really use and maybe did not even fully understand the feature.

Few users do unfortunately. 
I will say that we did speak to the original activities author before dropping the stopping, and he was in favour of it for the reasons given.

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