KDE framework 5 - a humble idea

Mon Sep 23 12:45:53 UTC 2013

hello,

is there a preferred way to share documents in the mailing list? is an
ubuntu one link an acceptable option?
Thank you,

2013/9/21 Michele Kipiel <michele.kipiel at gmail.com>

> Il giorno sab, 21/09/2013 alle 01.51 +0200, Sebastian Kügler ha scritto:
> > 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,
>
> hello,
>
> thank you very much for this fantastic reply, you gave me lots of
> information i was missing or unable to figure out. This really gives me
> a lot to base my wireframes and workflows on, which is a great thing.
>
> I hope to come up with some workflow examples in a few days, so we'll
> have something to talk about.
>
> Thank you again
> MK
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130923/b48a67c9/attachment-0001.html>