[Shotwell] export-Feedback
Ingo Lütkebohle
iluetkeb at techfak.uni-bielefeld.de
Sat Mar 13 05:29:17 PST 2010
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
More information about the Shotwell
mailing list