Re: KDE framework 5 - a humble idea

2013-10-03 Thread Thomas Pfeiffer 
On Wednesday 02 October 2013 00:35:17 Sebastian Kügler wrote:
> Hi Michele,
> 
> On Wednesday, September 25, 2013 22:46:29 Michele Kipiel wrote:
> > Il giorno lun, 23/09/2013 alle 22.02 +0200, Aaron J. Seigo ha scritto:
> > > On Monday, September 23, 2013 14:45:53 Michele Andrea Kipiel wrote:
> > > > is there a preferred way to share documents in the mailing list? is an
> > > > ubuntu one link an acceptable option?
> > > 
> > > as long as it is available without requiring special software installed
> > > or
> > > an  account, it doesn’t particularly matter where it is stored.
> > 
> > you can find the scenarios document here
> > http://ubuntuone.com/6E70KbRoRSEFLu9he3OptU
> > 
> > there's only three for now, i am currently working on the fourth, which
> > will be called "the fluid desktop"
> 
> Well-written scenarios, I think they're quite useful. Some thoughts:
> 
> Scenario #1 is something that describes how Activities can be used: as a way
> to organize the working environment. My experience with using Activities is
> that it allows you to have multiple clean working environments and have it
> easy to switch between them. In Plasma Active, the document-centric
> approach is much more pronounced, here you can connect documents, links,
> and other "Things" (defined by what we can describe using Nepomuk) to an
> Activity. This is a neat concept that is almost invisible in today's Plasma
> Desktop, unfortunately.
> 
> Scenario #2 would, from the technology side, need two things: A powerful RSS
> reader, and making sure dragging and dropping of feeds works. (For example,
> does dragging a URL to an RSS feed actually offer the "News" widget when
> dropped onto Plasma?). We have some RSS tools, but I don't think they allow
> the level of features you propose at this point. There's the News and RSS
> Feed Plasma widgets, and Akregator, which would need some design and code
> love. This scenarion is just as interesting when you replace the News with
> Email. Using Akonadi in the background, these things could possibly share
> quite some code, while being totally different things to the user.
> Imagine by the way this guy to help with filtering and sorting or the feeds:
> http://steckdenis.be/post-2013-09-25-the-end-of-the-google-summer-of-code.h
> tml
> 
> Scenario #3 raises an interesting topic: "How do people find their
> applications?". That's a complex problem which can be viewed from different
> angles:
> - The user just wants to get something done, she's not interested in a
> specific application, but needs her problem solved
> - There are multiple tools doing the same in different ways, some are for
> power users, some are more basic (imagine photo management with gwenview vs.
> digikam, for example). How to suggest the right tool?
> - Matching packages against user requirements ("install me something that
> can do X and Y")
> - Having the necessary software installed doesn't mean the user
> automatically knows a good workflow for it, often interaction between more
> than one tool is needed, complexity rises. This comes back to your original
> thoughts of workflows-across-components
> - The user knows the name of the tool and just wants to run it, it might not
> be installed yet, so that should be easy to do. This is I think a
> comparatively simple, but basic and essential feature.
> 
> Interesting prior art does exist, Aleix Pol has created Muon Discover, which
> takes a non-traditional approach to what technically, a package manager can
> do for you. There's also the Kickoff / PackageKit integration, which shows
> you hits for applications from the launcher menu and offers to install
> them.
> 
> Next steps would be:
> - Refine scenarios with use cases and detailed description of workflows
> - Test and evaluate what works today, and what needs changes (preferably
>   prioritised)
> - Define technical requirements, create a task list of things to solve
> - Find people to work on that, this could be in the form of "Shouting who
> wants to help solve these problems?", a Season of KDE / Summer of Code
> project, an internship, or, best, by someone scratching their own itch.
> 
> Reading the scenarios made me realise that I personally would prefer to have
> this on our wiki at community.kde.org/Plasma. There's matching information
> already there. Maybe it could be moved next to it and be refined from
> there? Quite relevant in the light of the scenarios is the work we did on
> persona's last year. You can find them at
> http://community.kde.org/Plasma/Workspace_Sprint/Personas , I've written a
> blog entry about that some time ago, you can find it at:
> http://vizzzion.org/blog/2012/06/plasma-personas-carla-and-raj/ . A good
> person, and one of our interaction guys is Thomas Pfeiffer (dunno if he
> follows this list closely, so I've CC:'ed him to make him aware of this
> discussion.

Thank you Sebas for CC'ing me! This is indeed a very interesting topic for me 
and I would have missed it otherwise (turns

Re: KDE framework 5 - a humble idea

2013-10-02 Thread Michele Andrea Kipiel 
2013/10/2 Sebastian Kügler 

> On Wednesday, October 02, 2013 00:35:17 Sebastian Kügler wrote:
> > person, and one of our interaction guys is Thomas Pfeiffer (dunno if he
> > follows this list closely, so I've CC:'ed him to make him aware of this
> > discussion.
>
> )
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>


Hello,

thanks for the awsome reply! i don't have the time to answer to all of your
comments right now, since i'm at work, but i'll sure spend the next few
nights gathering documentation and improving the concept to come back with
the best possible reply.

i'm looking forward to hear from mr. Pfeiffer about this concept!
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-10-01 Thread Sebastian Kügler 
On Wednesday, October 02, 2013 00:35:17 Sebastian Kügler wrote:
> person, and one of our interaction guys is Thomas Pfeiffer (dunno if he 
> follows this list closely, so I've CC:'ed him to make him aware of this 
> discussion.

)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-10-01 Thread Sebastian Kügler 
Hi Michele,

On Wednesday, September 25, 2013 22:46:29 Michele Kipiel wrote:
> Il giorno lun, 23/09/2013 alle 22.02 +0200, Aaron J. Seigo ha scritto:
> > On Monday, September 23, 2013 14:45:53 Michele Andrea Kipiel wrote:
> > > is there a preferred way to share documents in the mailing list? is an
> > > ubuntu one link an acceptable option?
> >
> > as long as it is available without requiring special software installed or
> > an  account, it doesn’t particularly matter where it is stored.
> >
> you can find the scenarios document here
> http://ubuntuone.com/6E70KbRoRSEFLu9he3OptU
> 
> there's only three for now, i am currently working on the fourth, which
> will be called "the fluid desktop"

Well-written scenarios, I think they're quite useful. Some thoughts:

Scenario #1 is something that describes how Activities can be used: as a way 
to organize the working environment. My experience with using Activities is 
that it allows you to have multiple clean working environments and have it 
easy to switch between them. In Plasma Active, the document-centric approach 
is much more pronounced, here you can connect documents, links, and other 
"Things" (defined by what we can describe using Nepomuk) to an Activity. This 
is a neat concept that is almost invisible in today's Plasma Desktop, 
unfortunately.

Scenario #2 would, from the technology side, need two things: A powerful RSS 
reader, and making sure dragging and dropping of feeds works. (For example, 
does dragging a URL to an RSS feed actually offer the "News" widget when 
dropped onto Plasma?). We have some RSS tools, but I don't think they allow 
the level of features you propose at this point. There's the News and RSS Feed 
Plasma widgets, and Akregator, which would need some design and code love. 
This scenarion is just as interesting when you replace the News with Email. 
Using Akonadi in the background, these things could possibly share quite some 
code, while being totally different things to the user.
Imagine by the way this guy to help with filtering and sorting or the feeds: 
http://steckdenis.be/post-2013-09-25-the-end-of-the-google-summer-of-code.html

Scenario #3 raises an interesting topic: "How do people find their 
applications?". That's a complex problem which can be viewed from different 
angles:
- The user just wants to get something done, she's not interested in a 
specific application, but needs her problem solved
- There are multiple tools doing the same in different ways, some are for 
power users, some are more basic (imagine photo management with gwenview vs. 
digikam, for example). How to suggest the right tool?
- Matching packages against user requirements ("install me something that can 
do X and Y")
- Having the necessary software installed doesn't mean the user automatically 
knows a good workflow for it, often interaction between more than one tool is 
needed, complexity rises. This comes back to your original thoughts of 
workflows-across-components
- The user knows the name of the tool and just wants to run it, it might not 
be installed yet, so that should be easy to do. This is I think a 
comparatively simple, but basic and essential feature.

Interesting prior art does exist, Aleix Pol has created Muon Discover, which 
takes a non-traditional approach to what technically, a package manager can do 
for you. There's also the Kickoff / PackageKit integration, which shows you 
hits for applications from the launcher menu and offers to install them.

Next steps would be:
- Refine scenarios with use cases and detailed description of workflows
- Test and evaluate what works today, and what needs changes (preferably 
  prioritised)
- Define technical requirements, create a task list of things to solve
- Find people to work on that, this could be in the form of "Shouting who 
wants to help solve these problems?", a Season of KDE / Summer of Code 
project, an internship, or, best, by someone scratching their own itch.

Reading the scenarios made me realise that I personally would prefer to have 
this on our wiki at community.kde.org/Plasma. There's matching information 
already there. Maybe it could be moved next to it and be refined from there? 
Quite relevant in the light of the scenarios is the work we did on persona's 
last year. You can find them at 
http://community.kde.org/Plasma/Workspace_Sprint/Personas , I've written a 
blog entry about that some time ago, you can find it at: 
http://vizzzion.org/blog/2012/06/plasma-personas-carla-and-raj/ . A good 
person, and one of our interaction guys is Thomas Pfeiffer (dunno if he 
follows this list closely, so I've CC:'ed him to make him aware of this 
discussion.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-09-27 Thread Mark 
On Wed, Sep 25, 2013 at 10:46 PM, Michele Kipiel
wrote:

> Il giorno lun, 23/09/2013 alle 22.02 +0200, Aaron J. Seigo ha scritto:
> > On Monday, September 23, 2013 14:45:53 Michele Andrea Kipiel wrote:
> > > is there a preferred way to share documents in the mailing list? is an
> > > ubuntu one link an acceptable option?
> >
> > as long as it is available without requiring special software installed
> or an
> > account, it doesn’t particularly matter where it is stored.
> >
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
>
> you can find the scenarios document here
> http://ubuntuone.com/6E70KbRoRSEFLu9he3OptU
>
>
> there's only three for now, i am currently working on the fourth, which
> will be called "the fluid desktop"
>

I'm very curious about those ideas. What you described thus far sounds
interesting.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-09-25 Thread Michele Kipiel 
Il giorno lun, 23/09/2013 alle 22.02 +0200, Aaron J. Seigo ha scritto:
> On Monday, September 23, 2013 14:45:53 Michele Andrea Kipiel wrote:
> > is there a preferred way to share documents in the mailing list? is an
> > ubuntu one link an acceptable option?
> 
> as long as it is available without requiring special software installed or an 
> account, it doesn’t particularly matter where it is stored.
> 
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

you can find the scenarios document here
http://ubuntuone.com/6E70KbRoRSEFLu9he3OptU


there's only three for now, i am currently working on the fourth, which
will be called "the fluid desktop"



___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-09-24 Thread Michele Andrea Kipiel 
Thank you, i will post a link to the scenario document as soon as i get
back home after work.


2013/9/23 Aaron J. Seigo 

> On Monday, September 23, 2013 14:45:53 Michele Andrea Kipiel wrote:
> > is there a preferred way to share documents in the mailing list? is an
> > ubuntu one link an acceptable option?
>
> as long as it is available without requiring special software installed or
> an
> account, it doesn’t particularly matter where it is stored.
>
> --
> Aaron J. Seigo
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-09-23 Thread Aaron J. Seigo 
On Monday, September 23, 2013 14:45:53 Michele Andrea Kipiel wrote:
> is there a preferred way to share documents in the mailing list? is an
> ubuntu one link an acceptable option?

as long as it is available without requiring special software installed or an 
account, it doesn’t particularly matter where it is stored.

-- 
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-09-23 Thread Michele Andrea Kipiel 
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 

> 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 wi

Re: KDE framework 5 - a humble idea

2013-09-21 Thread Michele Kipiel 
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 mimet

Re: KDE framework 5 - a humble idea

2013-09-20 Thread 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 i

Re: KDE framework 5 - a humble idea

2013-09-20 Thread Mark 
On Fri, Sep 20, 2013 at 6:40 AM, Bhushan Shah  wrote:

> Hello,
>
> On Wed, Sep 18, 2013 at 2:56 PM, Michele Andrea Kipiel
>  wrote:
> > 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.
>
> AFAIK this kind of feature already exist in KDE.. Just tested.. Not
> actually Facebook Feed plasmoid but though I can drag image or text
> file from FolderView plasmoid to Pastebin plasmoid which uploads it to
> pastebin or other client..
>
> Thanks!
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

The difficulty is probably not in having the feature itself, but having all
plasmoids use it when it makes sense.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-09-19 Thread Bhushan Shah 
Hello,

On Wed, Sep 18, 2013 at 2:56 PM, Michele Andrea Kipiel
 wrote:
> 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.

AFAIK this kind of feature already exist in KDE.. Just tested.. Not
actually Facebook Feed plasmoid but though I can drag image or text
file from FolderView plasmoid to Pastebin plasmoid which uploads it to
pastebin or other client..

Thanks!
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-09-19 Thread Michele Andrea Kipiel 
Hi Kevin,

that's exactly the interesting part (and the challenge): to forge a new
interaction paradigm for the desktop. During the weekend i'll try to sketch
some wireframes and some flowcharts to better explain the concept, i'll
keep you posted. In the meantime, feel free to comment and to propose ideas!

Thank you all!
MK


2013/9/19 Mark 

> On Thu, Sep 19, 2013 at 12:20 PM, Kevin Krammer  wrote:
>
>> On Wednesday, 2013-09-18, Marco Martin wrote:
>> > On Wednesday 18 September 2013, Michele Andrea Kipiel wrote:
>>
>> > > 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)?
>> >
>> > As Mark already said, this is mostly implementing meaningful actions for
>> > drag and drop on every plasmoid where it makes sense, and this is an
>> > orthogonal problem to actually "communicating with each other"
>> >
>> > now would be needed to be defined what "communicating with each other"
>> > means.. does a folderview plasmoid need to know a picture frame is here
>> > too? if yes, what it needs to say to it? is it needed an api?
>>
>> I think one way of improving drag&drop based workflows is to indicate
>> possible
>> drop targets when the drag starts.
>> With traditional drag&drop the users have to try where they can actually
>> drop
>> whatever they are currently dragging, i.e. the potential drop target says
>> whether it will likely accept a drop at the current pointer position.
>>
>> Given that the Plasma engine knowns all currently running Plasma applets,
>> it
>> could also be aware of all accepted dropdata types for each of them and,
>> e.g.
>> fade out those that can't do anything with the object currently being
>> dragged.
>> Or even on hover or when an item gets selected.
>>
>> > right now plasmoids by themselves are designed to be as sandboxed as
>> > possible, in part for security in part for lack of use case for doing
>> > otherwise.
>>
>> Data could be transferred through a mediator, e.g. in the drag&drop
>> scenario
>> that is the system service providing drag&drop communication (in X11 the
>> Xserver).
>>
>> Cheers,
>> Kevin
>>
>
> Hi Kevin,
>
> I didn't think of that.. If you extend your idea you could also do much
> more advanced things.
> For example, imagine the gimp plasmoid again. You can drag an image in it
> and apply effects on it. However, with your idea you could also do the
> complete opposite. You can simply have the gimp plasmoid with effects and
> drag those specific effects to some images. Either in a dolphin plasmoid or
> in facebook or whatever has images.
>
> That's like opening a whole slew of new possible features if the stuff you
> say would be implemented. But would it be used? I actually doubt it. Unless
> there would be some custom QML components that make those features
> available in a very easy manner.
>
> Cheers,
> Mark
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-09-19 Thread Mark 
On Thu, Sep 19, 2013 at 12:20 PM, Kevin Krammer  wrote:

> On Wednesday, 2013-09-18, Marco Martin wrote:
> > On Wednesday 18 September 2013, Michele Andrea Kipiel wrote:
>
> > > 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)?
> >
> > As Mark already said, this is mostly implementing meaningful actions for
> > drag and drop on every plasmoid where it makes sense, and this is an
> > orthogonal problem to actually "communicating with each other"
> >
> > now would be needed to be defined what "communicating with each other"
> > means.. does a folderview plasmoid need to know a picture frame is here
> > too? if yes, what it needs to say to it? is it needed an api?
>
> I think one way of improving drag&drop based workflows is to indicate
> possible
> drop targets when the drag starts.
> With traditional drag&drop the users have to try where they can actually
> drop
> whatever they are currently dragging, i.e. the potential drop target says
> whether it will likely accept a drop at the current pointer position.
>
> Given that the Plasma engine knowns all currently running Plasma applets,
> it
> could also be aware of all accepted dropdata types for each of them and,
> e.g.
> fade out those that can't do anything with the object currently being
> dragged.
> Or even on hover or when an item gets selected.
>
> > right now plasmoids by themselves are designed to be as sandboxed as
> > possible, in part for security in part for lack of use case for doing
> > otherwise.
>
> Data could be transferred through a mediator, e.g. in the drag&drop
> scenario
> that is the system service providing drag&drop communication (in X11 the
> Xserver).
>
> Cheers,
> Kevin
>

Hi Kevin,

I didn't think of that.. If you extend your idea you could also do much
more advanced things.
For example, imagine the gimp plasmoid again. You can drag an image in it
and apply effects on it. However, with your idea you could also do the
complete opposite. You can simply have the gimp plasmoid with effects and
drag those specific effects to some images. Either in a dolphin plasmoid or
in facebook or whatever has images.

That's like opening a whole slew of new possible features if the stuff you
say would be implemented. But would it be used? I actually doubt it. Unless
there would be some custom QML components that make those features
available in a very easy manner.

Cheers,
Mark
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-09-19 Thread Kevin Krammer 
On Wednesday, 2013-09-18, Marco Martin wrote:
> On Wednesday 18 September 2013, Michele Andrea Kipiel wrote:

> > 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)?
> 
> As Mark already said, this is mostly implementing meaningful actions for
> drag and drop on every plasmoid where it makes sense, and this is an
> orthogonal problem to actually "communicating with each other"
> 
> now would be needed to be defined what "communicating with each other"
> means.. does a folderview plasmoid need to know a picture frame is here
> too? if yes, what it needs to say to it? is it needed an api?

I think one way of improving drag&drop based workflows is to indicate possible 
drop targets when the drag starts.
With traditional drag&drop the users have to try where they can actually drop 
whatever they are currently dragging, i.e. the potential drop target says 
whether it will likely accept a drop at the current pointer position.

Given that the Plasma engine knowns all currently running Plasma applets, it 
could also be aware of all accepted dropdata types for each of them and, e.g. 
fade out those that can't do anything with the object currently being dragged.
Or even on hover or when an item gets selected.

> right now plasmoids by themselves are designed to be as sandboxed as
> possible, in part for security in part for lack of use case for doing
> otherwise.

Data could be transferred through a mediator, e.g. in the drag&drop scenario 
that is the system service providing drag&drop communication (in X11 the 
Xserver).

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-09-18 Thread Mark 
On Wed, Sep 18, 2013 at 10:01 PM, Michele Kipiel
wrote:

> Il giorno mer, 18/09/2013 alle 18.10 +0200, Mark ha scritto:
> > -- bottom post please --
> > On Wed, Sep 18, 2013 at 4:59 PM, Michele Andrea Kipiel
> >  wrote:
> > Hello
> >
> >
> > thanks for the quick reply :)
> >
> >
> > the interaction you describe as "truly communicating
> > plasmoids" is pretty much what i imagined when i referred to
> > yahoo pipes. i imagined  some scenarios for that interactio
> > too: think of a "picture frame" plasmoid which displays a new
> > picture every time a twitter profile (national geographic, for
> > example) posts a picture. that would require a background
> > connection between the two. Another scenario i imagined is a
> > stock based one: imagine you have a "stock ticker" plasmoid on
> > your desk, wich is connected to a "spreadsheet" plasmoid which
> > registers all the variation of a certain stock and then saves
> > them in a file.
> >
> >
> > The core idea of my proposal is to enable a new interaction
> > layer wich is accessible straight from the desktop, without
> > the need to even launch a single application after boot&login.
> > The desktop itself would become an active environmnt, instead
> > of an empty space.
> >
> >
> > Would such a desktop fit your workflow?
> >
> >
> >
> > 2013/9/18 Mark 
> > On Wed, Sep 18, 2013 at 11:26 AM, 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 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.
> >
> > 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
> >

Re: KDE framework 5 - a humble idea

2013-09-18 Thread Michele Kipiel 
Il giorno mer, 18/09/2013 alle 18.10 +0200, Mark ha scritto:
> -- bottom post please --
> On Wed, Sep 18, 2013 at 4:59 PM, Michele Andrea Kipiel
>  wrote:
> Hello
> 
> 
> thanks for the quick reply :)
> 
> 
> the interaction you describe as "truly communicating
> plasmoids" is pretty much what i imagined when i referred to
> yahoo pipes. i imagined  some scenarios for that interactio
> too: think of a "picture frame" plasmoid which displays a new
> picture every time a twitter profile (national geographic, for
> example) posts a picture. that would require a background
> connection between the two. Another scenario i imagined is a
> stock based one: imagine you have a "stock ticker" plasmoid on
> your desk, wich is connected to a "spreadsheet" plasmoid which
> registers all the variation of a certain stock and then saves
> them in a file. 
> 
> 
> The core idea of my proposal is to enable a new interaction
> layer wich is accessible straight from the desktop, without
> the need to even launch a single application after boot&login.
> The desktop itself would become an active environmnt, instead
> of an empty space.
> 
> 
> Would such a desktop fit your workflow?
> 
> 
> 
> 2013/9/18 Mark 
> On Wed, Sep 18, 2013 at 11:26 AM, 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 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.
>

