activities

[Chani]

On February 5, 2010 09:44:14 Aaron J. Seigo wrote:
> 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.

*you* have precisely one definition, in your head. not so in mine. :) and I 
guess I've spread the confusion a bit because of that.

> 
> > 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.

last time you were talking about context, you made it sound like it was all 
about the user's location, not what they were working on. perhaps I 
misinterpreted, though.

so: the Context holds associations that define what the user's working on: 
files, windows, etc. plus one or more Activities. the set of Activities that is 
tied to that Context gives the user an anchor to build the Context around.

does that sound right?


> 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.

yes, because I get the impression people have trouble grasping abstract, 
global things that have no visual representation.
I just want a way to get people using it easily, that's all.
at one point I considered having rows of desktops and each row being a 
different Context, but that was full of problems too. having a spatial 
representation for *both* vd's and context certainly won't work (no, not even 
if we go 3d, diego :)

> 
> >  So while in theory it makes sense to be able to merge vdesktops with
> > 
> > activities,
> 
> it doesn't make any sense in theory.

does too! :P


> 
> > 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.

mm, the UI for this is going to be important to get right. (part of the reason 
I haven't tried doing it myself ;)

> 
> > 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)

I wasn't aware there was any code for this in libplasma; I thought all we had 
was ivan's nepomuk stuff in playground (that's going to kdereview soon, 
riiight? ;)

> 
> * 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

separate out, as in give the Context a name instead of giving the Activity a 
name? or something else?

-- 
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/20100205/2a34d999/attachment.sig