I for one would appreciate that. I'm not a Gnome user, so using the across-gnome solution that stores too much data and slows down F-Spot is rediculous for me. Here, you have your first patch tester.
The thumbnail issue is not GNOME specific. GNOME implements the draft freedesktop.org standard for thumbnail management. KDE also is working toward the same goal. For more information on the spec of thumbnail management please see: http://jens.triq.net/thumbnail-spec/index.html Also, having F-Spot create it's own thumbnails not only duplicates data on disk if you have another program (Nautilus, Konquerer, EOG, whatever) that creates the thumbnails, but adds additional code complexity to the program. Finally, with regards to the people having the issue with the number of files in a directory, the spot where that is slow is in a directory read and a file lookup. However, a quick look at most filesystem code will show that lookup is quite speedy, often using a hash, so the increase in time for accessing a file when there is one file or 50000 files in a directory is small. However, where the increase will occur is in reading in all those thumbnails, any way you slice it, that's a LOT of data. As the thumbnails are saved, at least it won't have to read in the complete image every time there is a change. Anyway, read the spec, it's a little enlightening to some of the design rationale. --Patrick
_______________________________________________ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
