Activity-specific vs. global applications, foreground vs. background applications,

Thomas Pfeiffer colomar at autistici.org
Fri Sep 23 12:03:32 UTC 2011


Hi all,
this mail actually covers to distinct - though related - topics.

First, activity-specific vs. global applications.
Fania and me (and maybe all of us, don't remember exactly) have talked about 
this during the sprint: Although only showing applications opened in the 
current activity in the task switcher does make sense in general, there might 
be some applications users want to see in more than one activity, like an IM 
client for example: Users might want to chat with someone in parallel to what 
they do, no matter what activity they are in. And having to switch back and 
forth between their current activity and the one the IM client was started 
from would be pretty cumbersome. Kopete for example always pops up chat 
windows on the current desktop when a message comes in, no matter where the 
main window is, for a reason (even though this might not be the most elegant 
way to solve the problem).
Therefore I think we have to find a way to distinguish between activity-
specific and "multi-actvitity" applications. Two problems come with this, 
though:
1. How do we make this distinction clear to the user? It must be clear to them 
_why_ some applications are shown independently from the current activity 
whereas others disappear after switching. I'd suggest we should seperate them 
visually on the task switcher (and probably group the multi-activity apps 
together with the homescreen thumbnail).
2. Users might want to see an application in some activities but not in others 
(e.g. someone has started his chat client from a private activity to chat with 
private contacts and does not want to be bothered with it while on a work-
related activity, bot does want to see it in other private activities. And 
maybe she starts another work-related instance of the IM client from a work-
related activity (and of course only sees work-related contacts in there ;) )
One solution for this might be: Show the application only on activities it is 
connected to (as an app resource). This would solve that problem, but I'm not 
sure if this concept is understandable and not annoying. If we use this 
method, though, I don't think we need to do what I suggested in 1.) because it 
might be clear to users that the applications shows up in an activity it is 
connected to but not in others.
I think we need to experiment with that. But having all applications strictly 
limited to the activity they were launched from should not be the way imho.

The secend topic is a more technical one: Foreground vs. background 
applications. I don't know the technical details, but it seems to me that 
applications in KDE usually don't vary too much in resource consumption 
whether they are actually shown on the screen or resting eg. on another 
desktop.
This can be very problematic on mobile devices with their limited resources. 
If we want applications to be activity-specific, many open applications may 
accumulate in memory as users start applications, switch to different 
activities and just forget about them until they return to that activity. 
Although this is exactly what we want (when I switch activities, I don't want 
to bother with apps related to them anyway, but when I switch back, I want it 
to be still open).
So is there already a concept of "paused" or "backgrounded" applications like 
iOS or Android has for Plasma Active? If so and it works well, everything is 
okay. If not, I'd say we need that real soon.

Looking forward to your comments on these,
Thomas




More information about the Active mailing list