activities

[Chani]

hey guys :) this is a bit of a pre-emptive email... ramblurr was saying he'd 
email some questions, and yagami was having ideas in #kwin, and there's some 
possible confusion I'd like to address, so... well, here I am.

We seem to have two or three definitions of the word "activity" in kdebase now. 
Oops.
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.
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.

And so, confusion abounds! Oh joy :/
The first thing that comes to mind is, can we rename one of these concepts? 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.

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.


I wish the campkde videos were up so I could just point to that. (which 
reminds me - I owe someone a screencast!) but they're not, so I'll have to 
repeat a lot of that discussion here.

I want to explain a few things about my current view on activities...

One thing that is *very* important to me is that people must be able to 
understand activities enough to use them. A lot of people really don't get 
virtual desktops. I don't want to hold back those of us who do, but neither do 
i want to make a complex beast that scares off all but the geeks.

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.

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. Maaaybe 
we can allow more containments if we can do it nicely (someone with a small 
screen might want more widgets than he can fit) but let's start with it being 
1:1 with the physical space. (Side note- a scrollable containment, like 
newspaper, solves the more-space issue but breaks the scrollwheel-changes-
desktops misfeature.)

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.

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.

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 still want an 
option to unlink them though - there are plenty of people who have tons of 
stuff open and need the extra desktops even within one activity.

Here's where I run up against cruel reality, though. Virtual desktops have a 
lot of limitations most people don't notice. Some of them can be fixed, some 
miight be fixable or could be worked around, and some are just evil. 

I think it's *possible* to fake removing a virtual desktop that isn't the last 
one. I worry about small things like applications assuming they're on exactly 
one desktop.  I don't think it's possible to beat the composite monster, 
though. 
We've avoided it for desktopcontainment with the per-desktop-containment 
monstrosity. We've avoided it for the taskbar by not showing panels in effects. 
But how do we avoid it when apps like kmail start adapting their content to 
the current activity? I mean, maybe by then we'll get some new magic that uses 
more resources to render the apps separately for each activity, but... Eew.
And you still have the problem that if you add a 7th virtual desktop, desktops 
4 and 5 (or 3 and 6), which were once adjacent, are now further apart.

 So while in theory it makes sense to be able to merge vdesktops with 
activities, in reality it'd end up feeling awkward and hacky. :(

I've kinda hit a roadblock there, and haven't thought of a way around it.
I am *very* open to suggestions on how to make this easy to use without 
crippling it. :)

so, yeah, two open issues I'd like feedback on: 
how can we make activities simple and non-threatening to the new user?
what do we do about a dual-monitor computer having two activities 
(desktopcontainments) for each activity (in nepomuk)?

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100204/d48ffc64/attachment.sig