KDE framework 5 - a humble idea

[Sebastian Kügler]

Hi Michele,

A few thoughts inline. I've also explained a bit of the technical 
underpinnings of the ideas you propose, just to give you a general 
understanding of how the system is handling these things, and how the concepts 
could be described technically.

On Wednesday, September 18, 2013 11:26:21 Michele Andrea Kipiel wrote:
> hello everybody,
> 
> the following message is part of an email i sent a few days ago to Marco
> Martin, who then asked me to share my thoughts on this mailng list.
> 
> ***
> my name is michele kipiel and i am a ux designer. I currently work for the
> Kering luxury group, where i design and user test the checkout processes
> and the overall UX of the luxury sites.
> 
> i recently came across a video showing the new KDE framework 5 improvements
> (the one posted by phoronics, in case you were wondering).
> 
> watching that video reminded me of what immediately struck me when i first
> tried KDE 4: the apparent lack of a true purpose for the plasmoids. as a ux
> designer i constantly strive towards simplification and rationalization of
> the user experience, and the first thing i noticed about the plasmoids was
> that they didn't improve my experience in any relevant way, while taking up
> lots of space on my small 13" laptop screen.

I think others have already pointed it out, but let me clarify that. The video 
(it was probably me who took it) shows test and demo code. The goal here is to 
exercise all kinds of graphical objects on the screen. This helps us in 
porting a whole bunch of other widgets to Plasma 2. They're basically just UI 
tests and examples and have zero purpose for an actual user.

That is to say that we're getting closer to having the basic components in 
place to make Plasma 2 actually useful, and it's certainly a good point in 
time to think about higher level ideas such as workflows between these 
components.

> i asked myself a simple question: what do i need on my desktop? what i came
> to realize is that i could really use a desktop which acts as a connection
> point between the hundreds of apps that live on my hard drive.
> 
> current plasmoids act as discrete information bubbles (weather, rss, im,
> social feeds etc..) and threy don't communicate with each other, which in
> my opinion hampers their usefulness. in other words: what would happen if
> KDE added a common backend to connect all the plasmoids (i'm thinking of
> something similar to what elementary OS is doing with contractor)?
> 
> imagine this scenario: i have a file manager plasmoid open on my desktop,
> along with other ones. i want to share one of my pictures to facebook. i
> drag and drop the picture from the file manager plasmoid onto the "facebook
> feed" plasmoid, which in turn activates the sharing feature, allowing me to
> add a caption, tag my friends and eventually share the picture.

This gets me thinking that we can use Share-Like-Connect for this, in a 
sligthly different manner. Many widgets and a handful of applications 
"publish" their current document (url, or link to a file on the filesystem) to 
other apps. The Share-Like-Connect widget uses this to offer sharing options 
for this. I imagine, that a "gimp" plasmoid could use this same information to 
offer a bunch of image transformations. You pick one, and the published 
document becomes that newly transformed image, then you head over to the 
share-like-connect widget to post it. This is just an example, but would be 
entirely possible with how Plasma works today.

> now imagine i want to turn the picture in b/w before sharing it: i just
> drag and drop the picture onto the "gimp" plasmoid, which shows me a
> preview of the picture and lets me select an action form a pool of simple,
> predefined functions. once my picture is rendered, i just have to drag it
> from the "gimp" plasmoid onto the "facebook" one to share it.

Let's look into what we have for drag and drop support, in more detail. 
Widgets can offer themselves for a certain mimetype being dropped onto the 
"Desktop" (the containment in technical terms). We have applets which can 
handle images for example. The picture frame registers itself as being able to 
"handle" images (it doesn't tell what it does with it), so when you drop an 
image onto the desktop, you get offered the picture frame widget. 
Additionally, for images, you can set them as wallpapers. For text, you'll get 
a Notes widget, etc.
A widget defines what it can handle in its metadata, those can be two things:
- a number of mimetypes (Picture frame has image/png, for example)
- a regular expression to match a url

What happens when you drop "something" onto the desktop (the drop data can 
contain either file data with a certain mimetype, or one or more urls):
- We look through all installed applets, if we find one that can handle the 
  dropped data's mimetype, we add that to the offers
- If the dropped data only has a url, no data and no mimetype, we check the 
  url's destination file for its mimetype, and use that to find suitable 
  widgets
- We look through all installed applets for one that supports a url and 
  matches one of the urls passed in the dropped data
We then end up with zero, one or more widgets that can handle the dropped 
data, if there's one, we create that right away at the drop location, if there 
are more, we pop up a menu offering the widgets.
This whole mechanism also works for remote files (everything that's understood 
by KIO).

>From a higher level point of view, this means, for example:
- You can drop an image from anywhere on the desktop and create a folderview 
  there
- You can drop an image on the desktop -> it creates a folderview
- You can drop text there, get a notes widget

One thing that I had working at some point, but which never made it into a 
release was dropping emails onto the desktop and showing a small widget with 
the email's content. This worked by passing urls to emails in Akonadi, you 
could drag and drop emails from kmail onto the desktop, and from there back to 
kmail. 

Then, we have individual widgets that can receive dropped content. There, you 
can basically do anything you like, check the dropped data and play tricks on 
it or the urls destination. Go wild. An example for this is the pastebin 
widget, which can post dropped content to "paste sites", depending on what 
data it is.

That is to say that the system is already *very* flexible. I think the point 
really is: How do we harnish this power to create awesome workflows. From the 
user point of view, this will need a bit of design work, and probably fixing a 
few things here and there to allow for some newly found usecases. I think one 
of the most important shortcomings of these possible workflows I describe 
above is discoverability. It's hard to see these workflows if they only show 
up in small bits, on certain actions. They do not "offer" themselves to the 
user. That may be a good thing, it should not get in the way, but there's a 
fine line to reach how to make these things discoverable, while being non-
disturbing.

One vision that I have about Activities is that you should be able to drop all 
kinds of artifacts onto an activity, and in that way group these things, so 
Activities. This is mostly possible today, but I think there are quite a bunch 
of details in workflows which haven't been tested and polished.

> in these scenarios each plasmoid acts as a graphic frontend that exposes
> some functions of the related programs, which don't even need to be
> launched. it could be even possible to create predefined sequences
> connecting different plasmoids (think of yahoo pipes, for instance).

One key difference with how the plugin system works is that the options are 
not offered as actions, but as new objects. For example, you get offered a 
Picture Frame widget, but not to apply a cool effect. (Not that this code 
exists today, it just serves as a nice example that you brought up.) In the 
SLC widget, you do actually have actions available, which again might be a bit 
closer to the concept you present.

> i don't know whether this is possible or not, but i believe it could be a
> massive leap forward for the KDE desktop paradigm.
> ***
> 
> thank you in advance for every comment, positive or negative.

I think it would be good to do a couple of things:

- map out a few workflows that would be really useful
- describe these workflows, possibly visually
- design a solution around the above described discoverability problem
- map the needed and missing functionality
- design and implement the bits needed to realize the workflows
- test, iterate

Hope my comments are useful.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9