GNOME Bugzilla – Bug 511569
Allow user to configure photo directory layout
Last modified: 2018-07-12 00:07:54 UTC
In Ubuntu we would like to make F-Spot suitable as the default photo import and management implementation. This requires that users can continue to use their already existing photo collection, which often has a structure wildly different from F-Spot's. To solve 95% of the design conflict between how F-Sport wants to import photos and how users want to have the files arranged on their disks, the camera import dialog should have a destination directory chooser. I cooked a patch for this which I will upload to the current Ubuntu development version now. It adds a directory selector which defaults to FSpot.Global.PhotoDirectory (currently ~/Photos, which is wrong and not XDG user dir compatible, but that's a different bug) and does not alter the /yyyy/mm/dd structure for this directory, but it does not use it for a custom directory. It might not be ideal yet, but it's a start. What do you think?
Created attachment 103551 [details] [review] add import target dir selector
This patch will work only on camera import. A similar option should be placed also in "import_dialog" for consistency, isn't it?
I'm not entirely sure about how to design it. That import dialog already has a checkbox for 'Copy files to photo directory'. IMHO this should disappear and be replaced by the same 'Target location:' directory selector. I'm happy to extend the patch accordingly. I just wanted to put the initial version here for discussing it with you guys. No point in working against each other. :) Thanks, Martin
(In reply to comment #3) > I'm not entirely sure about how to design it. That import dialog already has a > checkbox for 'Copy files to photo directory'. IMHO this should disappear and be > replaced by the same 'Target location:' directory selector. I've talked to a maintainer. The import dialogs are subject to change in the (hopefully near) future. This means it's not worth while spending too much time in making it consistent with the other import method. I don't know if your patch will be included before or after the refactoring. Have you tested it extensively? There was a bug in the past with a similar feature.
Thanks for the feedback. Wrt. testing, I could only check a camera SD card so far. Next week, when I'm back home, I'll test it with a PtP (libgphoto) one.
IMO the Edit->Preferences->Folder should support both a base folder (like it does now) and a subfolder-pattern, such as: "%Y/%m" or "%y_%M" or "%Y/%V" (for "2008/11", "08_11" and "2008/47", respectively). I suggest to use the format of strftime, since that's quite common and readily available. See e.g. here: http://www.manpagez.com/man/3/strftime/
I agree with the proposal of Marcus. I think the dialog should propose both : A subfolder format with a default value (like %Y/%m/%d - %name) and that should be configurable in the preferences, and the name of the album, asked for each import.
Created attachment 134006 [details] [review] add import target dir selector Fix bug to only show the photos directory if it actually exists.
File.Exists -> Directory.Exists in that patch, as discovered by Ubuntu users
*** Bug 619146 has been marked as a duplicate of this bug. ***
is that something upstream could consider using? we still ship the change in Ubuntu
Comment on attachment 134006 [details] [review] add import target dir selector Maintenance update: In the past we've been less than stellar in reviewing patches. As such we have a pile of patches in bugzilla which are outdated and don't apply anymore. Am currently marking all of these as "needs-work". My apologies for this. Since I've become a maintainer of the project, I've set the personal rule of quickly reviewing all patches, to avoid that this happens again. If you (or anyone) wants to go through the trouble of updating this patch, please talk to us to figure out if it fits in the F-Spot long term roadmap. Should you, in the future, notice a patch lingering around for too long, please notify us immediately and we'll look into it, to avoid situations like these from happening again. You can filter these mails by searching for ###F-OLDPATCHCLEANUP###
Indeed it seems that the code changed completely in trunk. I'll check out the current status of trunk. I'm happy to port the patch to trunk if you are interested in adopting this functionality? The original rationale still applies. Thanks, Martin
I'm tempted to close this as WONTFIX. Not because I feel that we should not offer this to the users, but because I feel that we should not offer it in this way. From the F-Spot vision statement [1]: > F-Spot is a cross platform application for organizing thousands of photos. > It shuns 'organizing in folders.' instead, metadata is the basis for viewing > and drilling down the collection. Adding and maintaining metadata is easy and > enjoyable in F-Spot. Files and folders are a really bad way of handling photos. The file name is basically meaningless and we all know that only really techy users are capable of maintaining a clean folder tree (well, some of them). Working with metadata (tags / people / places / events / ... [2]) allows us to give custom browsing modes, based on how the user wants to explore his collection. How it's organized on disk shouldn't matter, nor should the user care. Does this mean that the user should not be able to have any control over the folder layout? Not really, but I'd rather not have it in the import dialog. What I'd rather see happening is to have a preference for this, similar to what Banshee does [3]. They allow customization of the folder structure, in a clean way. The average user though doesn't (and shouldn't) care about all this. My mum certainly doesn't. Am not closing this bug right away, as I'd love to hear your thoughts on this. [1] http://f-spot.org/Goals [2] We currently only do tags properly, that will change. [3] Attaching screenshot.
Created attachment 164889 [details] Banshee folder structure preferences
(In reply to comment #14) > Files and folders are a really bad way of handling photos. The file name is > basically meaningless and we all know that only really techy users are capable > of maintaining a clean folder tree (well, some of them). Well, I'm a techy user, and do it that way. Incidentally, my parents do that as well, because (1) they often copy the stuff around on USB sticks, and (2) they wouldn't even know what a tag is. I don't go through the trouble of renaming individual files (mostly, anyway), but I have one directory per event. That way I can easily copy stuff to USB sticks or to my server and have a web gallery, and can present photos in other programs as well (or even OSes). The problem right now is that F-Spot owns your photo files, which is fine as long as you use nothing else. Contrary to that, Rhythmbox does it exactly right; your banshee screenshot seems to indicate that Banshee has a pretty similar model. It keeps the files as they are and respects user's choice for how the hierarchy looks like, and still the UI does not expose files and directories, but just genres/artists/etc., i. e. tag info. > Working with metadata (tags / people / places / events / ... [2]) allows us to > give custom browsing modes, based on how the user wants to explore his > collection. Absolutely, I'm not denying that. (I don't personally use tags because they aren't portable, unlike ID3, but I know and appreciate that many people do). > How it's organized on disk shouldn't matter, nor should the user > care. He should and will once she wants to give the photos of an event to someone else or copy it around, though? Anyway, the design decision how F-Spot handles its files is of course your prerogative, I'm just pointing out the rationale why I do things differently and why I don't think that it's such a techy thing. > Does this mean that the user should not be able to have any control over the > folder layout? Not really, but I'd rather not have it in the import dialog. > What I'd rather see happening is to have a preference for this, similar to what > Banshee does [3]. They allow customization of the folder structure, in a clean > way. I fully agree. Instead of a target directory, having an input line for "event name" would be much friendlier. It could serve as a default tag, and depending on the folder settings it would put files there (i. e. $XDG_PICTURES_DIR/<event name>) or just right now in F-Spots by-date/day hierarchy. Thanks for following up!
I retitled the bug to be more in line with what you said, does that sound better to you?
F-Spot has moved to https://github.com/f-spot/f-spot/issues If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub. Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.