Make one system - Virtual Desktop or Activities

Brainstorm
41

I did some investigation to see what seems to be the case right now with activities:

  1. I cannot set different settings for notifications per activity (at least it isn’t obvious that this is happening)
  2. I cannot change font sizes for one activity, without changing the font sizes for everything.
  3. I can change the desktop, wallpaper, and widgets
  4. There isn’t a clear way to customize krunner results based on activity.
1 Like
42
  1. you can’t have different virtual desktop arrangements
  2. you can’t have different window tiling arrangements.
43

Maybe we should do a kickstarter to finance future work and improvements to Activities, since it’s a cool feature with a lot of potential.

44
  1. You can’t have different panels per Activity.

I can’t quickly find reference to it, but at least in the past, this was purposefully removed as a feature - back in the KDE 4 era for sure, and a mention from a Plasma dev somewhere somewhat recently that this wasn’t going to happen.

I can understand why – using Latte for the purpose made the plasma-org.kde.plasma.desktop-appletsrc file quite messy or cumbersome, I think.

But I still want the feature :laughing:

45

There is a section for it : Sponsored Work - KDE Discuss

Big problem is to have a vision and that is KDE is lacking since the era of Plasma 5. KDE4 was buggy but had a vision.

46

Can we do without a vision, but with a clear and documented discussion on the improvement of the Activity feature? But I’m sure someone already attempted that.
I suppose the vision comes for the most part from KDE goals.

1 Like
47

After carefully reading all peoples use cases and concerns, I don’t see there being just one (Activities or Virtual Desktops from my first post).

I am all for a separate .config for each Activity with would allow for a multitude of interesting setups. This would need a Activity manager for copy / clone / delete / new (based on default) as described above.

48

Cool! So a crowdfunding could be organized in that section?

49

Yes but who decide what is an improvement or not ?

50

You can try and see how people respond.

51

That’s why a big discussion on the matter takes place: to choose criterias, priorities, etcetera. But it seems like someone tried it, because I read lots of posts like this one. Maybe it has not been done with the proper effort or organization.

52

I guess the question that I have is what is needed by the people doing the approvals ultimately to merge the code (e.g. acceptance criteria). It seems to me we want a way to:

  1. a period of time where we collect use cases (maybe a 2 weeks/ 1month), followed by some ranked choice voting on priorities to help people volunteering to work on things decide what is most useful (another 2 weeks/month) – this won’t dictate what gets worked on, but for may help people decide. We also probably should get separate votes/feedback if any specific feature is inconsistent with KDE maintainers’ vision of what these features should be and interact with the rest of KDE. We shouldn’t assume that the current KDE devs will do the ultimate implementations (they have other awesome things they are working on), so getting some buy-off will be key.
  2. After we have some general idea that the features are well aligned, proposal(s) what the feature would look like and how interactions would work (e.g. mockups). My personal experience is that this can be much more lightweight than full code implementations, and can provide early feedback on implementation which is useful in larger coordinated features.
  3. After that we start implementations.
53

Maybe because there are not enough people using it so no one really care about it. That’s why I agree that it should be included to the overview.

54

I think adding it to the overview would help people get in touch with the feature. It could also confuse people who do not have any use for activities. But a discussion on the feature itself would be somewhere else even without this addition.