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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
