Notes from the Graz Plasma sprint

A few days ago I returned home from a wonderful Plasma sprint in Graz, Austria. Between COVID-19 and there being no Plasma sprint last year in favor of the Goals mega-sprint, this was actually only my my third in-person Plasma sprint! So I was very excited to attend. There’s much to talk about!


This is a companion discussion topic for the original entry at https://pointieststick.com/2025/05/01/notes-from-the-graz-plasma-sprint/
4 Likes

@ngraham, is there a reason that such a store seems necessary, atop what distributions’ package managers and their associated verification procedures provide (or even something like pip3, at worst)?

1 Like

Strictly speaking, very little is necessary, and this is definitely included.

However, it’s convenient to have a single distribution source for add-ons, the same way it’s convenient to use FlatHub as a single distribution source for apps. Going through one of these channels ensures that you as the developer are in control of the release cadence, and you aren’t dependent on the mercy of 50 overworked packagers in 50 distros doing redundant work. Imagine if you made a new Plasma theme and had to wait two years before anyone in Debian could use it — if it even got packaged at all!

4 Likes

Apologies, @ngraham… In retrospect, I suppose that should have been obvious. All the more reason why the section about ascertaining whether these can be packaged with flatpak would be wonderful! Very clever.

I love that Activities are getting some love again!

Something that came up over and over again was the desire to use certain apps differently in different Activities. For example in your “Home” Activity, you could have your email client set up to only show your home email accounts, whereas in your “Work” activity, you could have the same app set up with only the work email accounts, or with both. But it would be the same email client app in each Activity, just configured differently!

[…]

We thought this feature would be useful even outside of Activities, so our conclusion thus far has been to build it first! After it’s in production and the kinks have been worked out, it would then become the basis for the Activities system’s new scope: “configure and use your apps and virtual desktops differently in each Activity.”

That makes a lot of sense.

There’s several applications that could benefit from such “settings (and state) profiles”:

  • web browsers (I currently maintain the Activity-aware Firefox wrappers, but would love if this was automatic)
  • text editors – e.g. different Kate Sessions bound to different Activities
  • e-mail, as mentioned
  • other chat applications – e.g. imagine having different sets of channels and contacts depending on the Activity (that might be hard to do, because the subscriptions are likely server-side)

One thing that might be a bit tricky is easily sending things (tabs, projects/files, contacts, …) from one such “containerised” Activity to another.

Another thing that I think would push Activities to the next level is the Wayland session-suspend / checkpoint restore that @David_Edmundson (sorry for the ping, mate :heart: ) demoed a few years ago. Just imagine per-Activity sessions that when you suspend it, it stores everything to the disk and when you restore that Activity, it resumes it exactly the way everything was.

I imagine a caveat of this ”Wayland checkpoint restore” might be how to handle apps and services that sync with other Activities/sessions/internet.

Anyway, super excited about this. And if Activity-suspend-and-restore can become more toolkit agnostic, that would be a dream come true!

(P.S. I really need to finish my blog post about how I use Activities … just so much to do)

2 Likes