KDE framework 5 - a humble idea

[Mark]

On Thu, Sep 19, 2013 at 12:20 PM, Kevin Krammer <krammer at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130919/6a790015/attachment.html>