Re: Automatic activity switching and other stuff -- thoughts for 4.7
On Sunday 19 December 2010 08:49:34 Ryan Rix wrote: 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. [Finally catching up on my mail after holidays] Nice to see some thinking going on around this. I blogged about this sort of thing a while back as a generic concept of Events triggering Actions which you might be interested in reading (see http://www.layt.net/john/blog/odysseus/the_reactive_desktop and be sure to follow the link to Marco Polo) and with the new Activities stuff this is looking more achievable. I'm still looking into the geolocation side of things (hopefully have a state-of-the-onion email on that soon) but would be happy to kick ideas around sometime. John. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Automatic activity switching and other stuff -- thoughts for 4.7
On Sun, Dec 19, 2010 at 3:49 AM, 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 I think people should also be able to tag files and folders with activities, so opening that file or a file in a particular folders either triggers or at least prompts a switch to a particular activity. Tagging contacts with activities would probably also be useful, so if you start a chat with someone or open an attachment from someone it prompts you to change the activity (although these are definitely situations where it should NOT happen automatically). -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Automatic activity switching and other stuff -- thoughts for 4.7
On Tuesday, February 1, 2011, todd rme wrote: either triggers or at least prompts a switch to a particular activity. triggers is the operative word here; imho, kactivitymanagerd (KAMD) ought to accept requests for activity changes. the requests should probably include: * the name of the activity to trigger * a (translated) reason for the trigger * the source of the trigger * a weighting for the triggger? KAMD should return an id to track the request with, and should batch the requests up to avoid flooding the user with a constant barrage. the most recent (and/or most highly weighted?) trigger should be shown to the user via the notification system. the user could interact with the notification to approve the switch or ignore it. if the application that requests the trigger changes its mind, it can cancel the trigger request with the id. KAMD could perhaps even hold an internal stack of activities, allowing an app to trigger an activity and then untrigger it, returning the user to the previous activity. this could be useful for transient triggerings, such as the IM example. Ivan: what do you think? -- 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 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Automatic activity switching and other stuff -- thoughts for 4.7
On Wednesday, December 22, 2010, Ryan Rix wrote: Hello Aaron, On Tue 21 December 2010, plasma-devel@kde.org plasma-devel@kde.org wrote: On Sunday, December 19, 2010, Ryan Rix wrote: Basically, I'm trying to answer a simple question: what would cause a user to change what they are doing (their activity), i think the answers you provide below are pretty good for a start: location, calendar events .. i'd add network connections (e.g. if i pull up my VPN or tear it down, i may wish to switch activities), file/disk volume access ... When I get unblocked from Techbase i'm gonna start a usecases page somewhere... s,Techbase,community.kde.org, i think we may end up with a system of events that are associated with a given activity, and when triggered, something that is up to the application or plasmoid implementing that trigger, can let us assist the user. I really like the verbage behind triggered... I think I may steal it :) Plugging in projector triggers presentation activity... Connecting to work VPN triggers work activity... etc yes, this is the wording that chani and i came up with when discussing these things previously. i really think it works well, too. do we need plugins, or should this just be mediated by plasmoids and applications which we already have, using a D-Bus api to enact the changes? I don't know, would that mean that, say, Marble would have to be running 24/7 to monitor location? i don't think this would belong in marble; it sounds more like a job for something either baked right into plasma-desktop or as a plasmoid that offers a window onto location awareness. enumerating the different possible triggers, i think it becomes more apparent that nearly all have an existing always-running source. geolocation is an exception, so we'd need to find a home for that. I think that having the plugins outside of the application and outside of kactivitymanagerd would be a plus, given that I think it's a little tough to predict all the stuff thta users would probably end up doing, and this is where having a list of possible triggers would be helpful. we could start to detect patterns in them. the last time i did this, nearly every single trigger already had a long-running process associated with it, or the trigger made no sense unless the application was being used at the time anyways (e.g. amarok/banarang/etc having media triggered activities) The big thing I'm seeing with having the code stay in the applications/plasmoids is that I have to ask why have the activitymanager do anything at all besides switch an application in that case? Configs for this end up being spread out, etc... I need some time to think on it, but it just seems ... messy :( centralizing the configurations means knowing what the configuration means in the central location. example: for a network connection trigger, it has to have network connectivity awareness. to build that, we essentially end up repurposing some parts of the network manager plasmoid. in some cases, that will also mean synchronizing the plasmoid and the activity trigger plugins. and then we need to ask ourselves where is the best place to asy when i switch to this network, i want that activity to show up. there are two options that i can think of: a) connecting activities at the source of the context: so if i want to trigger an activity from networking, then i go to the networking tool b) a central tool for defining activity triggers: probably something like the mouse actions configuration only a lot more complex the benefit of (b) is that we then have one place to gain an overview on the configuration and you can see all ways that something can be configured. the downside is it may end up being quite complex, both code wise and UI wise. the power user in me likes this approach, though ;) the benefit of (a) is that it is contextual and easy to figure out how to set things up - when this thing changes, i want to trigger an activity change, too. for things like korganizer, i think this is significantly easier on the user and the developer. maybe there's some sort of hybrid approach between the two ... -- 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 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Automatic activity switching and other stuff -- thoughts for 4.7
On Sunday, December 19, 2010, Ryan Rix wrote: Basically, I'm trying to answer a simple question: what would cause a user to change what they are doing (their activity), i think the answers you provide below are pretty good for a start: location, calendar events .. i'd add network connections (e.g. if i pull up my VPN or tear it down, i may wish to switch activities), file/disk volume access ... i think we may end up with a system of events that are associated with a given activity, and when triggered, something that is up to the application or plasmoid implementing that trigger, can let us assist the user. and can we monitor those events to facilitate this change for them?: i think so, yes. we shouldn't do it completely automatically, though, as that could easily result in work interuptions (unless we build some sort of sophisticated AI into it ;). but we can certainly facilitate it. 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. .. or at the very least, the reminder notification could include a button that lets Terrance switch to the related activity. put together with the Susan persona, perhaps it becomes useful to add a Service to the Activities DataEngine which uses API provided by kactivitymanagerd to hint that something has happened which may mean an activity switch is useful. then it could batch these up (in case several occur in a short timespan) and show a notification to the user of this, with a shortcut link/button to switch activities. 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. how to associate this with activities remains to be seen, i think. one approach may be to have different panel configurations for different activities, with the notifications controls widget set up differently in the different activities. this way, we don't need to add yet more config UI or think of every possible use case in advance. 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? do we need plugins, or should this just be mediated by plasmoids and applications which we already have, using a D-Bus api to enact the changes? Then comes the question of how to implement something like this Fun. Do we do it in kactivitymanagerd? In its own daemon? kded plugin? for simplicity (and therefore reliability's sake) i think we should keep this all in one place; we've started with kactivitymanagerd, lets keep it there as well. -- 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 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Automatic activity switching and other stuff -- thoughts for 4.7
Hello Ivan, On Sun 19 December 2010, plasma-devel@kde.org plasma-devel@kde.org wrote: Hi, First of all, I'd avoid automatic switching unless explicitly requested by the user (aka, don't automatically switch to work-tagged activity when Alice arrives at work unless she somehow requested that she wants it to switch automatically in that case). Of course, none of this would be automatic, just as users aren't forced to create activities outside of the default one currently. :) Basically, as I see it, you'd provide a KCM accessible from the AM or somewhere else which would allow users to define actions like when X happens, do Y, where X and Y are the two types of plugins. Doing things like this without asking would just lead to wailing and gnashing of teeth, even from me ;) As for the other stuff - the tagging can go via Nepomuk - activities are (some basic info like icon and description) stored in it. The usage statistics will not be stored in Nepomuk, but most probably Zeitgeist. (nepomuk will hold summarized stats instead of each event). The tags on places, whatever and activities should (IMO) only be used for sorting the activities when presenting them to the user in the A.M. If you want auto-switching, I'd rather go (if you decide to use Nepomuk) for direct link between a place and an activity. Tags can be ambiguous. *nod* makes sense. That's all for this mail. Cheerio, Ivan -- 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
Re: Automatic activity switching and other stuff -- thoughts for 4.7
Hi, First of all, I'd avoid automatic switching unless explicitly requested by the user (aka, don't automatically switch to work-tagged activity when Alice arrives at work unless she somehow requested that she wants it to switch automatically in that case). As for the other stuff - the tagging can go via Nepomuk - activities are (some basic info like icon and description) stored in it. The usage statistics will not be stored in Nepomuk, but most probably Zeitgeist. (nepomuk will hold summarized stats instead of each event). The tags on places, whatever and activities should (IMO) only be used for sorting the activities when presenting them to the user in the A.M. If you want auto-switching, I'd rather go (if you decide to use Nepomuk) for direct link between a place and an activity. Tags can be ambiguous. That's all for this mail. Cheerio, Ivan -- A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort -- Herm Albright ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Automatic activity switching and other stuff -- thoughts for 4.7
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
