--===============2107759017==
Content-Type: multipart/signed;
  boundary="nextPart4320992.AyVFmmLImR";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart4320992.AyVFmmLImR
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable


>=20
> this is where having a list of possible triggers would be helpful. we cou=
ld
> 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)
>=20

+1 for brainstorming lists.
we did a bit of that on the train iirc, but I can't remember what we ended =
up=20
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:
>=20
> 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
>=20
> b) a central tool for defining activity triggers: probably something like
> the mouse actions configuration only a lot more complex
>=20
> 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 ;)
>=20
> 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.
>=20
> 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=
=20
application, but there's also a kcm you can go to to find all of them. it's=
=2E..=20
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 app=
s=20
to list their associations, instead of just having knetworkwhatever calling=
=20
suggestActivity(foo).

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

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

=2D-=20
Chani
http://chani.ca

--nextPart4320992.AyVFmmLImR
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEABECAAYFAk0V9lEACgkQeGbAwpIS3GyWJwCfZBeq+utK2zOFR8EMW+yPxSHy
YEsAn3gC1rh/3o33dpjHXcvRmnPZIwKI
=9UpB
-----END PGP SIGNATURE-----

--nextPart4320992.AyVFmmLImR--

--===============2107759017==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============2107759017==--