On 04.10.2010 23:54, Jim Nelson wrote:
> When your photos are not available (NFS not mounted), they should be
> available in the "Missing Files" page.  Are they not there?
> 
> -- Jim

Oh thanks and sorry for not finding out myselfs!
Of course all thumbnails can be browsed under "Missing Files",

Ingo


> On Mon, Oct 4, 2010 at 12:50 PM, Ingo Steiner <ingo.stei...@gmx.net
> <mailto:ingo.stei...@gmx.net>> wrote:
> 
>     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
>     <mailto:kten...@gmail.com>> wrote:
>     >
>     >> On Sun, Oct 3, 2010 at 5:10 PM, Michael Hendry
>     <hendry.mich...@gmail.com <mailto: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 <mailto: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 <mailto:Shotwell@lists.yorba.org>
>     >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>     >>>
>     >> _______________________________________________
>     >> Shotwell mailing list
>     >> Shotwell@lists.yorba.org <mailto:Shotwell@lists.yorba.org>
>     >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>     >>
>     > _______________________________________________
>     > Shotwell mailing list
>     > Shotwell@lists.yorba.org <mailto: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 <mailto: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

Reply via email to