[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: KDE framework 5 - a humble idea
From: Michele Andrea Kipiel <michele.kipiel () gmail ! com>
Date: 2013-09-19 15:35:36
Message-ID: CAOeydTVsq+Ai2BhZtN3vMyh65Bw5W=Ci42TUJbavv9qtPs-X3Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 <markg85@gmail.com>
> On Thu, Sep 19, 2013 at 12:20 PM, Kevin Krammer <krammer@kde.org> 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
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div><div>Hi Kevin,<br><br></div>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!<br> <br></div>Thank you all!<br>MK<br></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">2013/9/19 Mark <span \
dir="ltr"><<a href="mailto:markg85@gmail.com" \
target="_blank">markg85@gmail.com</a>></span><br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div \
dir="ltr"><div><div class="h5">On Thu, Sep 19, 2013 at 12:20 PM, Kevin Krammer <span \
dir="ltr"><<a href="mailto:krammer@kde.org" \
target="_blank">krammer@kde.org</a>></span> wrote:<br></div></div><div \
class="gmail_extra"> <div class="gmail_quote"><div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div>On Wednesday, 2013-09-18, Marco Martin wrote:<br> > \
On Wednesday 18 September 2013, Michele Andrea Kipiel wrote:<br> <br>
</div><div>> > i asked myself a simple question: what do i need on my desktop? \
what i<br> > > came to realize is that i could really use a desktop which acts \
as a<br> > > connection point between the hundreds of apps that live on my \
hard<br> > > drive.<br>
> ><br>
> > current plasmoids act as discrete information bubbles (weather, rss, \
im,<br> > > social feeds etc..) and threy don't communicate with each \
other, which in<br> > > my opinion hampers their usefulness. in other words: \
what would happen if<br> > > KDE added a common backend to connect all the \
plasmoids (i'm thinking of<br> > > something similar to what elementary OS \
is doing with contractor)?<br> ><br>
> As Mark already said, this is mostly implementing meaningful actions for<br>
> drag and drop on every plasmoid where it makes sense, and this is an<br>
> orthogonal problem to actually "communicating with each other"<br>
><br>
> now would be needed to be defined what "communicating with each \
other"<br> > means.. does a folderview plasmoid need to know a picture frame \
is here<br> > too? if yes, what it needs to say to it? is it needed an api?<br>
<br>
</div>I think one way of improving drag&drop based workflows is to indicate \
possible<br> drop targets when the drag starts.<br>
With traditional drag&drop the users have to try where they can actually drop<br>
whatever they are currently dragging, i.e. the potential drop target says<br>
whether it will likely accept a drop at the current pointer position.<br>
<br>
Given that the Plasma engine knowns all currently running Plasma applets, it<br>
could also be aware of all accepted dropdata types for each of them and, e.g.<br>
fade out those that can't do anything with the object currently being \
dragged.<br> Or even on hover or when an item gets selected.<br>
<div><br>
> right now plasmoids by themselves are designed to be as sandboxed as<br>
> possible, in part for security in part for lack of use case for doing<br>
> otherwise.<br>
<br>
</div>Data could be transferred through a mediator, e.g. in the drag&drop \
scenario<br> that is the system service providing drag&drop communication (in X11 \
the<br> Xserver).<br>
<br>
Cheers,<br>
Kevin<br></blockquote><div><br></div></div></div><div>Hi \
Kevin,</div><div><br></div><div>I didn't think of that.. If you extend your idea \
you could also do much more advanced things.</div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div>Mark </div></div></div></div>
<br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br> \
<br></blockquote></div><br></div>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic