System-wide Activities

[Aaron J. Seigo]

On Tuesday 19 August 2008, you wrote:
> Hi Aaron,
>
> I have to leave IRC for now. Hope to catch you sometime later
>
> But, to clarify things more, I have tried to explain my idea below:
> >> So, to be on the same side, I would like to clarify a few points...
> >> 1. Are we looking to create contexts that are shared between kde apps
> >> and plasma (via DBus)? Something like Global activities ( can we use
> >> the term "activities" for this or a different term ?)
> >
> > yes, the idea is to be able to sync this across the desktop. which is why
> > i'm using nepomuk here. the term being used in the code is "Context".
> > this came as a result of conversation with the Nepomuk team to suggested
> > this term instead.
>
> I would like to understand something here...
>
> We usually encounter two kinds of context:
> 1. static context in data (aka nepomuk tags) : these are a cool way to
> sync the whole desktop with a common ground and would be a great way
> to specify "static" activity related items like contacts, resources,
> files, etc
> 2. dynamic context (that would apply to apps and widgets) - when an
> activity is associated with a virtual desktop, all the items within
> the virtual desktop suddenly get a context (i.e. the current activity
> assigned). So, they change their display to focus on that context

hm. maybe i'm not explaining myself correctly here. we're actually talking the 
about the same thing here:

there is a dynamic context, and i am using nepomuk to store the various known 
contexts as well as mark which one is the currently active context.

nepomuk is shared storage and a way to connect data to those contexts; plasma 
is a way to manage the contexts (though not necessarily all the related data) 
and define which is the current one.

> So, you see, when an activity is assigned to a virtual desktop, all
> its constituents adjust themselves to help the user to focus on items
> relating to current activity

that's the idea, yes.

> >> 2. Shouldn't context be more granular? like activities, location, user
> >> modes, etc. Different widgets and apps might be interested in
> >> different things.
> >
> > i don't really get what you mean by "user modes" (that's what
> > activities/contexts are, afaiu), though location should certainly be
> > added to it.
>
> "user modes", as I see them, are a super-set of "user profiles". In
> addition to changing certain visuals like cursors, etc, they add a
> semantic dimension to user status.
> E.g. when I set my user-mode to "Do Presentation", my cursor
> automatically changes to an appropriate one easy for highlighting; Any
> system notifications are not immediately shown and are logged for
> later perusal. etc etc

i honestly doubt this will get widely used as it would require a lot of work 
on the user's side to configure things, such as the cursors, and require a lot 
of extra complexity in the configuration UI for such things.

> >From a popular quote, "important aspects of context are where you are,
>
> what you are doing, who you are with, and what resources are nearby"
>
> where are you - location

geo location; can be added to Plasma::Context, has nothing to do with the 
storage/creation/setting of activity.

> what are you doing - activity

right...

> who you are with - nearby people

this is presence info, and something that should be handled via decibel

> resources nearby - any devices attached, or network connections available,
> etc

this is the role of Solid

> So, if we can fully leverage all the above as "context" then that
> would result in a very smart desktop that can reconfigure itself when
> needed.I think this is needed more now, when things are becoming more
> mobile!

yes, that is what we are working towards. the four items you mentioned above

> Hope I made my point a bit more clear. If you want I can write a short
> proposal on what I would love to see implemented ;)

better, i think, would be to just start working on implementing the 
infrastructure bits that are missing (e.g. the geoclue integration) and then 
start working outwards from there, bit by bit. perhaps first focus on things 
like contacts<->context associations, since that's an obvious (and obviously 
useful) thing.

btw, let's keep this conversation on plasma-devel at kde.org so everyone can stay 
involved =)

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20080819/8f809c1d/attachment.sig