Dear Maintainer,

activities can no longer be stopped in Plasma 6.5 and all are active at the
same time. Not only does this create a huge burden for the system resources
with a ton of currently unused processes, it also renders the UI, and
therefore activities as a whole, basically useless.

Cycling forward and backward through activities, e.g. with the thumb mouse
buttons, is straightforward when the typical two or three activities are
active. It does not work in any sensible way with the >20 activities which
are now always active. Additionally, moving windows to certain activities
is normally a quick task via the context menu, but now with >20 instead of
~2 entries to choose from, this is much slower.

Although removing this feature was a deliberate decision from upstream
(although obviously from developers not using the feature themself) the
reasons are not convincing to me. It basically boils down to: "It does not
work in all possible situations, so it is better to never work at all".

This makes the whole package mostly useless beyond the simplest of use
cases. For the simplest of use cases, however, virtual desktops are good
enough, so activities are not needed. Therefore, this change effectively
makes the package useless.

Therefore, I suggest that Debian corrects the upstream decision for the
Debian packages by reverting 690d377810f775b0e4e7512f9516c8a9ba123d4f.

Having every (non-trivial) user of activities recompile the packages
themself is not a viable option, due to the SONAME change, the large number
of reverse dependencies of libplasmaactivities7 and the strict version
coupling between the Plasma packages.

Kind regards
Patrick

control: tags -1 + upstream wontfix


Dear Patrick,

Le 5 novembre 2025 08:20:47 GMT+01:00, "Patrick Häcker" <pat_h@web.de> a écrit :

Dear Patrick,

thanks for your bug report. You're not the only one bothered by this change, the issue has also been reported as #1118361 [1].

Unfortunately that's more of a divergence than we're willing to maintain in Debian downstream as the already pretty thin stretched Qt/KDE Team.

So if the feature is that important to your workflow I would advise engaging constructively with upstream around that workflow to find a better way to bring back what you need.

Like you I don't like the decision since I was using the feature, but unlike you I share the concerns raised by upstream about its previous behaviour and think they would need to be addressed from a design standpoint before moving forward.

I think nested session management is a pretty difficult topic, since handling session management properly is already a topic of its own. And if I were to dedicate resource on the topic I would prioritise ensuring the best session management features are enabled in all apps (think proper app state restore) and also in the Wayland session before working on nested setups.


[1] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118361>


Happy hacking,
--
Aurélien

control: tags -1 + upstream wontfix


Dear Patrick,

Le 5 novembre 2025 08:20:47 GMT+01:00, "Patrick Häcker" <pat_h@web.de> a écrit :

Dear Patrick,

thanks for your bug report. You're not the only one bothered by this change, the issue has also been reported as #1118361 [1].

Unfortunately that's more of a divergence than we're willing to maintain in Debian downstream as the already pretty thin stretched Qt/KDE Team.

So if the feature is that important to your workflow I would advise engaging constructively with upstream around that workflow to find a better way to bring back what you need.

Like you I don't like the decision since I was using the feature, but unlike you I share the concerns raised by upstream about its previous behaviour and think they would need to be addressed from a design standpoint before moving forward.

I think nested session management is a pretty difficult topic, since handling session management properly is already a topic of its own. And if I were to dedicate resource on the topic I would prioritise ensuring the best session management features are enabled in all apps (think proper app state restore) and also in the Wayland session before working on nested setups.


[1] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118361>


Happy hacking,
--
Aurélien