Automatic activity switching and other stuff -- thoughts for 4.7

[Aaron J. Seigo]

On Wednesday, December 22, 2010, Ryan Rix wrote:
> 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...

s,Techbase,community.kde.org,
 
> > 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

yes, this is the wording that chani and i came up with when discussing these 
things previously. i really think it works well, too.
 
> > 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 don't think this would belong in marble; it sounds more like a job for 
something either baked right into plasma-desktop or as a plasmoid that offers 
a window onto location awareness.

enumerating the different possible triggers, i think it becomes more apparent 
that nearly all have an existing always-running source. geolocation is an 
exception, so we'd need to find a home for that.

> 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

this is where having a list of possible triggers would be helpful. we could 
start to detect patterns in them. the last time i did this, nearly every 
single trigger already had a long-running process associated with it, or the 
trigger made no sense unless the application was being used at the time 
anyways (e.g. amarok/banarang/etc having media triggered activities)
 
> 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 :(

centralizing the configurations means knowing what the configuration means in 
the central location. example: for a network connection trigger, it has to 
have network connectivity awareness. to build that, we essentially end up 
repurposing some parts of the network manager plasmoid. in some cases, that 
will also mean synchronizing the plasmoid and the activity trigger plugins.

and then we need to ask ourselves where is the best place to asy "when i 
switch to this network, i want that activity to show up".  there are two 
options that i can think of:

a) connecting activities at the source of the context: so if i want to trigger 
an activity from networking, then i go to the networking tool

b) a central tool for defining activity triggers: probably something like the 
mouse actions configuration only a lot more complex

the benefit of (b) is that we then have one place to gain an overview on the 
configuration and you can see all ways that something can be configured. the 
downside is it may end up being quite complex, both code wise and UI wise. the 
power user in me likes this approach, though ;)

the benefit of (a) is that it is contextual and easy to figure out how to set 
things up -> "when this thing changes, i want to trigger an activity change, 
too". for things like korganizer, i think this is significantly easier on the 
user and the developer.

maybe there's some sort of hybrid approach between the two ...

-- 
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/20101222/4c787c99/attachment.sig