Activities are a new concept to me, and the help files aren't very detailed, but here is how I understand activities: A. I can assign applications (windows?) to activities, so that an application belongs to (one or more, or "all") activities. B. I can switch activities by clicking on the three colour dots and then another activity. C. I can stop activities by clicking on the stop symbol, which is not the same as switching away from the activity to another one. The bug I am reporting is reproduced as follows: 1. Assume you have three activities set up, let's call them Run, Jump, Wiggle. 2. Make all the activities active and switch to, say, Wiggle. 3. Let's have an application (e.g. Musicplayer), that is currently open. Put the window to belong to activities Wiggle and Run, but not to Jump. 4. Stop the activity "Run" (by clicking on the three colour dots, and then clicking the Stop symbol on "Run"). Expected behaviour: Musicplayer should not be affected, because it is part of the active activity "Wiggle". Actual behaviour: Musicplayer is shut down. I think this is a bug. But then, if I didn't understand the concept of Activities correctly, please close this bug. For example, I can't really say what should happen with the Musicplayer window when I switch to Jump. In my opinion, the window should disappear then but the Musicplayer should keep running. (Because the activity "Wiggle" is not stopped.)
PS: Actually, in my last thought... I think the Musicplayer window should not be hidden when I switch to Jump, because it is just as much part of the activity Wiggle as it is of Jump. Maybe for each activity, we need to define both which applications belong to it (this part exists) and where to focus when I switch to that activity. E.g., maybe when I switch to Jump, I mean to look at the web browser. So then the Web browser window should get focus, regardless of whether or not Web browser was part also of the previous activated activity.
Seems you understand activities correctly. This is the issue of the session protocol. It is not designed to support the same application in multiple sessions like it is required by activities. I agree with your statement, and will not close this bug for the time being. Although there is no much hope for it to be fixed. (changing the session protocol would probably need changes in underlying frameworks like Qt, Gnome-whatever, etc.)
Just woke up and I saw things more clearly. I agree, windows/applications should not be part of more than one activity. There's a conceptual bug in my "understanding" of activities, which relates to what should happen when you switch between two activities A and B that are both running (not stopped). My previous understanding: * If you want an application (say music player) to continue running when you switch from A to B, then it must be in both activities. This leads to a contradiction with the other basic ideas I had about activities. Because then, if I want to stop music player (e.g. because of starting the activity Phone, see suggestion bug 304514), I would have to stop all the activities that contain music player. This would then also stop lots of other programs (e.g. whatever is only part of activity B), that should not actually be stopped. So I suggest a slight revision to the Activities, to get around the above. A. An application (or window?) can only be part of one activity (or "all" activities, which means basically the application does not participate in the activities scheme). B. When you stop/start and activity, the windows and applications associated with that activity are shut down/opened. C. When you switch to a stopped activity, it is started first. D. When you switch to an activity, then the focus and view settings are adjusted to that activity. I.e., virtual desktop switch, wallpaper background switch, move windows around, give focus to "main" window for that activity, etc. As a corollary, when you switch an activity, nothing in the old activity is hidden or disappears. (Maybe it gets minimised but it must not disappear.) This is because an application can be part of one activity only, and if you want it to continue running in combination with other activities, it has to have a usable control interface. (If you want an application to stop or disappear, then you have to stop the activity that it is associated with. Or close it manually. So the suggestion 304514 would come in handy here.) Advantages: * Applications don't stop or disappear when they are still needed. * Maybe this is compatible with the "session protocol"? * It's more intuitive to me in the way I define activities, i.e. I can do more than one thing at a time if it includes passive things like listening to music. Disadvantages: * Does it mess up the way activities work for those people that already use them? * Without bug 304514 implemented, this will require more clicking on activities to start and stop them. However it could be seen as equivalent to opening and closing program windows, if the user has set up all the windows and activities correctly. * There has to be an option to configure what would be the "focus" of an activity.
Activities are not meant really for application-centric usage. The use case behind one window, multiple activities is that you can have, for example, two documents opened in kate, where one document should be in activity A, and the other one in activity B. You can set kwin and plasma not to hide windows from other activities. IMO, that would completely defeat the idea of activities, but you can do that if you want.
OK. Maybe I need to read up on how activities are meant to be used. Can you post a link to the documentation? I can't seem to find it from the KDE webpage. Thanks!
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
I'm afraid the feature to stop Activities has been removed in the upcoming Plasma 6.5 release, rendering this older bug report obsolete.