Automatic activity switching and other stuff -- thoughts for 4.7

[Ryan Rix]

Hello Aaron,

On Tue 21 December 2010, plasma-devel at kde.org <plasma-devel at kde.org> wrote:
> 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 ...

When I get unblocked from Techbase i'm gonna start a usecases page 
somewhere...

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

I really like the verbage behind triggered... I think I may steal it :)

"Plugging in projector triggers presentation activity"... 
"Connecting to work VPN triggers work activity"... etc

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

Instead of "just switching", to show a Notification (as you say down below?)? 
Or does that go back to Ivan's "don't switch unless the user requests it"?

The former seems more reasonable the more that I think about it, yes... I'll 
let it sink in for a while.

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

*nod*, quite possibly, yes. :)

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

That can Be Added Later™ and is more Chani's field than mine, anyways :P

> > 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?

I don't know, would that mean that, say, Marble would have to be running 24/7 
to monitor location? 

I think that having the plugins outside of the application and outside of 
kactivitymanagerd would be a plus, given that I think it's a little tough to 
predict all the stuff thta users would probably end up doing, and having some 
plugins infra to extend this would be nice. ++nice if we make it accessible 
through python or $interpereted bindings (Download New Activity Triggers, 
anyone?) but Iunno. I'll leave it out for now, I guess, we can come back to it 
later, if we decide to.

The big thing I'm seeing with having the code stay in the 
applications/plasmoids is that I have to ask "why have the activitymanager do 
anything at all besides switch an application" in that case? Configs for this 
end up being spread out, etc... I need some time to think on it, but it just 
seems ... messy :(

> i think we should keep
> this all in one place; we've started with kactivitymanagerd, lets keep it
> there as well.

*nod*, my thoughts.

R

--
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word         ==