After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 142932 - gThumb should provide assistance in locating images which are missing from Catalogs
gThumb should provide assistance in locating images which are missing from Ca...
Status: RESOLVED OBSOLETE
Product: gthumb
Classification: Other
Component: general
2.3.x
Other Linux
: Normal enhancement
: ---
Assigned To: Paolo Bacchilega
Paolo Bacchilega
Depends on:
Blocks:
 
 
Reported: 2004-05-21 20:52 UTC by Thomas Lunde
Modified: 2015-12-18 17:01 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6



Description Thomas Lunde 2004-05-21 20:52:22 UTC
Right now, when an image is moved around in the filesystem, that image is
silently removed from any Catalogs in which it was listed.  (See bug #142931)  

When gThumb discovers that an image is missing, it should provide a mechanism
for locating the images.  Ideally, this should happen without user input other
than (optional) confirmation of the process.  Here are two ways that this could
be done:

1.  gThumb could search the user's home directory for an file with the same
basename as the missing image.  As many images (especially from digital cameras)
have unique filenames and if only one image with that name was found, the
Catalog could be automatically updated (possibly with a warning note in the
status bar) to use the file in its new location.  

2.  Rather than relying on the basename of the image being unchanged, gThumb
could track images by a filesize and a hash on the thumbnail of the image.  No
matter where the image is moved to, or what it is renamed, the image size would
stay the same.  Obviously, multiple images might have the same size, so it
should be coupled with doing a hash on the potential matches that it found (i.e.
those with an identical filesize).  That should be small a small enough list not
to slow down the program.  Again, if a match is found, the Catalog could be
automatically updated.  

If more than one potential match is found (obviously, this is much more likely
with a basename match than with a hash match -- perhaps the user moved the
orignal image to a "Originals" folder and put a copy edited with the Gimp into a
"Revised" folder), then the program could present a dialog box and let the user
choose which image to use in the Catalog.  This could be just presented as a
list of check boxes:

Image $FILENAME has been moved since this Catalog was last updated.  

Do you want to replace it in this Catalog with any of these images:
[ ] /path/to/file/1.jpg
[ ] /path/to/file/2.jpg

Instead of [Cancel] and [OK], the box should have buttons that read:
[Do not replace this image] [Add the checked images to the Catalog] 


Or, even better, gThumb could present a dialog box that shows thumbnails (from
Nautilus?) of the potential image choices.  My Dad's (very old) digital camera
starts numbering at image #1 every time you change the batteries.  So, he'd get
a long list of potential matches, but he could probably very easily visually
choose the correct one for that Catalog.
Comment 1 Michael Chudobiak 2015-12-18 17:01:45 UTC
Marking as obsolete, as this was reported for a now-unsupported version and no recent activity has occurred. 

Please feel free to reopen this bug report if the problem still occurs with a current version of gThumb.