0

First things frist, forgive me for the cryptic subject, i'll try to explain it through an example

- My application is connected to KWindowSystem*::currentDesktopChanged(int) to poll for desktop changes (d'uh) but it is running on "Activity B" and everything goes as excepted and my application does... whatever is programmed to do.
- When i switch to "Activity A" and continue my work (), my application (which i left it on "Activity B") continues to receive events about desktop changes and does stuff (consuming resources) without purpose, because i am focused on "Activtiy A" and i cannot see what happens to "Activity B".
- So, in order to fix this i have to also poll for activity changes and change the state of my application - doesn't seem like a cool way for integration

So, what i am thinking** is to either to make automatically the correct propagation of the signals emitted depending the current activity or some other rule, for example KWin could detect (somehow) the activity which the application running connected to the signal,
or a simpler way and maybe more valid, provide overload signals/methods to specify the activity which an application is interested to.

* i am referring to KWin because that's where i stumbled uppon, maybe this characteristic is extended to other subsystems of the KDE API/Plasma
** at least for KWin

Comments are mostly welcomed,
Makis

p.s.: i am not completely aware of the implementation underlying KWin/KDE API/Plasma, maybe such features/thoughts are funny/obvious to developers

KActivitiies::Consumer has a signal when activity is changed.
void currentActivityChanged(const QString & id);

See:
http://api.kde.org/4.x-api/kdelibs-apid ... sumer.html