Re: KDE framework 5 - a humble idea

2013-09-18 Thread Mark 
-- bottom post please --
On Wed, Sep 18, 2013 at 4:59 PM, Michele Andrea Kipiel <
michele.kip...@gmail.com> wrote:

> Hello
>
> thanks for the quick reply :)
>
> the interaction you describe as "truly communicating plasmoids" is pretty
> much what i imagined when i referred to yahoo pipes. i imagined  some
> scenarios for that interactio too: think of a "picture frame" plasmoid
> which displays a new picture every time a twitter profile (national
> geographic, for example) posts a picture. that would require a background
> connection between the two. Another scenario i imagined is a stock based
> one: imagine you have a "stock ticker" plasmoid on your desk, wich is
> connected to a "spreadsheet" plasmoid which registers all the variation of
> a certain stock and then saves them in a file.
>
> The core idea of my proposal is to enable a new interaction layer wich is
> accessible straight from the desktop, without the need to even launch a
> single application after boot&login. The desktop itself would become an
> active environmnt, instead of an empty space.
>
> Would such a desktop fit your workflow?
>
>
> 2013/9/18 Mark 
>
>> On Wed, Sep 18, 2013 at 11:26 AM, Michele Andrea Kipiel <
>> michele.kip...@gmail.com> 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 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.
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> 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.
>>>
>>> regards,
>>> MK
>>>
>>> ___
>>> Plasma-devel mailing list
>>> Plasma-devel@kde.org
>>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>>
>>>
>> Hi,
>>
>> First of all, i'm not a plasma developer so i can't really comment on
>> your ideas from a plasma desktop point of view. I can on a technical point
>> of view.
>>
>> What you describe as plasmoids talking to each other with the examples
>> you provide isn't really talking to each other at all. It is just properly
>> implementing drag/drop for all plasmoids. So for example, if you want to
>> "drag" an image from your file browser to the "gimp" plasmoid then the
>> "gimp" plasmoid would have to support dropping that specific image format.
>> Furthermore if you want to manipulate that image on the gimp plasmoid and
>> drag the results to facebook then it would hav

