Automatic activity switching and other stuff -- thoughts for 4.7

[Aaron J. Seigo]

On Sunday, December 19, 2010, Ryan Rix wrote:
> Basically, I'm trying to answer a simple question: "what would cause a user
> to change what they are doing (their activity), 

i think the answers you provide below are pretty good for a start: location, 
calendar events .. i'd add network connections (e.g. if i pull up my VPN or 
tear it down, i may wish to switch activities), file/disk volume access ... 

i think we may end up with a system of events that are associated with a given 
activity, and when triggered, something that is up to the application or 
plasmoid implementing that trigger, can let us assist the user.

> and can we monitor those
> events to facilitate this change for them?":

i think so, yes. we shouldn't do it completely automatically, though, as that 
could easily result in work interuptions (unless we build some sort of 
sophisticated AI into it ;). but we can certainly facilitate it.

> Susan tags her workplace in Marble (or wherever) with the Nepomuk tag
> "work". The manager tracks Susan's current location via the Plasma
> geolocation dataengine and when it detects that Susan has arrived at work,
> changes the current activity to the activity associated with the "work"
> Nepomuk tag.
> 
> Terrance has different activities for each of his university courses. When
> he adds homework assignments or adds his class schedule to KOrganizer, he
> tags each event with the specified class, as well as asking the manager to
> switch to the associated activity when the event occurs. When the event
> occurs, the manager automatically switches to the activity associated with
> the Nepomuk tag Terrance has associated with the event.

.. or at the very least, the reminder notification could include a button that 
lets Terrance switch to the related activity.

put together with the Susan persona, perhaps it becomes useful to add a 
Service to the Activities DataEngine which uses API provided by 
kactivitymanagerd to hint that something has happened which may mean an 
activity switch is useful. then it could batch these up (in case several occur 
in a short timespan) and show a notification to the user of this, with a 
shortcut link/button to switch activities.

> There is also the choice of making something like this wider than this,
> controlling notifications status ("presentation mode"), etc... All of this
> falls in to this sort of "predict what the user wants to do" idea, but not
> so much with Activities as we know them.

how to associate this with activities remains to be seen, i think. one 
approach may be to have different panel configurations for different 
activities, with the notifications controls widget set up differently in the 
different activities.

this way, we don't need to add yet more config UI or think of every possible 
use case in advance.
 
> So, basically we end up with two things:
> * What would cause a user to change what they are doing?
> * How would they change what they are doing?
> 
> So, we end up with two lists of "things" -- plugins. What kind of API
> should these plugins be expected to have and what should they expect to be
> able to do?

do we need plugins, or should this just be mediated by plasmoids and 
applications which we already have, using a D-Bus api to enact the changes?

> Then comes the question of how to implement something like this.... Fun. Do
> we do it in kactivitymanagerd? In its own daemon? kded plugin?

for simplicity (and therefore reliability's sake) i think we should keep this 
all in one place; we've started with kactivitymanagerd, lets keep it there as 
well.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101221/5944e8d5/attachment.sig