Re: reimport files as new version



Stephane,
  I found the patch.  I have a few questions about it.
* Has it made it into the trunk yet?
* You note that the extensions need to be the same.  Doesn't this
prevent you from using a jpg as a version (revision) or a raw original
(.CR2 file)?
* Other than needing a change of arguments for over loading, is it
really important to pass the extension?

I'd love to work on this, but I'm still having problems building from
HEAD on Debian Etch.

Date: Tue, 07 Nov 2006 17:42:46 +0100
Re: reimport files as new version

Hi all,

here's a patch I cooked some month ago (but never published in bgo) that
solves a big part of this issue.
I updated it to latest CVS and polished it a bit.
Now, you can drag a photo (or some photos) on another to reparent as
version.

note:
- work only if the extensions matches !
- need a confirmation dialog

I'll try to find some time this evening to update it

best regards

stephane


On 6/15/07, Richard Bronosky <BrunosJunk bronosky com> wrote:
What's the best way to find this patch (and things like it)  I've tried a lot of searches similar to:
 http://www.google.com/search?hl=en&lr=&q=Stephane+Delcroix+reassign+version+patch+site%3Amail.gnome.org%2Farchives%2Ff-spot-list%2F

Has this made it into the trunk yet?



 On 4/17/07, Stephane Delcroix <stephane delcroix org> wrote:
>  Hi,
>
> Complete versioning (read create jpg versions of raw images) is still
> impossible due to design limitations. The code for handling this
> correctly exists but it's not yet part of the source tree. The good news
> is that it will be very soon (in some weeks maximum).
>
> If you can't wait for that, and already want a way to reassign images as
> version of others, I posted a patch to this mailing list a few months
> ago. Search the mailing list for that.
>
> regards
>
> stephane
>
>
>
> On Tue, 2007-04-17 at 16:21 +0200, Ton Biegstraaten wrote:
> > Hi,
> > Recently I adopted f-spot (3.5) as photo manager. A feature I like, is
> > to be able to have different versions of a photo.
> > It has however 2 limitations (for me at the moment :-) ). First of all I
> > have made some thousands of photo's before adopting f-spot and did a lot
> > of processing on them. To include the adjusted photo's as versions of
> > the originals is not directly possible.
> > The second limitations is that it is not possible to have versions with
> > different extensions. I use a lot of RAW images, and those can't have
> > versions. You usually make jpegs or gimps of them, but they aren't seen
> > as versions of the original. At the moment I make jpegs of RAW images
> > before importing them, so I have both in F-spot. Adjusting the RAW
> > results in a new jpeg with the same name as the one that is existing,
> > but now you have always two equal photo's in stead of different
> > versions. At the moment you can't easily hide the RAW's.
> >
> > Looking at the database (with sqlite3) shows that you can add versions
> > yourself, so old versions can be imported with some clever scripts.
> > I like to know how other people solve these issues and if it is planned
> > to allow versions with different extensions in the future. The naming
> > convention of versions in the database doesn't make this straightforward.
> > Apart from this, I think f-spot is a very fine and fast tool with a
> > perfect user interface
> >
> > regards,
>  > Ton
> >
> > _______________________________________________
> > F-spot-list mailing list
> > F-spot-list gnome org
> >  http://mail.gnome.org/mailman/listinfo/f-spot-list
> >
> --
> Stephane Delcroix
> stephane delcroix org
>
> _______________________________________________
> F-spot-list mailing list
> F-spot-list gnome org
> http://mail.gnome.org/mailman/listinfo/f-spot-list
>



--
.!# RichardBronosky #!.



--
.!# RichardBronosky #!.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]