Re: KDE framework 5 - a humble idea

2013-09-18 Thread Marco Martin 
On Wednesday 18 September 2013, Michele Andrea Kipiel wrote:
> hello everybody,
> 

hi, thanks for the comments

> 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.

keep in mind that video was pretty much a tech preview, doesn't represent that 
much how the ui will be (even tough right now the plan is to have a release of 
plasma2 with an ui/feature set similar to plasma1)

> 
> 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)?

As Mark already said, this is mostly implementing meaningful actions for drag 
and drop on every plasmoid where it makes sense, and this is an orthogonal 
problem to actually "communicating with each other"

now would be needed to be defined what "communicating with each other" means.. 
does a folderview plasmoid need to know a picture frame is here too? if yes, 
what it needs to say to it? is it needed an api?

right now plasmoids by themselves are designed to be as sandboxed as possible, 
in part for security in part for lack of use case for doing otherwise.

even tough they can communicate with the environment and with other 
applications with means of nepomuk,akonadi as common "data stores" and share-
like-connect as in a plasmoid that knows what file or url the currently active 
application is working on

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE framework 5 - a humble idea

2013-09-18 Thread Michele Andrea Kipiel 
Hello

thanks for the quick reply :)

the interaction you describe as "truly communicating plasmoids" is pretty
much what i imagined when i referred to yahoo pipes. i imagined  some
scenarios for that interactio too: think of a "picture frame" plasmoid
which displays a new picture every time a twitter profile (national
geographic, for example) posts a picture. that would require a background
connection between the two. Another scenario i imagined is a stock based
one: imagine you have a "stock ticker" plasmoid on your desk, wich is
connected to a "spreadsheet" plasmoid which registers all the variation of
a certain stock and then saves them in a file.

