Imagine if you will ... (ah, such a classic start! =) You are working on a work project involving Sarah and John and Marmaduke; you switch to working on your MySpace profile ... Let's call each state (the work project, MySpace fiddling) a "context" and changing between them a "context switch". What happens with the rest of the software running on your computer when you switch contexts? Answer: pretty much nothing. At least not automatically.
Compare with network connectivity. When you lose network connectivity, KMail stops fetching your mail, Kopete closes it's connections .. and when the network connectivity comes back, it all fires up again automatically. This is great because now the software is reacting to the environment it "lives" in.
Virtual desktops help somewhat as people can use them to aggregate related windows into contexts. But let's face it, there's only one Kopete window. Wouldn't it be great if you could tag Sarah, John and Marmaduke in your Jabber buddy's list with the "Workmates" tag? That way, when you switch back to the work project after you're done MySpacing, Kopete could re-arrange your buddy list to put those workmates at the top of your buddy list. The contacts widget in your panel or on your desktop could also switch the people they are showing.
To make software react to the user context in the environment they live in, we need a way to publish the user context and for the user to communicate "I am now doing $FOO" and "I am physically located in $BAR". This is similar to how Solid broadcasts changes in network status to KDE applications, but for user context.
In Plasma we have the idea of Activities. In 4.2 you can give your Activities names and Plasmoids can ask what the current Context is and do whatever they might want to do given that Context. Plasmoids are also notified via a Constraints update when the context changes.
For this to really fly, though, this contextual information needs to be accessible by software outside of Plasma itself. Nepomuk will be filling this role, and today a few of us huddled together on IRC for a quick meeting to wrap up a week's worth of discussion on the Nepomuk KDE mailing list about user context. Trüg, Hari and myself managed to align our schedules with one goal to achieve: come up with the initial ontology (fancy way of saying "organization definition", more or less) for context.
Over the next couple of days we'll be coding the start of a Nepomuk service for publishing and collecting information on the current context and I'll be hooking Plasma into it. This will allow other applications to see the various known Contexts and either automagically tag data with appropriate Contexts and/or let the user manually tag data. Going back to the Kopete and contacts widget example, once we can associated (or "tag") contacts in Akonadi with Contexts then Kopete and the contacts Plasmoid will be able to adapt in concert with Plasma.
We aren't going for auto-context switching yet, though we will be automating location changes and eventually hopefully be putting in some intelligence for detecting the user's current activity.
Fortunately for us, there's a lot of really good science that's already been done in this field for us to reflect upon and base our efforts on. We're also starting simple, though we intend to build as far as it makes sense to, as defined by real world user benefit. Which is to say that our odds of success are extremely high.
Once 4.2 is out, I'll be poking and prodding application developers to start making their applications context aware. (Application developers: you've been warned! ;) This won't make applications dependent on either Plasma or Nepomuk, they'll just work better when they are around. All that will be required is D-Bus, which is already a requirement for KDE 4 applications. But if Nepomuk is around then applications will be able to rifle through and get information on Contexts. Likewise, if Plasma is around then the user will be able to interact rather directly with the Context using their desktop shell.
As we develop the application API further, I'll blog more about it. Plasmoid developers can start having fun right now, though! =)