GNOME Bugzilla – Bug 443862
Clipboard : A long strings with filenames...
Last modified: 2010-07-13 14:05:03 UTC
Currently copying to Clipboard generates a string according to this: photo1 photo2 photo3 photo4 photo5 And with an example: /var/tmp/TestFSpot/Photos/2006/12/25/IMG_3638.JPG /var/tmp/TestFSpot/Photos/2007/01/01 /IMG_3848.JPG /var/tmp/TestFSpot/Photos/2007/02/16/IMG_3958.JPG /var/tmp/TestFSpot/Photos/2007/02/18/IMG_2298.JPG I propose the following syntax. "photo1" "photo2" "photo3" "photo4" "photo5" and with an example. "/var/tmp/TestFSpot/Photos/2006/12/25/IMG_3638.JPG" "/var/tmp/TestFSpot/Photos/2007/01/01/IMG_3848.JPG" "/var/tmp/TestFSpot/Photos/2007/02/16/IMG_3958.JPG" "/var/tmp/TestFSpot/Photos/2007/02/18/IMG_2298.JPG" This makes it a lot easier to manipulate the file names in a separate program. And this is what I most often want to do. Not to look at the names in a long string, but by row and row. Possible add a cp or a rm or something to the first column etc..
Created attachment 89317 [details] [review] Patch to ensure each photo name is on its own row, enclosed in quotes --- src/MainWindow.cs (revision 3127) +++ src/MainWindow.cs (working copy) @@ -2441,12 +2441,8 @@ StringBuilder paths = new StringBuilder (); - int i = 0; foreach (Photo p in SelectedPhotos ()) { - if (i++ > 0) - paths.Append (" "); - - paths.Append (System.IO.Path.GetFullPath (p.DefaultVersionUri.LocalPath)); + paths.Append (String.Format ("{0} \n", System.IO.Path.GetFullPath (p.DefaultVersionUri.LocalPath))); }
Did this go against the GNOME way of do it? The patch was simple and should be clean to commit. Just open Nautilus, and copied two files to the clipboard. Then opened Text Editor and paste. The two filenames appears on two separate rows.
the PhotoPopup menu is now extendable...
(In reply to comment #3) > the PhotoPopup menu is now extendable... I don't think this should be an extension. Either the actual behavior is kept or the new one will! ;)
Larry refered to this document earlier. http://www.rfc-archive.org/getrfc.php?rfc=2483 section 5 is about as close as you get I think. And this one states the following 2) The remaining non-comment lines shall be URIs (URNs or URLs), encoded according to the URL or URN specifications (RFC 2141, RFC 1738 and RFC 2396). Each URI shall appear on one and only one line. Very long URIs are not broken in the text/uri-list format. Content-transfer-encodings may be used to enforce line length limitations. To me this indicates each file name should be on a separate row. This bug should fix the one URI per row, as per above specification. Bug #327068 should fix the proper encoding of the URI's
Comment on attachment 89317 [details] [review] Patch to ensure each photo name is on its own row, enclosed in quotes 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###
This bug is not invalid (or perhaps masked by a new bug). In current f-spot copying photos does not copy the uris to the clipboard the the photos themselves. Being able to copy photos and paste the URI does sound like a nice feature though, and should likely be reimplemented.
Whoops, I meant "This bug is invalid".
(In reply to comment #8) > Whoops, I meant "This bug is invalid". Closing then. Feel free to reopen if needed.