[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Automatic activity switching and other stuff -- thoughts for 4.7
From:       Chani <chanika () gmail ! com>
Date:       2010-12-25 13:48:58
Message-ID: 201012251449.06224.chanika () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

["signature.asc" (application/pgp-signature)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]