Not much to add at the moment except this:
Currently, I see one of the main benefits of the Activity concept is
its malleability; that is, an Activity can be anything that makes
sense to the user, not just clear-cut divisions that can be easily
anticipated, such as "Work", "School", "Home", and "Lolcats binge at
02:00". While I'll grant that many good and common use-cases are
correllated with contextual cues or other things we can monitor, I
would submit that another question to be asked is "how can we add
useful automation and integration without hindering those in
unanticipated or 'non-traditional' scenarios?".
Just my $0.02
- Jeffery MacEachern
On Sun, Dec 19, 2010 at 00:49, Ryan Rix <r...@n.rix.si> wrote:
> Hey all,
>
> Long mail follows, sorry. Really only of interest to Chani, Aaron, Ivan and
> other activity folks... :)
>
> My goal was to bring this up for 4.6 but herp derp, I didn't, so here we go.
>
> I've been thinking a lot about how to give the Activity Manager a way to
> predict what a user would like to be doing at a certain time, based on
> external input, whether that's things like current GPS coordinates, what is
> scheduled in KOrganizer right now, etc. What follows is a braindump of crap
> I've been contemplating since before akademy, and it may well not make any
> sense.
>
> Basically, I'm trying to answer a simple question: "what would cause a user to
> change what they are doing (their activity), and can we monitor those events
> to facilitate this change for them?":
>
> Susan tags her workplace in Marble (or wherever) with the Nepomuk tag "work".
> The manager tracks Susan's current location via the Plasma geolocation
> dataengine and when it detects that Susan has arrived at work, changes the
> current activity to the activity associated with the "work" Nepomuk tag.
>
> Terrance has different activities for each of his university courses. When he
> adds homework assignments or adds his class schedule to KOrganizer, he tags
> each event with the specified class, as well as asking the manager to switch
> to the associated activity when the event occurs. When the event occurs, the
> manager automatically switches to the activity associated with the Nepomuk tag
> Terrance has associated with the event.
>
> etc... Makes sense, no? I have some other use cases, but I won't copypasta
> them here, for sanity's sake.
>
> There is also the choice of making something like this wider than this,
> controlling notifications status ("presentation mode"), etc... All of this
> falls in to this sort of "predict what the user wants to do" idea, but not so
> much with Activities as we know them.
>
> So, basically we end up with two things:
> * What would cause a user to change what they are doing?
> * How would they change what they are doing?
>
> So, we end up with two lists of "things" -- plugins. What kind of API should
> these plugins be expected to have and what should they expect to be able to
> do?
>
> Then comes the question of how to implement something like this.... Fun. Do we
> do it in kactivitymanagerd? In its own daemon? kded plugin?
>
> Next, where are we with the symbiosis between Nepomuk and the Activities
> infrastructure? Both of the usecases I described above use Nepomuk tags; they
> don't have to, but it's a decision we'd have to make before jumping in to
> writing some code like this -- do we use Nepomuk tags, or do we hardcode to
> Activities or whatever resource the plugin manipulates...?
>
> I'd like to start a dialog on this, and have something to show for 4.7 this
> time around. I've pissed around on this for nearly six months, and have a lot
> of nice ideas, just need to see how viable they are and how much they make
> sense.
>
> Lots of love,
> Ryan
> --
> Ryan Rix
> == http://hackersramblings.wordpress.com | http://rix.si/ ==
> == http://rix.si/page/contact/ if you need a word ==
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