The core idea of my proposal is to enable a new interaction layer wich is
accessible straight from the desktop, without the need to even launch a
single application after boot&login. The desktop itself would become an
active environmnt, instead of an empty space.

Would such a desktop fit your workflow?


2013/9/18 Mark 

> On Wed, Sep 18, 2013 at 11:26 AM, Michele Andrea Kipiel <
> michele.kip...@gmail.com> 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 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.
>>
>> 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.
>>
>> 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).
>>
>> 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.
>>
>> regards,
>> MK
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
> Hi,
>
> First of all, i'm not a plasma developer so i can't really comment on your
> ideas from a plasma desktop point of view. I can on a technical point of
> view.
>
> What you describe as plasmoids talking to each other with the examples you
> provide isn't really talking to each other at all. It is just properly
> implementing drag/drop for all plasmoids. So for example, if you want to
> "drag" an image from your file browser to the "gimp" plasmoid then the
> "gimp" plasmoid would have to support dropping that specific image format.
> Furthermore if you want to manipulate that image on the gimp plasmoid and
> drag the results to facebook then it would have to support drag
> functionality as well. The facebook plasmoid would then have to accept a
> drop with that image type and handle it. That is not easy stuff to
> implement properly. In fact, in pure QML (which the new plasmoids for
> pla

Re: KDE framework 5 - a humble idea

2013-09-18 Thread Mark 
On Wed, Sep 18, 2013 at 11:26 AM, Michele Andrea Kipiel <
michele.kip...@gmail.com> 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 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.
>
> 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.
>
> 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).
>
> 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.
>
> regards,
> MK
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
Hi,

