:) It seems that after a lot of discussion we are back at the beginning (in terms of plans):
Define a bunch of Activities/Contexts (I still prefer Context) and let one be active. Apps will then follow the chosen context when they get informed by the service or ask the service. Sorry, I am not one to write long mails. I tend to throw out little bits. ;) Actually, how about an irc meeting this week to get the ball rolling. I would propose we create a nepomuk service that provides the API and is wrapped in Plasma::Context. We can then continue from there... Cheers, Sebastian On Sunday 31 August 2008 05:16:14 Hari krishna Anandhan wrote: > On Sat, Aug 30, 2008 at 11:53 PM, Aaron J. Seigo <[EMAIL PROTECTED]> wrote: > > this will come down t winow management following the activity; whether or > > not this will end up in kwin or elsewhere remains to be seen, but an app > > associated strongly with a given activity (e.g. set to launch with it) > > should get "put away" when the activity changes. > > > > depending on the application, "put away" can mean either actually > > quitting the process or just hiding it from the user. > > > > most non-document-centric applications, will likely adjust what they are > > showing based on the current context. > > > > document centric ones will come and go with the activity. > > right. makes sense ;) > > > KGet is not really document centric, it's more service centric. as such, > > i would expect it to continue donwloading no matter what i was doing and > > i really don't see "associating KGet with an activity" to make any sense > > whatsoever on the application level. > > well, there might be scenarios where the downloads tagged with > officialActivity have more download precedence than those in > homeActivity... > > > but on the service level (or, per-download) KGet could: > > > > * adjust its download strategy depending on the activity > > > > * tag files with the activity that was active at the time the file > > started downloading > > ok. that brings out a lot of details on what you have envisioned .... > i am starting to feel that my apprehension could be farfetched ;) > > >> No, I completely understand what you were saying...What I am saying is > >> that there may be background or batch processes, where this *might* > >> break > > > > i have yet to come across such scenarios. > > ok. lets tackle any when they come. Now moving on ;) > > >> if it is just plasma which manages this whole thing, without > >> KWin knowledge > > > > plasma has insight into the running applications; how do you think it > > shows a taskbar or a pager? > > yes, via dataengines ! > but "whole thing" actually referred to active context ... > > > *if* we had more than one control point, then we end up with applications > > having to negotiate what the current activity is. good luck. > > > > the Plasma desktop workspace was designed to give users a way to define > > their current activity and the plan was to let the rest of the desktop > > know about it. if other apps don't care, they don't have to follow it. > > > > i fully expect other applications to cooperate, but not control the > > current activity. > > that makes sense ;) > Moving on ;) > _______________________________________________ > nepomuk-kde mailing list > [email protected] > http://lists.semanticdesktop.org/mailman/listinfo/nepomuk-kde _______________________________________________ nepomuk-kde mailing list [email protected] http://lists.semanticdesktop.org/mailman/listinfo/nepomuk-kde
