On 04.10.2010 20:42, Jim Nelson wrote: > The ticket that Michael (and others) is referring to is this one: > http://trac.yorba.org/ticket/2476 > > In the Shotwell 0.7, there's a startup scan to verify all the files backing > your photo objects in the library are present. If the file is missing, the > photo is moved to the "Missing Files" page (which is only visible if there > are missing files). > > In 0.8, we've extended this feature to attempt to locate renamed files. If > you rename a single photo or rename a subdirectory they are stored in (i.e. > ~/Pictures/F-Spot -> ~/Pictures/Shotwell), the startup scan will discover > the change and associate the renamed files with their old photo objects. > > An additional feature (http://trac.yorba.org/ticket/2478) will scan unknown > files in the library directory (which is set in the Preferences dialog) and > auto-import them into the library. > > We plan on both of these being optional in 0.8 ( > http://trac.yorba.org/ticket/2492). > > Now, these features have a key limitation: They only work inside the library > directory. If you've linked photos from an external directory, Shotwell > will *not* scan that directory for renamed files or auto-import from there. > This is something we may do in the future; we're taking baby steps with this > functionality. This why 0.8 doesn't solve Michael's problem but will solve > Mattias and Kenneth's, because they're asking for changes inside the library > directory be reflected in Shotwell. > > We could offer a "Locate Photo" option, as suggested by Kent, but in the > case of 21,000 photos, it's not so simple. (We could offer a "Mass Locate > Photo", but there's a lot of possibilities, and therefore pitfalls, with > that kind of feature.) A re-scan feature would simply do what we're doing > at startup; a better solution is active monitoring of the library, which is > under consideration: http://trac.yorba.org/ticket/374 > > Finally, regarding Michael's concern about the tediousness of the scan: Yes, > it can be time-consuming, but as you said, it's time-consuming for the app, > not the user. We're working hard to make the scan as unobtrusive to the > user as possible. Fortunately in the normal use-case, all we're doing is > verifying the file exists (by checking the modification date and file size), > which are low-impact operations. And because it happens in the background, > the user shouldn't be stopped from immediately starting work. > > -- Jim
I only started using Shotwell 0.7.2 on Ubuntu-Lucid-amd64 recently. My thanks to the team developing this great piece of software! I want to append another "feature request" which IMHO fits to this issue: I have my photo collection stored remotely on a NAS which I usually mount with nfs4 on my PC. This mount is not permanent, only on demand. The database of course is stored locally on my PC. All works perfectly when the nfs4 share is available. I even can umount the share with all thumbnails remaining visible and I can even browse through them. However when the nfs4 share is not available when starting Shotwell, all thumbnails shortly appear and when Shotwell is up, all "Events" are cleared out and no thumbnail preview is available (local database of course is available). Is there any possibility to view and browse the thumbnails even if the photo data are not accessible. Of course editing or opening in nautilus cannot be performed under this condition. Technically it should not be a big issue, as all the thumbnails are stored locally in the database together with the link to the photo itself (except the data to which the link points). This would allow to just scan the whole database to check or search for a photo without editing. Best regards, Ingo > > On Mon, Oct 4, 2010 at 9:26 AM, Kent Tenney <kten...@gmail.com> wrote: > >> On Sun, Oct 3, 2010 at 5:10 PM, Michael Hendry <hendry.mich...@gmail.com> >> wrote: >>> On Sun, 2010-10-03 at 20:52 +0300, Mattias Põldaru wrote: >>>> Ühel kenal päeval, P, 2010-10-03 kell 13:08, kirjutas Kenneth Jacker: >>>>> [ Ubuntu 10.04.1; shotwell-0.7.2 ] >>>>> >>>>> When I first ran 'shotwell', I choose the "import from F-Spot" option. >>>>> All my prior pictures and tags were then available. >>>>> >>>>> But, all the photos are still under the old "../Pictures/F-Spot/" >>>>> directory. I want to now get rid of F-Spot. >>>>> >>>>> My obsessive/compulsive nature would like the path to all my photos >> now >>>>> be "../Pictures/Shotwell/" ... corresponding to my new setup and >>>>> application. >>>>> >>>>> Does anyone know how I might this change? >>>>> >>>>> >>>>> Thanks, >>>> >>>> http://trac.yorba.org/ticket/2485 >>>> See this ticket. If this is implemented in a smart[1] way, you could >>>> simply rename your F-spot directory to Shotwell, then relocate one file >>>> and everything would be fine. >>>> >>>> [1] By smart I mean Shotwell would assume it could have been directory >>>> change and would apply the directory change to other missing images as >>>> well, where applicable. >>>> >>>> >>>> Somewhere was talk about automatic relocating as well, but unfortunately >>>> I cannot find the ticket. >>>> >>>> >>>> Mattias >>>> >>>> _______________________________________________ >>>> Shotwell mailing list >>>> Shotwell@lists.yorba.org >>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >>> This is a concern of mine, but in the more general case of a >>> reorganisation of my image files and the directories that contain them. >>> >>> I have just imported > 21000 images, using links to the files rather >>> than copying all the files, and in future I may well wish to change the >>> directory structure that the images are contained in - e.g. to merge >>> directories containing only a few images, or to move the whole tree to a >>> new disc when the current one fails or gets filled up. >>> >>> Jim Nelson has confirmed that Shotwell will lose track of these files, >>> and they'd have to be reimported and have all the tags restored - a >>> tedious process, and likely to introduce errors. He tells me that >>> additional features are to be introduced in version 0.8, which will >>> attempt to find "lost" files and re-associate them with the database. >>> >>> This sounds like a time-consuming process (but for the computer, not its >>> operator!), and I wonder if it would be more elegantly done by providing >>> a file manager within Shotwell itself - it would then "know" where the >>> files had gone, and could make adjustments to the database with this >>> knowledge. >> >> Other apps I've used have a "relocate" feature which allows replacing a >> portion of the filename path. >> >> Given "/home/me/my/old/path/2010-09/" containing files or directories, >> >> I could ask that "/home/me/my/old/path" in a filename path >> would be changed to "/mnt/cdrom/" or "/usr/local/photos/" >> >> or some such. >> >> Thanks, >> Kent >> >>> >>> Michael >>> >>> >>> >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell@lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >> _______________________________________________ >> Shotwell mailing list >> Shotwell@lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > _______________________________________________ > Shotwell mailing list > Shotwell@lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > -- ____________________________________________________________________ In a world without walls and fences we don't need windows and gates. _______________________________________________ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
