[Shotwell] export-Feedback

[Adam Dingle]

Ingo,

the root cause of the difference between Nautilus and other applications is
that Nautilus has a special feature which allows us to receive the URI of
the destination folder when a user drags into Nautilus.  This allows the
source application (in this case, Shotwell) to construct the required files
and copy them into the destination URI after the drag completes.  For other
drag destinations such as Postr, at drag time we must provide a set of URIs
which already contain the files to be transferred.

I agree that allowing dragging to Postr and other applications would be
great.  Your suggestion of using a local HTTP server is interesting.  There
might be other tricks we can play such as using a socket or a named pipe, or
somehow extending the drag/drop protocol itself.  Or perhaps we can extend
Shotwell so that it automatically keeps full-resolution images up to date in
the background (though there are some concerns there about CPU usage and
disk space).  I've created a ticket for this at
http://trac.yorba.org/ticket/1563 - we'll keep thinking about this.

cheers
adam

On Sat, Mar 13, 2010 at 6:29 AM, Ingo Lütkebohle <
iluetkeb at techfak.uni-bielefeld.de> wrote:

> Hi Adam,
>
> Am 09.03.2010 23:25, schrieb Adam Dingle:
> > the destination folder *after* the user lets go of the drag. But this
> means that
> > it's now possible to drag and drop only to Nautilus, not to other
> applications
>
> Thanks for the explanation, thats good to know. Am I correct in assuming
> the root cause of the difference to be that Nautilus makes a copy --
> hence, it can accept transient data, whereas postr (and other tools)
> just use a reference, and thus can accept static data only?
>
> I guess there is no easy way around that. The trouble would seem to be
> that drag'n'drop's interaction model is too restricted. Is there no way
> to allow an interaction between the two applications, that could make
> these things easier? For example, this could enable Shotwell to provide
> the edited data on-demand (and multiple times, so that postr can display
> a thumbnail immediately and request the full data on upload, for
> immediate sending).
>
> btw, picasa and f-spot don't do too well on this either: Picasa requires
> an explicit sync to disk for changes to appear, whereas f-spot just
> doesn't do dragging properly at all. In fact, this was one of the
> reasons why I preferred Shotwell ;-)
>
> Please don't take it as criticism of Shotwell when I say that this is a
> serious PITA. I now understand why it happens, but this is just so wrong
> and all the "workarounds" strike me as just that.
>
> This is annoying beyond flickr-export -- there are all sorts of
> applications which accept data by drag'n'drop and none of these will
> work properly.
>
> > (just like when dragging from File Roller, for example).
>
> I have noticed that -- though I have to say that the use cases for
> working with archive files are different from those of photos.
>
> > well would be to change Shotwell so that it would keep full-resolution
> versions
> > of all edited images at all times. We could possibly do that, but it
> would be a
> > large change and we'd need to generate the images in the background to
> avoid
> > slowing down the user interface. We'll think about this more as a
> possibility
> > for future releases.
>
> Well, it would not be a solution for postr (at least not right now), but
> maybe you could pass around different URLs, such as http-URLs, which
> would enable you to provide data on-demand by opening a local
> http-Server. Just a thought -- maybe there are other protocols that
> would make this work better.
>
> btw, postr doesn't accept http URLs, but GIMP, for example, does. I
> guess it wouldn't be too hard to extend postr to do, too.
>
> cheers, Ingo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zaftra.yorba.org/pipermail/shotwell/attachments/20100314/a5fcdfa4/attachment.html>