Automatic activity switching and other stuff -- thoughts for 4.7

[Aaron J. Seigo]

On Tuesday, February 1, 2011, todd rme wrote:
> either triggers or at least prompts a switch to a particular activity.

"triggers" is the operative word here; imho, kactivitymanagerd (KAMD) ought to 
accept requests for activity changes. the requests should probably include:

* the name of the activity to trigger
* a (translated) reason for the trigger
* the source of the trigger
* a weighting for the triggger?

KAMD should return an id to track the request with, and should batch the 
requests up to avoid flooding the user with a constant barrage.

the most recent (and/or most highly weighted?) trigger should be shown to the 
user via the notification system. the user could interact with the 
notification to approve the switch or ignore it.

if the application that requests the trigger changes its mind, it can cancel 
the trigger request with the id.

KAMD could perhaps even hold an internal "stack" of activities, allowing an 
app to trigger an activity and then "untrigger" it, returning the user to the 
previous activity. this could be useful for transient triggerings, such as the 
IM example.

Ivan: what do you think?

-- 
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/20110201/6fa44cc1/attachment-0001.sig