ChaniBlog











{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. :)



TheBlackCat says:

“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.”

There is also the issue when new screens are added. What happens to laptop users who connect to different projectors with different resolutions? Are you left with an entirely blank activity whenever you connect a new projector? What about someone who has a laptop with different resolution screens at home and at work?



anon says:

@TheBlackCat
I think that would be a great use case of linking specific activities with Solid, e.g. if you know that you regularly use this and that specific beamer at this specific resolution also use this specific activity on it (e.g. for presentations). Similar stuff could be done with a docked versus a non-docked laptop etc.



TheBlackCat says:

@anon: that still wouldn’t solve the problem of ending up with an entirely blank activity whenever you plug into a monitor with a new resolution and/or new multi-monitor layout.



damian says:

What about the gui(plasma)? wouldn’t it be nice if each activity could have a independent number of desktops? and with this it would be a good idea to make something like a dashboard wich shows all activities created and the desktops it have, if it haves no desktops then do not load plasmoids in memory, 1 of the principal reasons I don’t use activities is that I think They will cost some resources as (I think) they are another set of plasmoids running on the bottom.
With this gui it should be really easy to add new activities and add more desktop to current activity.



Fri13 says:

“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).”

If you are cleaning up the code. There is one feature what I find nasty. The widget preview/tooltip balloon. You browse the list and you start dragging the widget from list to desktop and the preview/tooltip pop’s up right when you were dropping the widget. It really makes the widget explorer nasty when you can not just drop widget where you want but first you need place it somewhere, then re-move it. If just possible, check out how it actually works if there is something wrong on it.

“aw fuck, I completely forgot to bring that up at tokamak. grr.”

Young lady! Watch your tong ;-)

Just cant wait that we could have activities where every activity has own panels as well. Then we (at least me) could really make activities for good purpose for every task.

One graphic activity for photos where you have all the wanted apps placed to panel.

Other for video editing where you do not need than few other and you can place the panel automatically hide itself.

Third where you have few different panels.



Tom says:

I love the direction you are going. Being able to save Activities with windows is _HUGE_.
The Gnome guys think of something similar. They want to just save whole workspaces in Gnome-shell. So if you really need to change the session spec or a new spec maybe you should start a freedeskop discussion.

I saw your cool Camp talk. If you use lots of autohide panels you should also want mouse velocity:
http://forum.kde.org/brainstorm.php#idea86182_page1



mat69 says:

What about Gnome etc. apps?

I think this — which activity does x belong to etc. — all should be done with Nepomuk, as this later could be shared with other desktops.

Additionally imo apps should connect to the backend via a dbus interface, that could later become a fd.o standard.

Further looking at what is planned for Gnome 3 there are some similarities, so places to coordinate and discuss. Here are some great ideas that might see the light in Gnome 3. [1] Imo

[1] http://www.gnome.org/~seth/zuhanden-gnome3.pdf



Comments are closed.

et cetera
%d bloggers like this: