Re: [nepomuk-kde] Plasma activities and Nepomuk
Hi Leo, On Sun, Aug 9, 2009 at 12:02 AM, Leo Sauermannleo.sauerm...@dfki.de wrote: I think you guys still did not check out the links I have posted, because if you did, you would be talking about UserWorkContextThreads which are the high-level user activity you are talking about. Actually I had read them completely! Last time, me and Sebastian Trüg had agreed that ContextThreads (given in that onto) are more aligned with tracking NOPs (medium and long term), and are not currently suited to what we need right now! I am sure we would be using most of it at later phases when we bring NOPs into the picture, but for now we have much simpler needs ;) Cheers, Hari ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [nepomuk-kde] Plasma activities and Nepomuk
On Sun, Aug 9, 2009 at 1:09 PM, Marco Martinnotm...@gmail.com wrote: there was also the idea of plasmoids changing their contents on activity change,that now i suppose would be from activity type change... (and the activity name being just a mnrmonic name for the user) Activity name is unique for each activity and activity type is shared between related activities (as there can be different activities with the same type). So, I would say that plasmoids might use either activity name or activity type depending upon the plasmoid's purpose... - Listing plasmoids - which just list things specific to the acitvity - like contacts, resources associated with the activity, would filter using the activity name - Communication plasmoids - like Mail, etc would depend upon activity type We would have to come up with a list of scenarios, plasmoids and their usage to conclusively answer this ;) Cheers, Hari ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [nepomuk-kde] Plasma activities and Nepomuk
On Sat, Aug 8, 2009 at 11:22 AM, Ivan Čukićivan.cukic+...@gmail.com wrote: what would you do with an activity type that you couldn't do with just the activity name? The type could be used by the /activity switching/ plasmoid - to group the activites, or to show only a certain type of activity... Activity Type can be used to covey a concrete semantic meaning about what the activity actually is; While 'activity name' can be used to restrict display to information pertaining to the current activity (like emails, people, apps, etc related to that activity), activity type gives another dimension to it which enables certain display changes to happen by default (i.e some defaults can be shared by all your 'official work'-related activities), without any customisation needed from the user. What comes immediately to my mind is... Suppose we have three activities: 1. P's Birthday card - a personal activity in which you are designing a card for your child 2. Plasma Netbook - a community development activity in which you are developing the plasma netbook version 3. Acme Business Project - an official work which you would need serious concentration and should not have any distractions There is a slight difference in the way the desktop can adjust itself for each activity type. Suppose you are doing... Activity 1: When an email or IM comes from any of your friends, fellow OSS developers or anyone, you are notified immediately. The contact plasmoid on the desktop shows your recent or fav. contacts. Kickoff/Lancelot/Raptor shows all apps Activity 2: In this, messages from your fellow developers take precedence and are notified immediately, but emails from other friends can also be indicated in a non-intrusive way, by just showing an unread count. The contacts plasmoid on the desktop shows just the developers. Kickoff/Lancelot/Raptor displays just the apps you need for development work (by default, without any customisation from user; but allows for user customisation, if needed) Activity 3: When you switch to this activity, the system sets your status as busy and queues any messages (other than from your company colleges, if configured) until you have finished with your activity. As you should not be disturbed, the system hides any non-urgent notifications till you finish or switch the activity. Kickoff/Lancelot/Raptor displays just the apps you need for productivity work (by default, without any customisation from user; but allows for user customisation, if needed) Hope I have made my point clear ;) Cheers, Hari ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Fwd: [nepomuk-kde] Plasma activities and Nepomuk
Sorry, forgot to CC nepomuk-kde ml ;( On Sat, Aug 8, 2009 at 11:22 AM, Ivan Čukićivan.cukic+...@gmail.com wrote: what would you do with an activity type that you couldn't do with just the activity name? The type could be used by the /activity switching/ plasmoid - to group the activites, or to show only a certain type of activity... Activity Type can be used to covey a concrete semantic meaning about what the activity actually is; While 'activity name' can be used to restrict display to information pertaining to the current activity (like emails, people, apps, etc related to that activity), activity type gives another dimension to it which enables certain display changes to happen by default (i.e some defaults can be shared by all your 'official work'-related activities), without any customisation needed from the user. What comes immediately to my mind is... Suppose we have three activities: 1. P's Birthday card - a personal activity in which you are designing a card for your child 2. Plasma Netbook - a community development activity in which you are developing the plasma netbook version 3. Acme Business Project - an official work which you would need serious concentration and should not have any distractions There is a slight difference in the way the desktop can adjust itself for each activity type. Suppose you are doing... Activity 1: When an email or IM comes from any of your friends, fellow OSS developers or anyone, you are notified immediately. The contact plasmoid on the desktop shows your recent or fav. contacts. Kickoff/Lancelot/Raptor shows all apps Activity 2: In this, messages from your fellow developers take precedence and are notified immediately, but emails from other friends can also be indicated in a non-intrusive way, by just showing an unread count. The contacts plasmoid on the desktop shows just the developers. Kickoff/Lancelot/Raptor displays just the apps you need for development work (by default, without any customisation from user; but allows for user customisation, if needed) Activity 3: When you switch to this activity, the system sets your status as busy and queues any messages (other than from your company colleges, if configured) until you have finished with your activity. As you should not be disturbed, the system hides any non-urgent notifications till you finish or switch the activity. Kickoff/Lancelot/Raptor displays just the apps you need for productivity work (by default, without any customisation from user; but allows for user customisation, if needed) Hope I have made my point clear ;) Cheers, Hari ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [nepomuk-kde] Plasma activities and Nepomuk
On Sat, Aug 8, 2009 at 2:47 PM, Ivan Čukićivan.cukic+...@gmail.com wrote: Although this would be perfect to have, I'm concerned about the interface to it. The users are already confused with activities, what would happen if we introduced activity types (as configurable) as well? I think the main reason casual users are confused is that they are not able to differentiate virtual desktops with plasma activities. When you see reviews of plasma activities, they inadvertently compare virtual desktops to plasma activities. Ideally they expect those to be coupled together by default...That is how casual users look at it normally... I read somewhere that users adjust themselves to something different as long as it feels different. And, they panic when they see something similar to what they had known already, but it does something entirely different. That is because when they see something similar they expect to use it like they have used before, but as it performs a different function, they just become confused and start to panic... I don't know why I am bringing this now ! But, anyway ... I'd rather have a 'create a new activity based on the current' than making a template system like that. Exactly, the normal users will not be required to temper with the above template features. What we can do is, have an Activities tab in Kickoff/Lancelot/Raptor which would list all the current Activity templates as icons with description. When the user clicks on it, we can start an activity based on that template ;) Cheers, Hari ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [nepomuk-kde] Plasma activities and Nepomuk
Hi Leo, On Sat, Aug 8, 2009 at 5:52 PM, Leo Sauermannleo.sauerm...@dfki.de wrote: a completly working implementation with applications on top (such as clicked-link history, etc, ...) was done open source complete with ontologies and algorithms: http://usercontext.opendfki.de/ http://lists.opendfki.de/cgi-bin/mailman/listinfo/usercontext http://dev.nepomuk.semanticdesktop.org/wiki/UserWorkContext I think this thread is currently reinventing this. Leo, the contexts discussed there are more in line with 'Gnome Zeitgeist', where the actual user operations (called NOPs in nepomuk) done in individual applications are observed and the user context is guessed. But, as per what we have agreed earlier, for the first phase of implementation, we are looking at a more higher-level 'User Activity' which is explicitly invoked by the user, which just remembers the apps or applets the user might use to do his specific activity. I am sure we will cover NOPs at a later phase and use UserContext onto for it, but for a start, let us just stick to ActivityContext at a higher level. I think the plasma team is also thinking in those lines ;) Cheers, Hari ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [nepomuk-kde] Plasma activities and Nepomuk
Hi all, 2009/8/4 Ivan Čukić ivan.cukic+...@gmail.com: The reason I started this topic now is that we are approaching Tokamak 3 (meeting of Plasma developers / hackaton) and I intend to work on d-bus interface and the nepomuk stuff. Ivan, I would like to clear up something here: I understand that when you are saying context, you mean the Activities the user is doing. But, in true semantic sense, there can be a lot of other contexts also. So, to keep things clear for both the sides, I would request to use the word 'ActivityContext' whenever 'Activities' are intended ;) And, as per our discussions in nepomuk, we haven't yet finalised how ActivityContext is to be represented. Previously we were thinking of using a dedicated ontology for it. But, now we are thinking more in the lines of extending the PIMO to use it. Nothing is final yet... As Sebastian Kügler says, ActivityContext could be minimally represented as a user-given name, a QString. But, I think we might also need a activity type (personal work, official work, code development, leisure, academic work, community work, anonymous, etc). If there is no type, how will you differentiate between the different activities to show diff things as in the usecases you have given... Use-cases: - When John switches to the /work/ activity, he wants the favourites in Kickoff/KMenu/Lancelot/Raptor/... to be the applications related to work. - When Eric switches to the /internet/ activity, he wants the file open/save dialogue to contain 'Downloads', 'Pictures' etc. folders in the places side- panel. - Terry starts KDevelop to work on his project. The rest of the environment switches to /kde development/ activity. These usecases perfectly align with what we have in mind... Now, all we have to do is to brainstorm on the types of activities that might be applicable ;) On Tue, Aug 4, 2009 at 2:55 AM, Leo Sauermannleo.sauerm...@dfki.de wrote: here is the open source reference implementation, ontologies, documentation, and community site: http://usercontext.opendfki.de/ http://lists.opendfki.de/cgi-bin/mailman/listinfo/usercontext http://dev.nepomuk.semanticdesktop.org/wiki/UserWorkContext Leo, the contexts discussed there are more in line with 'Gnome Zeitgeist', where the actual user operations (called NOPs in nepomuk) are tracked. But, as per what we have agreed earlier, for the first phase of implementation, we are looking at a more higher-level 'User Activity', which spans multiple apps or applets the user might use to do his specific activity. I am sure we will cover NOPs at a later phase, but for a start, let us just stick to ActivityContext at a higher level. I think the plasma team is also thinking in those lines ;) On Sun, Aug 2, 2009 at 4:31 AM, Sebastian Küglerse...@kde.org wrote: the big requirements we have in plasma is the ability to have a named context that can be associated with locations, people, documents ... projets, tasks, time periods, ... :) All these are planned to be included in ActivityContext. But, as we would like to evolve the ontology over time with real-life usage (instead of long discussions over the actual structure of the ontology), we would like to start with the bare minimum required to represent an ActivityContext and actually implement it before we start adding other things... So, here is what might be the minimum required to represent ActivityContext: - Activity name (given by user) - Activity Type Anything else needed ? PS: I am now in both Plasma and Nepomuk-kde mailing lists. So, no need to keep CCing me ;) Cheers, Hari ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: System-wide Activities
Aaron J. Seigo you probably want to look at Plasma::Context in kdebase/workspace/libs/plasms/context.h as it already does this (though right now most of the methods are just stubs); i'll be working on this (and the n810 shell) for the rest of this week. Cool... Had a look at it just now... Looks like a great start. *rubs hands and sits straight* Btw, I just read your blog entry (http://aseigo.blogspot.com/2008/08/sitting-in-lhr.html) where you also talk about contexts, but more limited to widgets and just plasma activity.. So, to be on the same side, I would like to clarify a few points... 1. Are we looking to create contexts that are shared between kde apps and plasma (via DBus)? Something like Global activities ( can we use the term activities for this or a different term ?) 2. Shouldn't context be more granular? like activities, location, user modes, etc. Different widgets and apps might be interested in different things. We need to nail down the difference between project, activity and context, please...for a more clear understanding i don't have plans to add support for geographical awareness (e.g. geoclue) to Context yet, but that's where it does belong. perhaps you'd be interested in working on that bit? Sure! Once I get a better idea of what is needed, I would jump in ! If you would like to discuss this more on IRC, please let me know. FYI, I live in India (so, my timezone is GMT + 5:30 hrs). But, let me know your convenient time, i will try to make it ! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
System-wide activities
Hi, Note: I am just forwarding mails that I had accidentally *switched* to discussing with aseigo instead of on the plasma-devel . I will remember to keep further conversions on the plasma-devel-list ;) But, not sure why the last mail i forward to the list came out as blank. So, doing it again... From a popular quote, important aspects of context are where you are, what you are doing, who you are with, and what resources are nearby where are you - location what are you doing - activity who you are with - nearby people resources nearby - any devices attached, or network connections available, etc So, if we can fully leverage all the above as context then that would result in a very smart desktop that can reconfigure itself when needed.I think this is needed more now, when things are becoming more mobile! Hope I made my point a bit more clear. If you want I can write a short proposal on what I would love to see implemented ;) Regards, Hari krishna Anandhan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
System-wide Activities
Hello all, I am a newbie here ( though long-time lurker). This is my first journey to make myself useful to KDE. I will start with a *dream* and then the implementation (Hope it doesn't clash with plasma's vision; or better if it is complementary to it, it would be great! ) To start with, please ignore what is called as plasma activity in current KDE version and read this ;) I know, it clashes with the current name of activity in plasma, but I couldn't find another good term that conveys the exact meaning… If needed we can rename it later... Now, KDreams of system-wide activities … Term explanation: Activities are a more casual term for projects. Imagine a case where projects / activities are handled at system level and applies to both plasma and KDE applications equally. Now that plasma and Kwin (virtual desktop) interaction is planned, this could be achieved by associating an activity with a desktop, and storing that information in a shared space. Vision: When I create a new activity, applications automatically prepare themselves for the new activity. Dolphin creates a new folder for storing activity resource files. Kmail creates a mail folder to store mails corresponding to the activity. Korganiser creates a tag that can be assigned to specific contacts to associate them with the activity. And, when I switch to a particular activity, everything changes as well. Plasma widgets filter content appropriately. Applications focus their context exclusively on the activity-related items, including changing the open/save dialog to default to the folder which corresponds to the activity resources (So that needed files are always just a click away!) Now, suppose I have tons of files for the current activity and I couldn't find the file needed. I just set the global filter as last 90 days. Every app filters their content to show only those items that fall in that date range. Dolphins only shows files modified within last 90 days. Kmail filters mails accordingly, etc Life is cool and world will be a better place ;) Implementation: Now, back to reality ! Bringing context-awareness to KDE !! I am currently working on a user context framework (I badly need a cool codename. Any ideas? ), which supports the different contexts that smart applications might need to be aware of, namely - Activities - Locations - User modes - Global search filter - Sensors (if needed) First things first, why a new framework? - Activities - for context to should be shared between apps and widgets - Location - as a wrapper for geoClue - User modes - Though IM presence can quality already, this adds a semantic dimension to it - Global search filter - for cases where search with keywords is not enough - Sensors - for any future or device-dependant contexts It would also serve as a single point of operation for all applications that need context-awareness, without needing to understand all the underlying mechanisms ... Hope it makes sense. So, lets get moving ;) For starters, I would like to start the implementation with system-wide activities to nail down the architecture of the framework first , as I find my way around KDE!!! (remember I am new to KDE..!) Before I start, I would like to know whether such a framework would be useful and fits with the overall vision of plasma and KDE. And, further inputs are always welcome and needed ;) Regards, Hari krishna Anandhan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
