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