Automatic activity switching and other stuff -- thoughts for 4.7

[Chani]

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

+1 for brainstorming lists.
we did a bit of that on the train iirc, but I can't remember what we ended up 
with...

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

a thought: global keyboard shortcuts are hybrid, no? you can set them in an 
application, but there's also a kcm you can go to to find all of them. it's... 
not a UI I would suggest copying, but the general concept is sound.

but then, you'd need a global registry of associations, or a way to ask apps 
to list their associations, instead of just having knetworkwhatever calling 
suggestActivity(foo).

of course, if you want to go beyond triggering activities and allow other 
context-based effects (I dunno, power profile maybe, when I run mplayer?) then 
you'll want more of a global framework anyways, with context events and 
context... uh.. well, slots? I'm thinking of something vaguely similar to 
signals & slots here. but how do you present such power to the user in a non-
scary way?

the programming side could be very easy: you could just say "when you see a 
dbus signal like *this*, then call *that* dbus method". it's the UI that's 
hard...

-- 
Chani
http://chani.ca
-------------- 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/20101225/f5ffa110/attachment.sig