4.5 - Activities

[Ivan Čukić]

On Wednesday 10 March 2010 Aaron J. Seigo wrote:
> On March 8, 2010, Ivan Čukić wrote:
> > - libs/consumer
> > ActivityConsumer - basic access to kded service for normal apps
> > ActivityInfo - access to extra info provided by nepomuk - this one will
> > probably get expanded in future.
> > 
> > - libs/controller
> > ActivityController class - access to kded service for activity managers
> > (kwin, plasma) - will probably be changed/extended to suit Chani's
> > (kwin's) needs.

> 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 
until it gets stable enough) and the Controller would be in kdebase/runtime 
(iirc). As for the Info... I have no idea - it needs nepomuk, so the 
kdebase/runtime could also be a good fit.

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

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

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

> should ActivityConsumer::currentActivity() be currentActivityId()?
> availableActivities() -> listActivityIds() to be consistent with our other

OK

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

> activitiesForDocument -> activitiesByIdForDocument? what about the other
> kinds of resources that ActivityInfo lets me get to?

Yes, that will have to be changed - the activitiesForDocument will become 
activitiesForResource

> 
> 
> 
> on the controller side:
> 
> currentActivity -> currentActivityId()?
> 
> availableActivities ... why wouldn't the controller use ActivityConsumer
> for this? same for currentActivity, for that matter.

I just didn't want for controller application to be /obligated/ to use two 
different classes for accessing the activities.

> perhaps ActivityController could be a subclass of ActivityConsumer, even?
+1 this can be a way

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

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.


Cheerio,
Ivan
-- 
Sanity is the trademark of a weak mind.
    -- Mark Harrold