First of all, i'm not a plasma developer so i can't really comment on your
ideas from a plasma desktop point of view. I can on a technical point of
view.

What you describe as plasmoids talking to each other with the examples you
provide isn't really talking to each other at all. It is just properly
implementing drag/drop for all plasmoids. So for example, if you want to
"drag" an image from your file browser to the "gimp" plasmoid then the
"gimp" plasmoid would have to support dropping that specific image format.
Furthermore if you want to manipulate that image on the gimp plasmoid and
drag the results to facebook then it would have to support drag
functionality as well. The facebook plasmoid would then have to accept a
drop with that image type and handle it. That is not easy stuff to
implement properly. In fact, in pure QML (which the new plasmoids for
plasma 2 are) that only becomes possible in Qt 5.2. Now i think KDE had
some custom drag/drop components that implemented the same support.

Then for plasmoids _really_ talking to each other. If that where to be
implemented (which i doubt) then i guess it should work somewhat like this.
Reusing your example here. Imagine you have a facebook plasmoid and you're
using it. If you then move to a "file manager plasmoid" it should know that
you came from the facebook plasmoid. If you then select and drag an image
it could automatically pop up a "gimp" plasmoid to throw some fancy filters
over your image. The gimp plasmoid (which then knows you came here from the
file browser from facebook) should offer an option: "Publish to facebook"
or something alike. That would be really plasmoids communicating with each
other and would frankly be quite scarry :)

Lastly how i use the plasmoids. I'm a developer so i have an interest in
more then one console window. So i simply put a bunch of consoles on my
desktop along with a CPU monitor. That works quite well, but only works if
you have

Re: KDE framework 5 - a humble idea

2013-09-18 Thread Mario Fux KDE ML 
Am Mittwoch 18 September 2013, 11.26:21 schrieb Michele Andrea Kipiel:
> hello everybody,

Good morning Michele

> 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.

Thanks for your email. Your idea seems quite similar to:
https://conf.kde.org/en/Akademy2013/public/events/15

Which was already discussed here and/or on the active list. As I see it this 
idea "just" needs implementers.

Oh and btw. I think you talk about the Plasma 2 Workspaces and not directly 
about KDE Frameworks 5 (which are the libraries used).

[snip]

Best regards
Mario
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

KDE framework 5 - a humble idea

2013-09-18 Thread Michele Andrea Kipiel 
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 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.

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.

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).

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.

regards,
MK
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel