[PATCH] Re: dropping content onto Plasma

[Aaron J. Seigo]

On Saturday 28 March 2009, Sebastian Kügler wrote:
> Here's a first try:
>
> Use KIO::TransferJob to retrieve the mimetype of dropped remote content
>
> This is a rough proof-of-concept to enable dropping remote urls onto
> Plasma. Currently they're simply added as an icon. The goal is to be able
> to transparantly add remote content to the plasma desktop by dropping urls
> to websites, pictures or references to database such as akonadi or nepomuk.
>
> With this patch, Containment retrieves the mimetype for URLs through KIO,
> and offers a qmenu popup after retrieving the applet's mimedata.

some thoughts/comments:

* there's a static_cast<KIO::TransferJob*> in slotMimeType that should be a 
dynamic_cast. 

* i wonder about latencies; if there is an issue of high latency between drop 
and mimetype resolution (which for many remote urls there likely will be), it 
would be very cool if we could show the popup menu more quickly with an 
(unselectable, but maybe animated?) entry that noted it was "processing 
possible widgets" and then replace that item with the applet suggestions when 
the mimetype data (if any) comes back in. 

  not only would this give us back "instant feedback" (something i don't like 
with this patch) this would have the nice side effect of changing the 
multiple-drops race condition i talk about below.

* there are a couple TODOs in there that are old and should be removed, 
indeed: the one about script engine matching and the one about showing a 
dialog

> - Applets need to actually support loading content through URLs. That means
> checking the args passed when loading the applet, and loading for example
> an image through KIO. The Picture Frame applet only does the arg part right
> now, the webbrowser does both.

yes; well, what we really probably ought to do is send in an actualy URL 
versus put the URL into the file. we should only use the create-a-temp-file-
and-pass-that-to-the-ctor-of-the-applet method when it's "actual" data and not 
a resource locator.

but yes, plasmoids probably want to support both methods, depending on the 
plasmoid.

> - The akonadi: url is currently hard-coded to the emailmessage applet. I'll
> need to find a more elegant way, since it technically doesn't have
> emaildata, probably a mimetype for an akonadi object.

yes, that would make sense. maybe ask the akonadi people what they think about 
mapping mimetypes to akonadi objects.

> - The algorithm in there is a bit wacky. In current trunk, containment
> tries to find an applet suitable for the mimetype, if it doesn't it just
> puts a URL there. I guess a change to isLocalFile: handle it sync, else do
> the KIO::TransferJob async popup should make more sense, semantically. And

this probably only matters if the time to do all the mimetype processing and 
job creation on local files is noticeable to the user. if it isn't, having 
multiple code paths probably isn't worthwhile.

in any case, i don't think it makes sense to show the popup menu if something 
matches immediately. it should always go through the async mimetype process 
imo always... it will make things consistent in all cases, and if coupled with 
the show-a-popup-immediately-and-populate-it-with-more-when-we-get-a-mimetype 
approach would probably be not even noticeable by the user.

as for something matching applet/octet-stream, that's why the url matching is 
first, with the "direct mimetype" matching after that only.

> - Since we don't have the pointer to the event in the slotMimetype()
> method, I had to cache the dropped location. I've put that QRectF into the
> d-pointer. The slot is in Containment. Should that slot also go into the
> d-pointer? It's private.

yes, it should be put into the private class. and we tend not to use "slot" to 
start slot names; perhaps processMimetypeRetrieval or processMimetypeJob?

> - This QRectF makes the menu pop up in the wrong location (usually way to
> much top right. I guess the cached location needs to be mapped to the scene
> here?

you should be storing event->screenPos() as well. the geometry is only used 
for where to create the applet, but the screenPos() is what is used to show 
the popup menu.

also, there's the issue of what happens when this happens:

* drop
* delayed mimetype fetching kicked off
* another drop
* delayed mimetype fetching kicked off

uh-oh. :)

there will probably need to be a mapping kept between the jobs and the 
positioning caching so that the position for each job can be retrieved 
properly when the mimetype fetching comes back.

> - What if the user wants to save the document?

that could be an option we provide when creating an icon, i suppose, and the 
user should choose where it goes.

> KIO will probably do caching
> for us, but I wonder if it makes sense to save the dropped URL to the
> ~/Desktop directory.

the ~/Desktop directory is an abomination (it doesn't map to anything 
meaningful given modern workflows) and one of the goals is to get rid of it, 
not reinforce it.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090329/811ca4a5/attachment.sig