KDE framework 5 - a humble idea

[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 <markg85 at gmail.com>

> 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
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130919/c64d1df6/attachment.html>