GNOME.org
 

Re: Various patches expected


Le 22 févr. 06 à 20:34, Larry Ewing a écrit :


On Wed, 2006-02-22 at 14:23 +0100, Jean-Christophe Dubacq wrote:

[advanced queries]


Gabriel Burt is doing a bunch of work on more advanced queries in the
query branch in CVS, try it out and give him feedback.
I will be trying this. I just need to merge it with f-spot 1.9 (at least) or f-spot CVS to be sure the database of my f-spot is not changed w.r.t. the version I use. I am more familiar with subversion than cvs, but I will find my way (I hope).
Preferences about wether "Copy photos to ~/Photos" should be checked by default during import would be great (I never want to copy to ~/ Photos, 
my home disk is a NFS mount and backed-up, and I cannot allow my
personal pictures to be backed-up at my lab).
This is a known problem point. The contention comes where if you copy it 
sometimes but not others how do you clearly inform the user when you
haven't copied the photos so that they don't assume you have then remove 
teh originals.  It is further complicated by the fact that you pretty
much always want to copy photos when importing from cameras so a single 
option just isn't good enough.  See the list archives for a lot of
discussion about this


I did not found the point, but it looks like you have a point.
Some support for "ghost images" (backuped pictures, not present on the disk, but thumbnailed) is being discussed, I see in the archives. This 
would be really good.

This is definitely in the plans.
I have been thinking about this a bit. This also solves (somehow) the movie problem. An item in the DB (I do not know if "versions" are different items or not) could have more fields: - one field which is "handler/type" (think a shell script to visualize the movie flicks or, for backed-up material, a warning that the image is not present on the disk and has been saved to "suchplace") - one which is "real location" (this could be the real path to the movie for a movie file, or a text string describing the backup media such as /home/login/backups/My-DVD #14) so that the helper can act not on the "ghost image", but on the real information (either saying "Your image cannot be seen : it is on backup named "My-DVD #14" or running "vlc /home/login/Movies/somedir/MVI_4855.AVI") - There would be an image stored (in ~/Photos or somewhere else). This "ghost image" could be edited at will (but of course, this would not change the original, since the original is either a movie or is not present). This image could receive all tags modifications. - Probably a hash should be stored for the ghost image also, to detect when things are moved and so one. If the "fingerprint" of an image also includes size, then add two fields to record ghost
- Movies: when a movie is imported, it is moved to someplace (or not moved), and a miniature image is generated from the movie. There do exist (in gnome) already means to do that (totem-thumbnailer). When clicking on a button (which would be beside ), an external program (standard lines could be provided to use either mplayer, totem, vlc, xine, muine, etc.) is launched to play "Real movie location". Maybe a few info could be stored in hidden tags (rotated left, rotated right), to have initial options of the external player changed. This is candy. - Backups: New item in menu, "Backup those images". Popup and ask a destination. Every image is copied to destination, checked, replaced by the ghost image. Maybe according to preferences, a script can be launched to start real backup of the destination (e.g. cdrecord- wrapper "/home/login/backups/My DVD #14") but I'd rather leave this to the user (backups can be so complicated). - Added to normal import: A location is searched. If images are found with fingerprints (hash, size, some exif info) that are already in the database, they are put in the same place as they occupied before and considered restored. They are first tagged as they should be according to the catalogue (if reading tags is implemented, a merge of the tags must be done: read tags from reimported image, compare with those of the ghosts, if different, ask wether the tags should be merged, if the original tags should replace the ghost tags or if the ghost tags should replace those in the original).
- Versions: I still do not know enough about versions in f-spot to tell. Are they first-class citizens in the DB? There should be a way to backup only originals, and a way to backup all versions.
Now this could be extended a bit for restoration/external/amovible storage. There should therefore be another state (so four states: in catalogue, movie, ghost, backuped+restored). 
- in catalogue: there is only one location for the image (current way).
- movie: there are two locations, a ghost (movie thumbnail) and the real movie. Whether the movie is actually there or not is not f- spot's problem (when importing, it could be copied by default to ~/ Movies, with the same rationale that copy to ~/Photos is used, but these are side-issues). - ghost: there are two locations in the DB, and a smaller image is stored in the first. It is used for everything. The second location is the one identifying the backup. - backuped and restored. The image is present in its second location. If any access to the second location fails, the image becomes a ghost. If some "Restore" command 

The cycle is as follows (movies not shown)

                         <- restore <-
Import -> "in catalogue" -> backup  -> "backuped+restored"
                  A                           |
                  |                  read/write access fails
               reimport                       |
                  |                           V
                  `------------------------"ghost"
An image in catalogue keeps its backup location, but the work done on the image is done solely on the catalogue image.
- There could be a check on ghost images (on command, or at startup, or when trying to edit/read picture): if the original image is returned to its initial backup place, and this place is accessible read-write, it returns to the backuped+restored state. Ghost image and backup image are synched w.r.t. tags, dates, comments (this merge is another UI design). - Several backup locations: since the overhead (in DB size) of having one backup is small, provide several external paths for backups. The helper would be provided with all possible external paths and should do something with those ("This image is not on the disk right now. However it can be found in these places: "My DVD #14", "/media/usbkey- movies/IMG_4032.jpg", "/remote/nfs/archive/photos/2005/04/01/ IMG_4032.jpg"). - Import: if an image is imported and found identical (fingerprint- wise) to an image in state "backuped+restored" or "ghost" (or even "in catalogue", this also solves the duplicate picture problem), the location is added to the backup locations (or not). I think stating all possible options are better shown with this (ASCII-art mockup): 

Import options:
+------------------------------------------------------------------+
|o copy original to "~/Photos"                                     |
|o copy original to "~/Photos" and use location as backup          |
|o keep original in place (and create ghost in "~/Photos")         |
|What to do if picture already exists:                             |
|o ignore this picture                                             |
|o add this place as a backup location (if not already the case)   |
|o clobber ghost image by this image                               |
|o create new version of the image                                 |
|o create independant version of the image                         |
|What to do if picture already exists and has different metadata   |
|o do nothing                                                      |
|o ask                                                             |
|o try to update picture with f-spot database                      |
|o restore f-spot data to data stored in picture                   |
|o combine f-spot data with data stored in picture                 |
+------------------------------------------------------------------+
Default would be "copy original to "~/Photos", "ignore this picture", and "do nothing". This makes sense for cameras. 

That's it. I can provide the ghost icon :)
Being able to choose themes when exporting to a static HTML folder would also be an improvement. There are already themes available for gthumb, 
for example, that could be reused.
You realize there are themes built into the javascript generated right?
I did not, and I do now. I will look (as an exercise) into porting one of gthumb's theme to f-spot (to be added beyond dark and light), and will then look (still an exercise) at how the default theme could be set as a preference (or question during the export, which is the same to me: UI programming). 

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