4.5 - Activities

[Aaron J. Seigo]

On March 10, 2010, Ivan Čukić wrote:
> > do you have any thoughts currently on where the classes in these libs
> > should end up, or do we need to start looking for homes for them?
> 
> We talked about it - Consumer would be best suited in kdelibs (maybe base

sorry, i wasn't clear enough. i meant where in kdelibs :)

> (maybe base until it gets stable enough)

sensible; we can keep it alongside Controller until it's ready; still, it begs 
the question of where to put it. with nepomuk?

> and the Controller would be in kdebase/runtime

i'd recommend workspace/libs/kworkspace/. runtime isn't for libs :)

> (iirc). As for the Info... I have no idea - it needs nepomuk, so the
> kdebase/runtime could also be a good fit.

runtime isn't for libs; and i think it does make sense next to Consumer. 
perhaps they could both go into kdelibs/nepomuk? would have to ask the 
nepomukians of course.

> > ActivityConsumer: how is the WId to be used (internally) in the document
> > registration methods? e.g. what will we do with this information?
> 
> This will allow us to have the document-centric activities rather than
> having them window based. So, the window will be shown for the activities
> that its documents are assigned to.

ah, so this is a way to expose the window<->document relationships; the API 
makes it sound like it's document related rather than window related. 
registerWindow perhaps?
 
> > what are there document registration methods in ActivityConsumer if
> > ActivityInfo also lets me do that?
> 
> Consumer ones are temporary - needed for kwin to be able to handle the
> window hiding. Temporary in a sense that if we don't have Nepomuk running,
> when you restart kde, it will forget the doc-activity links. Info provides
> the persistent links.

where does Info store this information? and shouldn't the persistence be an 
implementation detail that users of the classes shouldn't need to worry about? 
right now it's confusing as to which class to use given the duplication in 
API.
 
> > why can't i get ActivityInfo from from ActivityConsumer?
> 
> It could be added to API, but then we'd have to have both classes in the
> same kde package.

i think that's sensible...
 
> > should ActivityConsumer::activityName() go into ActivityInfo instead?
> > ditto for the activity name changed signal? or is ActivityInfo too
> > heavyweight
> 
> We need the name even w/o nepomuk - the Info class can be renamed to
> something like ExtraInfo but it is a bit ugly :)
> 
> The idea behind the naming was to look like QFile and QFileInfo.

ActivityConsumer doesn't represent a single Acitivity, it represents the 
collection of them, so the symmetry isn't exactly perfect there.
 
ActivityInfo does give information about an activity, though, and that seems 
quite sensible if the division of labor between the classes is Consumer for 
the collection and Info for individual activities.

> > how will location be associated with this concept?  it would be great to
> > be able to create locations, associated with triggers such as network
> > access attributes or physical (gps) locations, and the associate
> > activities with
> 
> > those. it might be nice to:
> The controller class is not meant to have all the logic of kwin/plasma that
> will deal with activities - just to provide them with a necessary
> info/management for activities.
> 
> The Location (amongst other things) is something that would be implemented
> in kwin (or plasma) itself.

the mechanism for tracking location will be in plasma-*, yes. but how will 
that work, exactly? will they have to go through Nepomuk directly? to me, the 
"where" is as central to the topic of Activities (as the word is used in this 
API) as the other resources that can be associated with them. i'd even go so 
far as to suggest that there should be a LocationResource in the ResourceType 
enumeration.
 
> From my point of view, an activity is only a small block of the whole
> context, there is no point in extending it to hold other context things.

not everything, no; but to make it possible to take location into 
consideration, i think we will end up making it happen somewhere. if not in 
these classes then in libraries in kdebase-workspace. it seems like a nice fit 
in ActivityInfo to me since Location is something we will quite obviously be 
needing to associate with Activities.

another API quesiton: QList < KUrl > associatedResources() const;

could that take an optional ResourceType arg so that one can pull out just 
resources of type Folder for instance? with an AllResources or AnyResources 
entry in the ResourceType enum set to 0xFFFF and that as the default arg ?

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