{March 7, 2010} Activities and Context, again

So I promised I’d write about all the activity/context stuff we discussed at tokamak, didn’t I?

I was hoping to have something to show first, some pretty screenshots – but that’s going to take a little longer, it seems. In the meantime, I guess words will have to do.

So… where shall I start? Well, let’s go over the pieces involved. The most visible part of Context will probably be the workspace UI – plasma and kwin. Plasma will, of course, have the UI for managing Activities. Kwin (KWin?) will filter out the windows that shouldn’t be shown, and allow you to manually associate windows with activities (after all, in the beginning few applications will be context-aware).

In plasma we’re starting simple, with something that’s sort of a much prettier Activity Bar, sharing some UI code with the widget explorer (which means I’ll probably clean up some widget explorer code while I’m in there, too). From there I can add features and make it something that actually allows management of the activities, based on the mockups one of our designers drew at tokamak. (uhm, anyone got photos of that?)

There’ll probably be a behaviour change too: when there are multiple screens, they’ll still have one containment each but they’ll be treated as one “activity”, switching together and being closed and opened together. That means we’ll have to provide a sensible way of dealing with ‘orphan’ containments when a screen’s disconnected, though.. aw fuck, I completely forgot to bring that up at tokamak. grr.

Anyways, it looks like I’m going to be doing most of this plasma/kwin stuff; the only part I can guarantee will be in 4.5 is the most essential features of the plasma actvity UI. Still, it’s looking like I’ll have more hacking time soon, so hopefully I’ll get a lot more done. :)

Then there’s the plumbing: all the behind-the-scenes stuff that makes things actually work. Nepomuk will store associations, since that’s what it’s good at; connecting all the related documents and contacts and things with the activity’s UID. Then there’ll be a simple little kded module that handles activity management: something that apps can easily query to know what activities there are and which one the user is in right now n’stuff. We’ll also have some convenience code in kdecore for talking to that kded module – that way kde apps don’t have to mess around with dbus to be activity-aware. Oh, and there’ll be another API for workspace, for actual management of the activities (creating/destroying them, etc).

One neat thing that we’re doing in the backend is that windows can advertise what documents they’re working on – that can be used to associate them with activites automatically, but may also lead to other interesting stuff, like kwin knowing what tabs are open in your browser…

Ivan’s doing this work – in fact he’s already done a lot of it (and blogged about it), but it’s been hiding in playground. You’re going to get that into kdereview now, right, ivan? :)

Another backend bit coming later will be session management – when you close an activity all the windows that belong only to that activity should close too (and then come back again when you open it, of course :). I *think* I can make that happen with XSMP, but I need to look into a couple of things to make sure it’s actually possible, and I still haven’t got around to that. XSMP isn’t the nicest of protocols (lubos told me some scary things about it at tokamak), but it has one huge advantage: apps are using it already.

And applications are the third piece of the puzzle. Once we have the backend in place, and workspace programs using it, we need apps to use it too. If they advertise their content, they can be associated automatically with activities. They could offer other cool features too, adapting to the current activity… I’m sure people will think of cool stuff to do with it once we’ve got a few apps to serve as examples. :)

So we have workspace stuff to let the user manage their activities, a few things in the back holding it all together, and apps adapting to the activity (and perhaps other contextual info someday).

The activities serve as a sort of anchor for your context – a way to say clearly (to both you and your computer) “I’m working on this project now” or “I’m just gonna read comics and surf the web”. The context behind that activity gives it meaning – associations with the documents you use for that project, tools you use, contacts who are involved… that sort of thing. And the apps are, usually, where the actual work gets done. :)

I’m really looking forward to the day when I can just start a new activity, drag some windows (or tabs?) over there and go work on it without getting it all tangled up with whatever I was working on earlier. :)