activities

[Aaron J. Seigo]

On February 4, 2010, Chani wrote:
> We seem to have two or three definitions of the word "activity" in kdebase
> now. Oops.

we have precisely one definition.

> First, there's the original: desktop containments.
> Second, there's the nepomuk activities: they're UIDs that can have an
> associated name, and then other arbitrary things can be associated with
> them.

these are the same thing. 

there is the idea of Context. Context includes the concept of an Activity 
which is primarily a temporal concept. a desktop view in plasma-desktop is 
intended to reflect the Activity that is current in Context.

> Third, there's my "everything you need for what you're working on"
> plan, which will pull in kwin and new session stuff and applications, and
> *probably* will be tied to a set of containments (one containment, for
> those of us with one screen). Hopefully this will merge with nepomuk's
> activity stuff, so we can count only two definitions of "activity" in kde.

no hopefully about it: obviously this would merge with the Context. there's no 
point in doing it otherwise.

which means we have one meaning, one implementation and one place of storage. 
the only "multiple" here is that it gets reflected in multiple places and that 
we will end up needing a way to coordinate these multiple reflections.
 
> The first thing that comes to mind is, can we rename one of these concepts?

this is unnecessary due to the above.

> We have activities "the group of widgets on your desktop" and activities
> "the windows/files/whatever for your current project". Can someone come up
> with a different name for one? I'd take Context but aaron's already
> defined that to mean activity+geolocation.

Context is precisely what it's supposed to be.
 
> For the rest of this i'll just say "containment" instead of
> plasma-activity, and when i say "activity" i mean the nepomuk/kwin/etc
> thing.

please don't confuse matters even further. there's a reason they are called 
Containment in the code, that Context is a separate class and that we only 
refer to Activity in the UI.

> quick review for anyone who's forgotten: I want to be able to associate
> windows with activities so that they're only shown on those activities
> (yes, plural, not like virtual desktops where it's all or one). later I
> want applications to adapt to the current activity (example: filedialog
> showing special Places for that activity), I want to be able to
> save/restore the whole activity - both containment(s) and windows - and
> then someday I want to start automatically associating new windows with
> activities based on stuff like nepomuk tags on the file that's being
> opened.

right, this has been the goal for the last ~3 years.
 
> Anyways, to help people get it, I think it will be beneficial to tie the
> activity to N containments, where N is the number of physical screens.

this is a requirement, actually. and why Containments can share Contexts.

> Having this activity-containment tie gives users an anchor. The activity
> isn't a completely abstract concept then; it's got a more physical
> representation. And if users are smart they'll give each activity its own
> wallpaper; having a pretty picture makes it far easier to tell them apart
> and remember where you are.

right.

> Now the part aaron's not going to like . ;) I think that the spatial layout
> of virtual desktops, and the pretty composite effects showing that layout,
> really help users grasp the concept better. I think that for most people,
> it makes sense to start out with the same spatial stuff to help people not
> feel lost.

sure.
 
> I'm not talking about something added on here - that'd be confusing, the
> way the zui and desktopgrid are confusing. I'm talking about a merge.
> Tying activities to virtual desktops, a strict 1:1 relationship.  I'd

at which point you may as well just stop considering tying applications into 
Context or anything else that isn't strictly spatial. my guess is that people 
will be rather confused as to why when they go to check their email everything 
else changes (due to the Activity/Context being changed) or why they can't 
check their email after the Context changes unless they add EMail to every 
Activity.

Context is specific to the person in that it is the person's current internal 
state which defines which Context (if any) is applicable. it has nothing to do 
with the computer. in fact, Context is a way to make the computer reflect the 
person. you're suggesting we make the computer define the Context through a 
visual representation, when really it's something that should be global to the 
computer at any given moment.

> effects. But how do we avoid it when apps like kmail start adapting their
> content to the current activity? 

but not trying to tie it to the concept of virtual desktops.

>  So while in theory it makes sense to be able to merge vdesktops with
> activities, 

it doesn't make any sense in theory.

> in reality it'd end up feeling awkward and hacky. :(

and that should be a clue.
 
> how can we make activities simple and non-threatening to the new user?

by making them easy to define and switch between. the defining bit is actually 
going to be the hardest. if we wish to tackle an interesting set of unanswered 
problems, that's probably where to head.

> what do we do about a dual-monitor computer having two activities
> (desktopcontainments) for each activity (in nepomuk)?

Context can be shared between Containments.

what needs to be done in this case is to make it so that:

* Context objects are able to be managed by the appliction (e.g. plasma-
desktop). right now they are a detail hidden in libplasma (which gives us 
flexibility going forward since they aren't really exposed in any meaningful 
way)

* plasma-desktop ensures that one and only one Context object is active at a 
time and is associated with all visible Containments

* separate out the Activity Name setting from the containment type switcher in 
the config UI; it does not make sense to have there as long as we have PVDA 
and multi-screen support. while PVDA could be turfed, we'll never get away 
from multi-screen support

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks