4.5 - Activities

[Ivan Čukić]

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

Well, these classes don't depend on nepomuk directly, that is, no nepomuk 
linking required. The Controller class is completely usable without it.

That's why I thought to place Info into kdebase - since kdebase provides 
nepomuk.

> registerDocumentWindow? :)

Better than the idea above and is ok as far as I'm concerned. :)

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

Ok, yes, the name is not that important to entry-level users. I'll move it.

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

That was the idea. But, we could just add which methods depend on nepomuk 
running in apidox.

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

Ok, so we're safe for now ;)

> going on. ditto perhaps for the Consumer class. something we can easily
> add as an optimization later as well, though. :)

Ok ;)


Cheerio,
Ivan
-- 
There are no such things as applied sciences, only applications of science.
  -- Louis Pasteur