[Panel-devel] Plasma Desktop: Drop Forwarding

[Sébastien Laoût]

Le Jeudi 16 Juin 2005 17:48, Aaron J. Seigo a écrit :
> it's not so much about benefiting the desktop so much as it's quite
> important to design the system to be able to service the needs, current and
> future, of applications and users. it's harder to do this without actual
> use cases =) basKet seems like an obvious use case and one that has the
> potential to push the boundaries of required/desired desktop capabilities.

OK. So, in that spirit:

Moving a basket or a group of items to the desktop seems good.
But why anyone would want to move it to the panel, as Plasma will allow?
The panel is a small area, and even one single item would hardly fit into it.

And then I remembered Drop Drawers: it have tabs on the desktop, clicking a 
tab open the "drawer".
It is nearly the same as what I've seen on kde-artists (expandable clock...).
And as it would be possible with Slicker.

So, after some toughts, « yes », dragging baskets to panels is a good idea.
It would then create a little icon and clicking it would expand a drawer 
containing the items. The drawer could auto-collapse if focus is moved to 
another application, or not.
And... this drawer need focus to write in it (it seems obvious to say that, 
but with the Universal Sidebar, we can't have keyboard focus, so there is 
currently no way to write text items).

So, panel should also forward such drop (again, I don't know how, 
technically).
The application should be able to know if it must create a desktop applet or a 
panel applet.

But it's not so easy:

With BasKet, we can have all sort of items, including application launchers.

Currently, when dragging an app-launcher into the panel, a .desktop file is 
dragged and the panel understand it by creating an application launcher 
(obviously!).

With Plasma integration, this will not be the same. How Plasma will know if:
- It must understand the dropped app-launcher item as an app-launcher and
  create an icon or,
- It must understand it as a basket-item and create a basket-applet with it.

I propose that if the user dragged _a group or more than one item_, it should 
be understood by Plasma (the panel OR the desktop) as a basket-applet.
If _only one launcher is dropped_, it have to be understood as a launcher and 
act like currently.

Note: I talked about launcher, but it can as well be a file, or a link to a 
file/folder/URL... or a text file (text items are dragged as text files 
too)...

This HAVE to be understood by Plasma.
And, if possible, in a generic way, so every other apps could do the same.

Another important concern to concentrate efforts on is the action of a drop: 
copy/move/link.

This also have to be forwarded to the destination aplication or applet.
(hum... is a Plasma-applet what called "Plasmoid"?)

I will again take BasKet as an example as I don't see other applications for 
the moment: we can imagine to copy the dropped items to the desktop/panel, or 
move the dragged items/group to the panel/desktop, or LINK the group to the 
panel, so, eg. when dragging a group to the panel, modifying items in the 
panel drawer will also modify them in the original basket.

Don't know if it will be useful, but that's some toughts of what could make 
possible Plasma.

But perhapse you already thinked about all those issues.
Just to say that it can be useful :-)

> matt broadstone has actually started on some documentation for libkicker,
> but it's very early stuff, so .. no =P but what you want to look at is
> AppletInfoDrag in kdebase/kicker/libkicker/paneldrag.h ... you need a
> kicker applet and an AppletInfo object that was created using the applet's
> .desktop file, and then you can place it anywhere on the panel(s) ...
> desktop integration of the same will happen with Plasma. current
> limitations:
>
> 	- libkicker is not a public library
> 	- AppletInfoDrag is new for 3.5
> 	- there is no way currently to pass parameters to applets using DnD. =(
>
> i assume you'd need the latter, and this is exactly why i would like to
> work closer with people actually using this stuff as it helps define needs

OK, I don't understand everything, and if it's limited to KDE 3.5 I willn't 
invest time in implementing something that will half-work and should be 
redone for KDE 4.

When I will have time, I will however try to take a look at this to see if I 
find something that should be enhanced in the future.