4.5 - Activities

[Aaron J. Seigo]

On March 10, 2010, Ivan Čukić wrote:
> > sorry, i wasn't clear enough. i meant where in kdelibs :)
> :
> :) I have no idea :)
> :
> > i'd recommend workspace/libs/kworkspace/. runtime isn't for libs :)
> 
> Ok :)
> 
> > 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.
> 
> I'm not really sure about that - things in nepomuk tend to be rather
> generic compared to this. This is something that uses nepomuk, and is not
> really part of it (we could live w/o nepomuk, and nepomuk will certainly
> exist w/o this :) )

honestly, the more i look at the API (and a bit at the implementation now), 
the less i'm convinced we -want- this work without nepomuk.

you are right that it's a bit over specific for nepomuk though... it could go 
as a separate library under kdelibs/nepomuk/; but having a whole new library 
for just a couple classes seems unfortunate.

libplasma is not the right spot for it either.

kdeui and even kio do not currently depend on nepomuk. a puzzler :) we should 
ask Sebastian Trueg for some guidance here i think.

> >From my POV, it should be provided alongside KApplication...
> >
> > 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?
> 
> It is intentional for two reasons:
>  - we want it to look document oriented
>  - more than one document can be in the same window - it would be strange
> to have to call registerWindow twice because we have two
> documents/resources in it.

or it could be:

registerWindow(WId, KUrl)
registerWindow(WId, KUrl::List)

and then it can be called once per window. the downside of this is that an app 
would have to iterate over all URLs every time one tab updates. hum.. ok, not 
great :)

*thinks*

registerDocumentWindow? :)

> > 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.
> 
> The idea is that Consumer class is an entry-level API - minimum for it to
> be able to *react* to activity events.
> 
> Info class, on the other hand, should be for the applications that really
> want to use activities (to be active participants instead of being only
> bystanders)

what would the definition be for each?

to me, adding resources to an activity is being a full participant.
changing internal state based on the activity id perhaps isn't.

if i want to show the name of the activity in the UI somewhere, then i don't 
think it's too much to ask me to create an ActivityInfo class.

> > 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.
> 
> The reason for this division was that Consumer is fully functional without
> nepomuk and Info is fully non-functional without it. I know it is not a

so this would be resolved by saying "this feature set requires nepomuk"?

> > 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
> 
> Locations will be resources like documents and everything else.

great :)

> > even go so far as to suggest that there should be a LocationResource in
> > the ResourceType enumeration.
> 
> Ok, good enough for me, but it can only be added when the Location gets its
> ontology (to be more precise, to get the type uri). Adding an item to an
> enum is not BIC, right?

it is, as long as it doesn't increase the size of the enum (e.g. we have 
32bits to work with there)


more code review bits:

static org::kde::nepomuk::services::NepomukActivitiesService * 
activitiesStore;

that looks concerning. imho it should be reference counted; might even make 
sense to have the ActivityInfo objects COW with a shared dptr like the Qt 
collection classes. QSharedData makes that easy enough. probably only worth it 
once we see common usage patterns leading to multiple Info objects in the same 
app for the same Info object, esp if there's client-side caching going on. 
ditto perhaps for the Consumer class. something we can easily add as an 
optimization later as well, though. :)

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