john.layt.net

This blog started at the last Akademy in Mechelen as some thoughts on the location aware desktop, what apps would benefit, and how we should be looking to use GeoClue to achieve this rather than rolling our own. But as I've written it I've been thinking about other concepts people have been discussing to the point that it has morphed into a disconnected ramble about the Reactive Desktop. It may not make a lot of sense, but one year later it's about time I posted it :-)

Just a quick note first about Geolocation services. At the moment Plasma has it's own Geolocation implementation. All credit to the guys who have been working on it, it filled a need and it is a fun itch to scratch and it is designed with a future switch in mind, but to me they do need to move to using GeoClue as a backend and to co-ordinate with Marble to move a Geolocation API lower in the stack (kdesupport?) where all apps can access it at all times, not just when using Plasma. A common low level Geolocation API with pluggable backends in the style of Solid and Phonon would become another Pillar Of KDE.

Right, onto the fuzzy blue-sky thinking.

A lot of the ideas I see floating around about the Location Aware Desktop are just at an application level, where an individual application responds to a change of location in an independent and un-coordinated manner, or actively queries the geolocation service when it needs to know the exact current location. These are ideas ranging from the panel clock automatically updating your timezone based on your location changing to konqi telling search engines where you are when searching for a restaurant, etc.

But at a higher level than that is the possibility of your entire desktop automatically adapting to your location when it changes. Imagine being at work with your laptop using your Plasma ‘Work’ Activity, you have open a bunch of work documents and apps, you’re connected to your work chat room, and Kontact is using your work groupware for e-mail and calender. You get to the end of the day, suspend your laptop and go home. On restarting your laptop at home, KDE detects that you’ve changed location to Home, so switches to your Plasma 'Home' Activity/Containment/Whatever with the NSFW wallpaper, saves your Work Session of open docs and apps for later, restores your last Home session with your Kate 'Hacking' session of several kdelibs source files you were working on, Konquorer tabs session with those dot and slashdot articles you were reading, starts Amarok playing with your chill-out playlist, logs you into #kde-devel, connects to MSN, and switches Kontact to your personal e-mail and calendar settings. When you go back to Work everything automatically switches back again.

While you could achieve that by the user going through every single app and individually configuring it to respond as required, that's just too much work. Why shouldn't we provide the user with a single place to configure this? To do that, I think you would need a broader, fuzzier concept of a 'Named Location' then an 'Exact Location' georeference at this moment in time. While you could then define Work as being within 1km of your office georef, Starbucks as being their ESSID, and Home as being anywhere else, you would then also have a way of manually switching locations when you have no Geolocation service available to automatically trigger the change or if you want to be in a different 'location' than where you are now (e.g. work from home).

And this is where my thinking gets a lot fuzzier as to how this would work in practice.

If you think about that a little more, we're no longer talking about being location aware, we're talking about application and desktop session or state management, with pre-defined application and desktop states being switched in response to an outside event. A Reactive Desktop and Applications.

OK, so we already have a lot of that with D-Bus and Solid events triggering application or desktop changes, but much of that is down to the app programmer to join up or the advanced user to script using D-Bus calls. Shouldn't we be letting our users decide what Events or combinations of Events trigger what Actions or state and session changes? If you look at PowerDevil, you have a great example of this sort of model. Shouldn't we have a more general model available where all apps and the desktop advertise a subset of the D-Bus Events they emit and what D-Bus or Session Management Actions they can have triggered, and then give our users a GUI to link these together? The switching to a Named Location state would then just be a special case of this. For example, if There's a cool app over in OSX that does something like this called Marco Polo, have a look it's quite cool.

There's a lot of stuff that would need to hapen first to lay the foundations here. Sorting out Geolocations services is a biggie, but other parts don't necessarily depend on that. Session management would obviously need to be greatly enhanced to enable you to save, edit and restore named desktop sessions, but also to have smart session switching, i.e. if an app is already running don’t close it and open it just change its state or config and geometry if possible. What else can people think of?

Some of the work needed as I see it:

• Fix Geoclue to be fully Gnome independent (Inge has a patch?)
• Add a Qt-only abstraction layer for Geolocation services (including Geoclue as one backend) to kdesupport
• Add a KDE wrapper for the Qt abstraction layer (if needed) into kdelibs
• Add a Named Location service to kdelibs or kdebase
• Add improvements to desktop session management in kdebase
• Add a KCM for Named Locations
• Add support to apps and desktop
• Apps to advertise their Events and Actions
• GUI to allow users to link Events and Actions

Obviously this isn’t all thought through yet, there’s a lot that would need to be sorted out with the architecture and interactions of the components, and many things I’ve probably misunderstood completely about the KDE / D-Bus architecture that may make some things impossible to do, but I thought I’d float the idea out there and see if we can get some discussion going.