<div dir="ltr">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 class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wednesday, 2013-09-18, Marco Martin wrote:<br>
> On Wednesday 18 September 2013, Michele Andrea Kipiel wrote:<br>
<br>
</div><div class="im">> > 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 class="im"><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>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>