This is a long one, because 1) there was a lot that we discussed at Akademy, and 2) since many people are not aware of Activities, I wanted to provide some more context, so people can understand better.
Overwhelming interest
That I think Activities are cool should come as no surprise.
What was surprising though was just how much interest in Activities turns out there is the community:
- at the Activity BoF, we were about 30 people and it was a very constructive meeting
- the video recording (PeerTube, YouTube) of my Activities BoF lightning talk has already had more than 1.200 views – which I find just utterly wild
- completely independent from each other, apart from mine there were two other talks at Akademy that touched upon Activities and how they can be a foundation for cool advanced stuff – in the BoF we have taken some inspiration from them
This is all to say: it is the right time for Activities to finally shine!
Call for help
As I mentioned at the Tuesday BoF Wrap-Up, we unearthed a lot of (previously hidden) interest in Activities, but – as is often the case – much fewer people have the skills and time to help develop them.
So if anything written below tickles your interest, you are very welcome to join in!
The first point of entry is the #kactivities:kde.org Matrix channel.
What are Activities (my desks analogy)
In the lightning talk I used a desk analogy to explain how I understand Activities. I will summarize that here, but will not go into technical details of how Activities work.
Essentially, I consider virtual desktops and Activites as complementary or even orthogonal to each other.
I treat virtual desktops as real estate – analogous to extending the size of my physical desk. So I can fit more tools on it to get something done. So when I am moving a window from one virtual desktop to another, it is merely (re-)positioning my tools and resources around on the desk.
To continue with this analogy, I understand Activities as separate, specialized desks. Like you would not chop onions at your office desk and would not do woodwork on your kitchen counter, it makes sense to separate the tools and activity on your computer by context too. When you go get your study book, notepad and writing utensils, you also do not go browse for them through your kitchen cupboards and fridge, game collection or garden toolshed, but instead go straight to your study room where what you need is on the desk or in its drawers. This context separation and switching is what Activities enable on the computer desktop.
Context is king
One of the first things did was to gather some information what people use Activities for and how.
Very quickly a common theme emerged: almost everyone saw Activities as providing context to the task at hand.
In some cases those contexts were for longer-standing activities (e.g. communication, organisation, work, study, presentations, gaming); in other cases those contexts were used for more project-based activities (e.g. writing a long document/book, work for client X, work for client Y, programming project A, programming project B, vacation planning, …).
To help those, who have not had much experience with Activites yet, better understand, these are all things that are unique to an Activity and are useful to provide context:
- the Activity name, icon, wallpaper and layout of icons/plasmoids can jog your visual memory
- having a toolkit specific for that task by setting custom plasmoids and by associating/pinning individual programs, files and folders to that Activity makes it easy to reach the right resources
- Plasma stores file and program use history per Activity and that serves two purposes here – 1) by looking at the history and most used sections in KickOff you can more easily remember what you were working on; and at the same time 2) having the history only be restricted to this Activity, you can stay focused better because when searching for something in e.g. your programming Activity, you will not be shown your gaming or comic book history
Presentation of Activities to new users
A good start is that we already mention and quickly explain Activities in the Welcome dialogue. (I apologize that in my lighting talk I forgot that fact.)
But it would be even better if we could show that power and flexibility by shipping Plasma with a handful of preset Activities – for example, to get the discussion going:
- Main/default – as it is now
- Presentation – an activity that is intended just for making and presenting slides and demos, with the “automatic suspend computer” and “automatically turn off screen” options off
- Gaming – with gaming-related plasmoids and some games associated with that Activity, so they show up first on KickOff
The Presentation Activity is particularly one that several BoF participants thought was a great idea to avoid oversharing when presenting talks/slides or demos. Having a clean place, where the desktop, browser and their history is showing only presentation-relevant information would have saved many from awkward situations.
With the Gaming Activity we could demonstrate how you can be playful with plasmoids in one Activity, without affecting the other, more serious Activities, like Presentation.
Main/default Activity – avoid or embrace?
That brings us also to a problem many of us admitted to be guilty of – there always ends up this one Activity that you default to, when you are not working on any specific project.
It looks like many of us felt this as a failure (of either us or the system) as this main/default/chaos/dump Activity would typically be the gateway to procrastinating, as starting a new Activity would be just a little too much work. Also, if everything was associated with the main Activity, it lost its quality as context.
But perhaps a coming back to the default Activity should not be seen as a failure, but instead as a (ever new) starting point. To borrow the rooms analogy, instead of treating it as a hoarder’s out-of-hand den, perhaps we should treat it as a hallway, where you choose where you go next.
This needs some serious thought and discussion on how to tackle that. But it seems clear there is room for improvement and that it is possible to fix it.
We are exploring this very idea right now – see the Workflow idea below. This could be a game changer!
Low-hanging fruit
Some things seem like they might be relatively easy to implement. Activities are already hiding a lot of untapped power, remember?
These things below might be an interesting single-person contribution, if anyone is looking for a small thing to dive into.
Mentioning Activities in “find window” in KRunner/KickOff
Currently when you are searching for a window with KRunner, it will very helpfully tell you which virtual desktop the window is on.
Unfortunately, it will equally very unhelpfully omit to tell you on which Activity it is. Which is extra confusing if you have several windows of the same app in different Activities – like Kate sessions or browser profiles.
It would help a lot if instead of just saying “Activate window on Desktop 4” it would say “Activate window on Desktop 4 in Writing activity”.
Recently and commonly used files and apps (per Activity)
As mentioned, Plasma already stores the history of which apps and files were opened separated by Activity.
You can already access this information through Dolphin, if you type/select recentlyused:/ in the location bar. As you can see below, in the “Activities” Activity, that I recently made for this project, it is very useful already for quick access.
Even if we look at my very old “FLA” Activity, the history there remains very useful and jogged my memory about where I can find more information about not just the latest draft, but presentations and other documents I accessed while analyzing different options.
KickOff (and other launchers) show even more historic information. Confusingly though, the historic information lies under the “Places” tab in KickOff.
In addition to files and folders, here we can also see application history.
Not only does it show recently used files and apps, but often often used ones too! For some this has the potential to replace (or enhance) the favourite/pinned apps in the menu.
Kai Uwe Broulik was so cool that he already implemented an option for the users to at least set the “Places” tab as the default tab in KickOff while he was sitting in the BoF! (I do not have the link to said merge request at hand, if I get it I will post it here.)
Still, it would be great if we made this information easier to access by the user and make it more useful. If you have any ideas, there is a lot of potential here, it seems.
Plasmoid to show history
But, surely, we can do more than that!
For inspiration, we can look at the timeline demo by Scott Jenson.
Per-Activity information we can already gather:
- file/folder history – as seen in the above screenshots
- application launch history – I do not know the details, but assume Plasma records timestamps for it too
- browser history – not out of the box, but you can use the Activity-aware Firefox wrapper together with the Plasma Browser Integration (and you enable access to browser history in its option)
In addition to that, it could be very useful to also add see a ChangeLog/journal of what you did in that Activity. (See the Workflow idea below.)
Perhaps as a start, as a testing ground to see if this is useful to users, someone can make a simple plasmoid to show a timeline and put all of the above info in it … and then we start using it and gather feedback whether what could be improved (or if it is a terrible idea).
As Scott Jenson said, it is up to the FOSS desktops to innovate and it seems it is the right time to do just that and play around a bit (to paraphrase Nuno Pinheiro).
Context-aware clipboard / scrapbook (i.e. per Activity)
Another thing from Scott Jenson’s talk that seems like a very powerful idea, and relatively easy to develop in Plasma is the clipboard/scrapbook demo – but with the slight change of doing it per-Activity instead of per-Document.
There are two reasons for this modification: 1) as we already have Activities it should be much easier to set it up that way instead of writing a new way to associate clipboard entries to files/windows/applications, and 2) it makes a lot more sense to store all the project’s information per Activity – history, plasmoids, favourite/pinned files and applications and now the clipboard/scrapbook.
The obvious solution would be to modify Klipper to support Activities in some way.
And the obvious caveat would be what happens when you want to copy something in one Activity to bring it to another? So a 100% separation between Activities may not be the best option.
Maybe we should introduce an additional separate part of Klipper that is a per-Activity scrapbook and does not automatically get cleared. Then, the user could have the scrapbook-view of the Klipper plasmoid on the desktop (or in a panel) for easy access.
This is just brainstorming, to get ideas going and test things out.
Again, Kai Uwe Broulik was already super-fast in creating a merge request in Qrca that goes a bit in this direction.
Time tracking
“Funnily” enough, at the BoF someone suggested that it would be very useful for them to track the time spent in an Activity. Their use case was that they have a separate Activity for each paid project they do for a client, and knowing how much time they spent on a project this way would make things much easier. I say “funnily”, because that functionality got removed not too long ago under the assumption that no-body uses it 😅
At least we know it is not hard to do, as it was done before. And Ivan Čukić said it was trivial to implement – sounds like a great small first project 😉
Here are some use cases for where this could be useful:
- count time spent in the Activity – e.g. to track work, paid projects (and offer different time statistics – per day/week/month/total)
- limit maximum time – e.g. to limit time for playing games, work, doing responsive tasks like processing e-mail and work chat
- enforce minimum use – e.g. too force you to stay in the studying or writing mode, before being able to switch to a different Activity (and ideally prevent you from accessing stuff that’s just a distraction)
Do not disturb mode
It would be great if we could trigger the “Do Not Disturb” mode when starting a specific Activity.
This would be particularly useful for the Presentation Activity and any others where the user wants to concentrate on.
In the Activity settings, next to where the “do not suspend” and “do not turn off screen” options already lie, there is a great place to put it.
Another one that sounds like it would be a great first contribution to KDE.
The Workflow idea – the star of the show
While we were discussing all of the smaller and bigger things that we could do to make Activities better and compared how each of us understand and uses them, sharing papercuts and frustrations … an idea started crystallizing.
And I think we are on to something that could indeed be the next big step in how we use desktops.
Some friction that we all noticed with Activities is that they take time to set up – not much, but it adds up. What we need is a way to quickly start and quickly stop Activities.
So we started thinking what about if we flipped the Activity creation over and instead make it more like saving a file or a session. And that snowballed into the following use case:
- you are working on something on your computer
- you decide to do something else, but want to get back to that thing later on
- you click “save Activity” and the dialog asks you to:
- provide the name for what you were working on (and icon), so you can find it later on
- optionally, provide the description of what this thing is you are working on (or motivational message), so you can remember better
- optionally, write a note on what you did (changelog)
- everything you were working on – the desktop setup (background, plasmoids, icons), files, application windows, scrapbook, etc. – gets shoved aside
- with a quick prompt you select whether you want to continue an Activity you saved before, or start a new one (from a template or blank)
- let us say, you decide to continue writing your thesis, that you have not touched since summer
- you are greeted with your last description/note and the changelog to quickly remind you where you left of
- a familiar desktop setup (backround, plasmoids, icons) gets you back in the mood, while scrolling through the history plasmoid’s timeline and seeing your thesis scrapbook provide the necessary context to start working on it again; you immediately see the relevant files too, as they are top on the recent and commonly used list here (or you even “favourited them”); the right Kate session is already there too, and the notifications are automatically blocked … everything you need to continue your research, apart from a nice cup of tea
GOTO 1
As an analogy, one BoF participant called these “work snapshots”.
To achieve this without (re-)introducing needless friction again, such a workflow needs to accommodate for:
- perpetual Activites – such as organizing, communication, general reading, time wasting, gaming, system tweaking, …
- project Activities that have a start and and end – writing your thesis or book, a research paper, a programming project, planning the next vacation, etc.
- single-use Activities – even shorter than projects, where you do not care about the history, you just want a clean slate to concentrate (perhaps from a template)
- fall-back Activity – the “hallway” from which you choose where to go next
- easy to create/modify Activity templates
What I described above is just the simple use case we collectively thought up during the BoF session. Shortly thereafter Andy Betts was amazing and started a more detailed design document in the KDE VDG. That is where you should go next, if this “Workflow idea” interests you.
There is still work to be done here and details to iron out, but this seems very achievable and it could turn out to be a killer feature of KDE Plasma.
More tricky ideas
As opposed to the above, I think that the below are some ideas that would need quite a bit more work added to get them working without breaking things elsewhere.
Activity-based app settings profiles
A common problem with Activities, and a reason for many to give up on them, is that unless a program has been specifically written to be Activity-aware, it can be a bit quirky and tricky to force it to work differently in several Activities.
To combat that, an idea was to use Activities as profiles/sandboxes for application settings. That would mean that if a program is not Activity-aware, its settings would get stored per Activity so it would essentially still act differently in different Activities. There is some ongoing work here already as part of a wider settings management system, but it is very early days.
If this works out, an interesting bonus would be that it might be possible to import/export settings or even sync whole Activities across different devices.
There are several complications to take into consideration though. Just to name a few that were mentioned at the BoF:
- How to handle single-instance apps (e.g. KMail, KOrganizer, most communication apps …) that do their damnest to make sure there is only one instance of this app running?
- Related to that, how to make sure that an application can be used with the same settings in different Activities, if the user wants that instead? And how to we present the two options to the user?
- How to detect if a program works nicely with Activities or if it needs settings sandboxing?
Luckily, there is already an example of how this can work (or at least similar enough) – Activity-aware Firefox] creates a Firefox Profiles for each Plasma Activity to separate the tabs, history, settings between them. It works pretty well, but it has some caveats.
One participant presented a detailed use case on how they would like to use one Activity per client they consult. In each activity, they would like to have different Dolphin places/bookmarks, browser sessions/cookies (e.g. profile), recent files/history, projects/settings in the IDE, sticky notes/scratchpad, search settings in Baloo and separate MS Teams tenants.
Better context isolation (against AI)
Continuing with the sandboxing, the other talk that mentioned Activities (by Eva Brucherseifer and Jan Mühlig) was about a suggestion on how one could safely (and optionally) use AI on the desktop.
At the BoF we agreed that whatever we intend with Activities should work with no AI/LLM needed at all and that our scope is limited to Plasma and Activities.
I will still take this opportunity to point out a few things that I found interesting regarding that talk and even more so in the hallway discussions – and here I am not speaking for the BoF, but just sharing my personal thoughts:
- I found it interesting and exciting that others at the same Akademy, completely separately, decided to talk about Activities as a foundation for work separation and project-focused workflows. This reassures me that the base idea of a better and more prominent Activities workflow is sound.
- LLM and AI agents are a thing. While no-one should be forced to use it, IMHO it is only time until we see wide-spread “AI agent as payload” malware – and with that not just voluntary, but also involuntary AI use.
- From what I heard in the hallway, the way things are right now, once you install an AI agent on any desktop – FOSS or closed-source – it basically gets complete access to do whatever the user can do on it. That is scary.
- Activities can be, and indeed seem like a good option, an integral part of setting guardrails around contexts, so an AI agent cannot access more than it is allowed to (within that Activity).
So, IMHO even if you do not subscribe to the workflow proposed by Eva and Jan, there is a lot of good points about hardening the desktop to make sure if an AI agent gains access to it, the damage to the privacy and security can be negated or at least contained.
Because this is a touchy subject, let me reiterate that this is out of scope of the Activities BoF and our current plans for making Activities easier to find and better to use.
… and now back to our regularly scheduled programme …
Better resource and session management with Activities
Resource management is also a topic, of course.
If this Activity-based Workflow takes off, we need to figure out how to manage resources on devices where a dozen – or even dozens! – of Activities are running at the same time.
Until a few versions ago, you were able to stop an Activity and later resume it. The idea was brilliant and I relied on it a lot in order to manage my cca. two dozen Activities. The problem was, that there were way so many edge case problems, you might as well look at a circle. So it got removed. (Some of us mourned, but it was the right decision.)
Still, if we run something like two dozen Activities and each of them has its own set of applications with different settings, as well as custom wallpapers and plasmoids – things add up.
An interesting idea that popped up during the BoF was that perhaps we could simply dedicate less resources to Activities that were not used in a while.
Luckily on Linux and other Unix-like systems we can tweak the “niceness” of processes. So we could make it that the longer an Activity has been inactive (i.e. not currently focused), the lower the nice and ionice values for the processes in it would get. And then at some point, we could even prompt the user if they want to close (and save the session of) an Activity that has been inactive for very long.
Especially the idea of closing of a session was something that we think is worth exploring even further. Even though the way Activities stopped/suspended before did not work really well, now that support for sessions in Wayland is progressing in Plasma, there is potential to do it right. From what I understand, the new xdg-session-management protocol would be key here (relevant news article).
Per-Activity sessions would greatly support the Activity-based Workflow.
Once you decide to do something else, when you end your current Activity, you could decide to either put it into background or stop it, so the resources it was using get released, (or delete it completely). If it runs in the background, it would become “nicer and nicer” in time. If it was stopped, the session would be saved to be later loaded up again.
Some further thoughts we gathered for future consideration on this topic:
- What should be the default when switching from an Activity? Some suggestions to consider:
- Perpetual Activities, when unfocused, should not automatically ask to be stopped even after a long time. The user can manually stop them anyway.
- Is there any reason to ask the user when an (e.g. project or single-use) Activity gets unfocused, what they want to do with that Activity? Or is is too much chatter/friction and we should simply leave it to the “niceness and propose close session”-algorithm and the user’s direct control?
- On reboot/login how should Activities get loaded, by default? Some suggestions to consider:
- Perpetual Activities should get automatically loaded.
- There should be an option to set an Activity to only load if explicitly requested by the user (i.e. “do not ask on reboot/login” option).
- For the rest of Activities the user should get presented as suggestions to load after reboot/logging in. Maybe this specific option is a bad idea and we should only auto-load Perpetual Activities and let the user load the rest as they decide what they want to do.
Varia
Unorganized notes
Some more notes from BoF participants that I do not have enough context (ha!) about to expand in more detail:
- private Activities (sandbox + Tor/proxy automatic setup)
- separate Activities in System Monitor / grouping resources
- premade templates
- power management in Activities – probably not going to happen, that was removed a few releases ago for a reason
- enable plugins in all subsequent sesisons for KDevelop/Kate
- more Activity support from apps / KDE Gear: Kate, Kaidan, KMail, …
- project overview in Activity
- Activities as profiles with data isolation
- switching between desktop layouts and themes
- similar to profile features on mobile phone / sub-users
- stopped using Activities because they did not stay on one project in an Activity, but got sidetracked all the time … and then forgot Activities exist
- better WM support when cycling through windows
- clarify difference with virtual desktops; often new users find about Activities, because they want to have a different wallpaper on each virtual desktop, and then they find a recommendation online that says to use Activities instead, so you can do that (but not what else are the differences)
- it should be easier to build your own plasmoid, or even your own Activity layout
- security and privacy options per Activity
- I do not use Activities, but rely on virtual desktops for context separation and on (X11) session management; switching between contexts needs to be “instant”; time tracking would ne useful
The naming (non-)issue
Pretty early on in the discussion the naming issue arose. Because we were short on time and history has shown that this debate has no end, I decided to cut it short. To make up for that, let me explain myself here.
To get the obvious out of the way first: Yes, I agree “Activities” is not the best word to describe all that is possible with them, but I argue that that is fine.
When we think of a desktop environment, we think of windows, icons, menus and pointers – those are words we throw around every day, but have you ever thought how they bizarrely look nothing like their real-world physical counterparts?
Imagine for a minute – and really try hard to imagine the following physical objects while you are looking at your actual physical desk:
- you repurpose a printed paper, intended to put on a wall instead on your empty wooden desk to make it pretty
- then you put a bunch of religious art on said wall-decoration-covered desk
- when poking a piece of religious art with a rod, a window magically appears on the desk (without a wall to support it)
- oddly enough “opening” a window makes it appear – usually windows first have to exist, before you can open or close them
- again, oddly enough, “closing” the window, destroys the window
- through the window you see a bunch of text and a handful of buttons that are somehow stitched to whatever magic fabric is “in” the window (possibly the same invisible material as the wall holding the windows that you can freely move around and change the sizes of)
- poking the buttons with the rod (through the window) sometimes makes things that you see through the window change
- (all of this is still happening on your actual desk, keep that in mind)
- there are files and folders on the desk – that at least make sense
- you can put files into folders, but you cannot put folders into files (sic!)
- in order to open a file or folder you need to poke the piece of religious art, that represents it, with the rod, and then a new window appears (“opens”) on your desk and you can see the inside of the folder through said window
Now tell me which drugs you were on if any of this made sense … and can I have some? 😅
And then even if we get the English naming just right, the question remains how that word can get translated into the 100+ languages of KDE.
Since Activities have existed since 2010 (and have their established translations), I think that it is fine to continue to use this name for them, as long as we explain and show in a better way what they actually are.
If an ideal name happens to drop into our collective laps, I agree we should take it into consideration, of course. But that is a much much lower priority than basically anything else in Activities.
What is Plasma anyway?
I recall a discussion with another participant that, just as me, has been a long-time heavy KDE user that I think is worth mentioning.
At an Akademy social event I claimed that KDE 3.5 with SuperKaramba was peak old/traditional desktop and that it would be a huge pity if we threw away all that massive innovation and work that went into the Plasma 4 rewrite, if we simply removed or hide all the weird cool stuff in order to make it look like a traditional desktop again. I argued that since no-one else is innovating, we would simply re-invent the KDE 3.5 with SuperKaramba again, just with better graphics.
And Jason, I think his name was, reminded me why “Plasma” was called the way it is (I am paraphrasing):
Plasma is a neither a gas, nor a solid(, nor a liquid).
And similarly, KDE Plasma is a malleable thing full of potential. Panels, windows, widgets, etc. – they are all there for the user to define what they want them to be. A chat, for example, can be in a window or it can be in a widget. That widget can be on the desktop or in a panel and you can move it from one into the other.
Apparently that was super noticeable on netbooks, where Activities were a central part.
This is also part of the reason why quite a few things on Plasma are abstracted into Baloo, Akonadi, etc. – because the same thing can be used in several places at the same time, sharing a common (local) backend.
With all the pain that came with Plasma 4.0’s instability, there was a great deal of innovation and flexibility – including Activities. And with ironing out the kinks and polishing, in time Plasma got more and more predictable, stable … and boring. And on one hand, that is great.
But, on the other hand, I think we should also continue KDE’s mantra of “Simple by default, powerful when needed” and not shy away from its powerful components and building exciting, fun and useful stuff with it.
If you have not yet, I warmly recommend you watch the KDE Documentary and browse the KDE Timeline.
Wrapping up
That was a long read …
So to summarize the important parts:
- Activities are cool and we plan to improve them a lot
- what I wrote above are a bunch of ideas in different levels of maturity, but none are set in stone or with a dedicated developer
- we need help – if you are interested in any of the ideas above of Activities in general – join us on Matrix, Invent and the Activity Workflows issue
hook out → I apologize that this report took way too long, but I had a lot on my plate … some of which I will blog about very soon
P.S. People at the BoF complained that I used Oxygen icons. I hope my switch to Buuf made them happier 🤣
Sho
@silverhook:matrix.org
