> I don't think f-spot needs to abandon the whole thumbnail spec. That's a > bit dramatic. We'd prefer not. Whatever the way we handle the thumbs, inside or outside of the specification, it's gonna take a lot of space > > It's no big deal to modify the default MAX_AGE and MAX_SIZE settings to > something that people consider "sane". Suggestions? Right now it's 60 > days and 64 MB, but I have no problem increasing them if there is a > consensus. Would 6 months / 512 MB be more sane? (f-spot could provide a > UI to adjust these.) Whatever the MAX_AGE, at the time you're passing the threshold, you're screwed.
About providing a UI, we're not in favor of that. A decent solution could be to prompt the user with a UI like "the f-spot thumbs cache is taking 90% of the thumbnail allowed space. Grow that threshold by 200% ?" > Deleting thumbnails for files that no longer exist is not practical. > You > would have to read every thumbnail file to extract the png txt that > identifies the original uri, then check that uri. Very slow. Plus, > some > people will not appreciate losing thumbnails for transient network > shares or CDs/DVDs. same for network uri like http;// ftp:// for more info on what the spec says about a possible cleaning tool as implemented by the housekeeping plugin : http://jens.triq.net/thumbnail-spec/delete.html Stephane _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
