|
APR
25
2015
|
Building on new pillars: Activities and KPeople in Plasma 5.3With the release of Plasma 5.3 only days away, it's time to start talking about some of the new features users of Plasma Desktop will get their hands on in the new version. Activities Many Plasma Desktop users are already familiar with Activities as a toolbox to divide and organize their personal computing environment into shards: You can set up and name activities, distribute application windows across them, associate relevant files with them, switch between, start and stop them to your heart's content. A previously less explored side to the Activities story is what the technology can offer while working inside any one of your activities - thus even if you don't bother with setting up more than one and just stick to the default activity created for you the first time you log into Plasma. This changes with Plasma 5.3! New work to make it easier for applications to enter useful data into the activity's knowledge store, as well as run smart queries against it, enable some new and improved functionality in both the Application Menu and Task Manager widgets in this release. In Application Menu, all of the Recent categories (one of which is new) are now powered by Activities. One immediate advantage of this is that their contents now change with the activity you're in, but as promised it also provides several other inherent benefits:  The three Recent categories in Application Menu 5.3
KPeople  Recent Contacts in Application Menu 5.3: Powered by Activities and KPeople The KPeople framework allows applications (including the shell) to retrieve lists of people and information about them (status, contact metadata), as well as perform actions on them - e.g. initiate a chat, as used by Application Menu when you click on an entry in the Recent Contacts category. The data backing this interface is provided by backend plugins. The first implementer of a fully-featured KPeople backend is of course our very own Telepathy instant messenging suite. In the future, other KDE communication apps will integrate with KPeople, making conversations had e.g. in KDE's IRC client Konversation pop up in Application Menu as well. Closing thoughts Both the enhanced Activities backend and KPeople are very fresh. While we work hard to line up everything behind them (implement additional data sources and optimize those implementations, for example), they are still exposed somewhat carefully in Plasma Desktop 5.3. The Recent Contacts category in Application Menu, for example, is disabled in this release by default, because a Telepathy release entering conversation data into the Activities knowledge store is still pending. It can be enabled from the widget's config dialog. In future releases you can expect us to make more of these pillars as our confidence grows, with additional UI functionality built on them and more prominent placements of it in various areas of the shell. Lots of work ahead! |
 |
Comments
launching documents from inside dolphin
Getting all the data on recently used applications/documents in connection to an activity is quite nice and has potential, but the current experience using multiple windows of the same program (e.g. kate) on different activities and trying to opening text documents from dolphin is rather confusing to me.
Create a few txt files (touch {1,2,3}.txt}, open dolphin and kate on two activities each and start a small experiment by opening files from inside dolphin from different activities. Currently it is not clear to me why a specific kate window opens the document, even if it is not in the same activity. The only way to reliable open a file in the window I want is to drag it from the file manager to the application window. Bug?
This sounds like a failure of
This sounds like a failure of Kate's "reuse active window" code to take the activity context into account. Kate is simply run with the URL as argument and has to take it from there. Report a bug against Kate on bugs.kde.org so the Kate team becomes aware :). Adding some code that sorts the eligible windows by a comparison between the current activity and what activity the windows are on is doable and shouldn't be too hard.
The bug already exists
The bug already exists (284474) as some searching revealed. So thanks for the pointer and sorry for the noise here.
activities , ux research and browsers
Recently I participated in a user research about activities. Are the things you are discussing here in line with the finding of that study? If so please state that to your article, along with other findings that can help us get some context. If not I really think you need to consider adding features after consulting what the user base thinks.
Personally I think that we have a real problem when we do not have activities integration with modern web browsers. That is where most users spent their time nowadays and not having that integration essentially keeps users from using activities more.
The theme of this post is
The theme of this post is mostly how Activities as library technology help realize and expand upon older features, such as access to recently-used data or recent events. As highlighted early on, this is useful stuff even if the user isn't necessarily aware of activity sharding at all, and only uses one activity. In some sense this post is really about Application Menu and Task Manager, but the audience of Planet KDE surely appreciates hearing about how these things tie together under the hood. It's also nice to let people know that Activities is much more than a sidebar and a few context menus they may or may not be using.
The research you're talking about (which I personally wasn't involved with, no) focused on the sharding aspect of Activities, and while the features talked about here are inherently sharding-enabled, doesn't really apply to this too much.
We don't disagree
I agree with what you are saying, however, activities (and in that sense application men and task manager) could significantly gain from understanding what the users want rather than the user's be told what they might get. I respect the time and effort you put in this an by no means I want to sound negative or unappreciative but if you are interested in creating something that would benefit the user then you need to look at what the user wants. That was the purpose of the study, how users work with activities and what they find frustrating.
I think it is really grate that KDE is a multifaceted project that has ux designers thinking about things
You do sound really negative
You do sound really negative though, because you have no reason to assume that I didn't listen to what users want - that's a claim you treat as truth in your comments, but don't really back up with anything :). Recent documents in Task Manager launchers have been requested by users many times, for example, and are going to make quite a lot of folks happy. Try it in 5.3 - it's very handy and a big time saver!
negative only if you see it that way
I do not think I am negative. I am only stating that we had the luxury of having a ux study for that piece of functionality. We are lucky enough to have ux people doing some work in kde , we would be even luckier if we could combine development and ux work to create even better things.
I can relate to that. I tried
I can relate to that. I tried to adapt to using multiple Activities, but found that the feature I most wanted out of it was to have different sets of open tabs and bookmarks in the various Activities. Without that, I didn't want to bother with it at all.
Vista
The recent application documents are stolen from Windows Vista. I always emphasis KDE developers comes clean, when some technology went from Windows(in difference of Microsoft, which stolen technology from Linux and emphasis it's revolutionary). But the idea about connecting recent documents with activities is probably older than Vista. Microsoft firstly stolen this idea, but divide recent documents by application instead of activities, because Windows don't have Activities.
Pages