GNOME Bugzilla – Bug 321025
Smaller Tag Views/Icons
Last modified: 2007-03-05 19:40:54 UTC
As noted by Nat: "I have lots of tags, and my sidebar on the left is pretty full, I have to scroll a lot to see all the tags. It'd be nice to have a mode where you can turn off the icons or make them as tall as the letter 'X' or something. That could be a right-click thing too."
*** Bug 323839 has been marked as a duplicate of this bug. ***
I sent this to the list a while ago (http://mail.gnome.org/archives/f-spot-list/2005-December/msg00124.html): The current tag icons are very large, especially if one has many tags. One fix would be to make them smaller. Another would be to let the user set the size in pixels. A more middle ground approach would be to have them default to the current size, and give the user the option to set the size smaller (about the size of the text), or maybe even off. What do you think? I favor the third approach.
i like the thrid approach, but maybe it is enough if they could be disabled, because from under a size they would not be very useful.
*** Bug 327801 has been marked as a duplicate of this bug. ***
This really can't be done properly until the tags database is changed to keep track of which photo it's thumbnail came from so new scaled versions can be made as needed. I'm working on this.
Why not allow three different options? 1) Icons and Text 2) Only Icons 3) Only Text and we could also add larger Icons/Text for those who wants that.
Created attachment 59909 [details] [review] Patch to allow for showing/hiding the tag icons This patch allows the user to turn the tag icons off or off, and saves that choice as a preference. It doesn't fix this bug, but it's a step.
the saving part is not working, if i choose view->tag icons->hidden and then quit the next time i run f-stop i see the icons again. By the way, if we are just going to have hidden/show tag icons it would be better to have a checkbox in the menu instead of a submenu. Good work, now i only need a searching feature to switch to f-spot!
Created attachment 66099 [details] [review] patch to allow users to hide the tag icon I have attached a revised version of the original patch which cleans up some things and makes f-spot remember your decision between launches. Applies cleanly agains cvs as at 24-May
Hi John First impression, just reviewing the code, and do excuse me if it sounds like nitpickying. Are you using tabs only, or spaces for identations? If you want to use space, please convert one tab to 8 spaces. Just so all modules have the same indentation and layout of code. Good job though, I will install and check this patch momentarily... (relatively anyway)
Just applied the patch and compiled it. No problems. Looks nice, but a few comments. 1) I agree with comment #8, a simple checkbox in the menu would be nicer. 2) The import and attach tag still displays the icons. 3) Create new tag, still displays icons in the Parent tag drop down. Edit tag do not display any icons though. (Just create bug #342756 for this one) 4) Please use tabs as indentations, or ensure you have tab=8 spaces in your editor. Thanks, it looks very nice so far :)
Created attachment 66164 [details] [review] allows setting size and visibility of tag icons Updated patch that lets users set the displayed size of the tag icon in the tag tree sidebar. At the moment this doesnt change the size of the tag icon in the right click menus or other places.
Patch review: 66164 for bug 321025 This patch really helps the usability of the tag tree. Some comments though... +) create your patch from the upper directory (f-spot, not f-spot/src). It's easier when you apply a lot of patches to f-spot +) When you choose 'Large', the 'Icons' tags (not generated by a photo) should keep their default size. Otherwise, it's a bit ugly I'm waiting for a new version of this one, applying the preference also to the 'import', 'create', 'add' and 'remove' tags dropdowns.
Marking needs-work. Besides the points raised by Stephane (which should be fixed): The default from the patch is different from the default in current f-spot. I'm not sure if that's a very good idea (if not just to avoid confusion among users). Anyone else has feelings about this?
Created attachment 69264 [details] [review] Setting tag size and visibility In order to push the things forward (the old patch was 2 month old), I've made a new version of this, based on attachment #66164 [details] from John Stowers. What's new in this: - cleaning the identation - making the diff from /f-spot/ - moving the sizing code to TagStore.cs - set the default bigger (like the size without the patch) - never resize up. (nicer for stockicons) That closes all the remarks pointed by Ruben and I. Applying this everywhere will be now as simple as replacing Icon by SizedIcon...
Created attachment 69353 [details] [review] improved version This patch now handles resized tag icons (almost) everywhere: - in the left pane - in the 'Attach' and 'Remove' Tag popups - in the 'Create' Tag - in Import, Attach tag I guess that means everywhere. did I miss something ?
Hi Stephane, I think you covered all cases, but i have some small comments: 1. why don't you use constants for the icon sizes, now you have hard-coded values (0, 16, 32, ...) in more than one place. 2. in the HandleTagSizeChange method, i would add a check that makes sure that the icons are not redrawn if the size isn't actually changed. Otherwise, i really like this patch, it makes the icons look more consistent.
Thomas, thx for all the flowers, but it's not originaly my patch. about 1) and 2), I'll try to fix that asap
Created attachment 69499 [details] [review] updated version updated version considering the comments from Thomas. please review...
+1 on this patch. I've merged it into my bzr branch at http://repo.spacepants.org/f-spot/show-hide-tag-icons and from there into my own dogfooding branch at http://repo.spacepants.org/f-spot/jaq , for anyone wanting to pull down a full working copy of HEAD + this patch ;-)
Thanks for you work updating the patch Stephane! I have been out of the f-spot loop for a while! Just tried it from the bzr branch, all works good. +1 That this goes in sometime....
Did a quick check on this patch as well. The patch works fine, as stated, and should go in to CVS since it adds a nice touch to f-spot's gui. Some nitpickying below. 1) + if (choice == tag_icon_hidden) { + tag_icon_size = TagIconSize.Hidden; + } else if (choice == tag_icon_small) { + tag_icon_size = TagIconSize.Small; + } else if (choice == tag_icon_medium) { + tag_icon_size = TagIconSize.Medium; + } else if (choice == tag_icon_large) { + tag_icon_size = TagIconSize.Large; + } else { + return; + } Is this code not better represented by a switch stratement? 2) public static Pixbuf TagIconFromPixbuf (Pixbuf source) { // FIXME 50x50 crashes Pixdata.Serialize... what a mess. - int size = 52; + int size = 48; Could this 48 be replaced by MainWindow.TagIconSize.Large ? So we do not use hardcoded variables that might change. The preferences (gconf) is not updated until f-spot has ended, is this intentionally or?
Created attachment 71692 [details] [review] minor updates Updated according to suggestions from Bengt. Re: Is this code not better represented by a switch stratement? I could not switch on non string or integer types... maybe its just me Re: Could this 48 be replaced by MainWindow.TagIconSize.Large ? Done Re: The preferences (gconf) is not updated until f-spot has ended, is this intentionally or? Fixed. Preferences are saved/updated immediately
Tested the latest version of code. works well. I'm happy with the code also. John, it's not you, you can't switch on a Gtk.RadioMenuItem. And even if it would be possible, the code for expressing that with a switch statement will require at least 4 extra "break;" lines. The only cleanup we can make on this statement is removing the curly braces...
merged the latest patch into my bzr branch, same url as before
Changing status to Accepted-CommitNow
Created attachment 72647 [details] [review] Patch against HEAD I just updated the patch to work against head... For those of us who can't live without it anymore =)
Changing the status to Accepted-Commit-Now. It applies cleanly to head, apart from changelog.
looking at the patch, does this mean we create a new pixbuf every time we read the SizedIcon property? It should probably cash the tag so that we aren't accidentally doing a lot of extra work.
Created attachment 72981 [details] [review] with a cache With a cache
don't commit the latest one, it still needs work
Created attachment 72984 [details] [review] better version of the cache
Latest patch doesn't apply that cleanly to most recent CVS: avp@traveller:~$ patch -p0 < small_icons.diff patching file src/MainWindow.cs Hunk #4 succeeded at 1509 (offset 3 lines). Hunk #5 succeeded at 1638 (offset 3 lines). Hunk #6 succeeded at 2480 (offset 3 lines). patching file src/PhotoTagMenu.cs patching file src/PixbufUtils.cs Hunk #1 succeeded at 346 (offset 28 lines). patching file src/Preferences.cs patching file src/TagMenu.cs patching file src/TagSelectionWidget.cs patching file src/TagStore.cs patching file src/f-spot.glade Hunk #1 succeeded at 8789 (offset 2 lines). But still the patch works as advertized for me.
Created attachment 74205 [details] [review] Patch updated for HEAD Applies cleanly to HEAD (as of 5 minutes ago) ago.
It feels wrong to poke into MainWindow for the Size setting here, either the caching should happen in MainWindow or the setting should live in the TagStore.
Created attachment 74398 [details] [review] updated version it no longer pokes in MainWindow but the other way around, which is cleaner
Installs and makes fine against CVS for me. Operation is as expected and has not caused any unexpected issues. The only comment that springs to mind is would it be good if the tag size option changed the size of the tags on the search bar as well?
Created attachment 74488 [details] [review] alternate version, change also the query bar Implementing the good idea from Kevin. This patch also change the tags size in the TagQueryWidget. Please test and discuss...
New patch apllied and made without problems. Behaves as expected and all icons looked fine. Search bar icons changed size to match and looked great, nice patch stepane. I would be happy to have this in CVS now.
Also applied latest patch from Stephane. Works fine. Nice patch! Voting for CVS :)
Created attachment 75167 [details] [review] updated version (includes changes to query bar) I have updated the patch to apply cleanly against CVS. I have also changed the behaviour of the Query bar slightly to be more usable in the case where the tag icons are hidden/small. These changes include * Always show the tag name (label) in the query bar. Rationale: If the Tag icons are photos they are pracically indistinguishable in the query bar. Always showing the Tag label makes it more clear what the tag represents. Showing the tag label is required if the user has otherwise hidden tag icons * Italicize the logical operators (or, and). Rationale: With the tags labels now shown all the time it is important to differentiate the logical operators from the tag name. Italics does this nicely. See the screenshots for more information
Created attachment 75168 [details] Query bar changes Screenshot showing the query bar with small Tag Icons
I also updated the F-spot Tag icons to all be 48x48. This looks much better if you have the Tag icons set to the Large size. See http://bugzilla.gnome.org/show_bug.cgi?id=364079 for the new icons
Hi John, Please open another bug for the changes you suggest to the FindBar (always displaying the text, operator in italic). If we can't keep one small discussion by bug entry, we'll never be able to fix any of them ! So, please keep the discussion in this bug focused on "Smaller Tag Views/Icons" best regards, Stephane
(In reply to comment #44) > Hi John, > > Please open another bug for the changes you suggest to the FindBar (always > displaying the text, operator in italic). Are you certain? because I consider the current behavior (not italicized, "and" operator not shown) OK if the labels are not shown all the time. Perhaps I should open another bug - "Tag labels should be shown all the time in find bar?" and then point back to this bug? > > If we can't keep one small discussion by bug entry, we'll never be able to fix > any of them ! Agreed! Thanks, John
Is the only update to this patch the changes to Find bar? In that case, I definitely would recommend to move this patch to a new enhancement bug specific for that issue. I definitely can imagine some people would like to use Tag Names, some would like to use Icons, and some would like to use a combination in the Find Bar.
(In reply to comment #46) > Is the only update to this patch the changes to Find bar? Aside from updating it to apply cleanly, yes. > In that case, I > definitely would recommend to move this patch to a new enhancement bug specific > for that issue. I definitely can imagine some people would like to use Tag > Names, some would like to use Icons, and some would like to use a combination > in the Find Bar. > However I dont think it makes sense to have a users preference (i.e. small tag icons) ignored when in the find bar. One of the nice things about the tag icon size patch as it stands is that is makes all tag icons *uniform* sized. This looks pretty :-) I also dont think adding another preference (use tag icons of this size, except in the find bar when you should use tag icons of this size) is the right thing to do. Isnt GNOME about choosing sensible defaults (tm)? From a technical perspective by using SizedIcon everywhere we avoid some additional scaling of the tag icon in the query bar, and can take advantage of the scaled tag icon cache. But with all that aside if you still really want me to split out that part of the patch then I will do so. John
Correct me if I am wrong... but did you not also add the tag name to the find bar or? (Am in windows world, and can not check the patch :( ) Having a uniform size on all icons is of course preferable, which is what this bug is about. That should also include the find bar.
(In reply to comment #48) > Correct me if I am wrong... > but did you not also add the tag name to the find bar or? Oh yeah, oops! Should this only be shown if the user decides to hide tag icons? Previously it was shown if the tag did not have a icon. > > Having a uniform size on all icons is of course preferable, which is what this > bug is about. That should also include the find bar. >
Patched cleanly: patching file ChangeLog patching file src/MainWindow.cs patching file src/PhotoTagMenu.cs patching file src/PixbufUtils.cs patching file src/Preferences.cs patching file src/TagMenu.cs patching file src/TagQueryWidget.cs patching file src/TagSelectionWidget.cs patching file src/TagStore.cs patching file src/f-spot.glade After about 5 minute of doing a few tags searches, suddenly I could not view any photos (I got the large question mark instead of the photo). About a minute later F-Spot locked up completly. I see that F-Spot could not find some files, yet they are most certainly there on disk, and she was able to find them just a minute before. I had to kill her with CTRL-ALT-ESC: in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x00024> FSpot.JpegFile:.ctor (System.Uri uri) open uri = file:///home/user/f-spot_photos/2002/12/16/phto0028-1.jpg System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/16/phto0028-1.jpg". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x0000a> FSpot.ImageFile:PixbufStream () in <0x00030> FSpot.ImageFile:Load (Int32 max_width, Int32 max_height) in <0x00086> PixbufLoader:ProcessRequest (.RequestItem request) in <0x00025> FSpot.ThumbnailGenerator:ProcessRequest (.RequestItem request) open uri = file:///home/user/f-spot_photos/2002/12/16/phto0027-1.jpg System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/16/phto0027-1.jpg". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x00024> FSpot.JpegFile:.ctor (System.Uri uri) open uri = file:///home/user/f-spot_photos/2002/12/16/phto0027-1.jpg System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/16/phto0027-1.jpg". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x0000a> FSpot.ImageFile:PixbufStream () in <0x00030> FSpot.ImageFile:Load (Int32 max_width, Int32 max_height) in <0x00086> PixbufLoader:ProcessRequest (.RequestItem request) in <0x00025> FSpot.ThumbnailGenerator:ProcessRequest (.RequestItem request) open uri = file:///home/user/f-spot_photos/2002/12/16/phto0026-1.jpg System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/16/phto0026-1.jpg". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x00024> FSpot.JpegFile:.ctor (System.Uri uri) open uri = file:///home/user/f-spot_photos/2002/12/16/phto0026-1.jpg System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/16/phto0026-1.jpg". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x0000a> FSpot.ImageFile:PixbufStream () in <0x00030> FSpot.ImageFile:Load (Int32 max_width, Int32 max_height) in <0x00086> PixbufLoader:ProcessRequest (.RequestItem request) in <0x00025> FSpot.ThumbnailGenerator:ProcessRequest (.RequestItem request) System.IO.FileNotFoundException: file:///home/user/f-spot_photos/2002/12/16/phto0030-1.jpg in <0x00030> Gnome.Vfs.Vfs:ThrowException (System.String uri, Result result) in <0x00018> Gnome.Vfs.Vfs:ThrowException (Gnome.Vfs.Uri uri, Result result) in <0x00048> Gnome.Vfs.FileInfo:.ctor (Gnome.Vfs.Uri uri, FileInfoOptions options) in <0x00031> Gnome.Vfs.FileInfo:.ctor (System.String uri, FileInfoOptions options) in <0x0000f> Gnome.Vfs.FileInfo:.ctor (System.String uri) in <0x0004e> FSpot.ThumbnailGenerator:ThumbnailIsValid (Gdk.Pixbuf thumbnail, System.Uri uri) System.IO.FileNotFoundException: file:///home/user/f-spot_photos/2002/12/16/phto0031-1.jpg in <0x00030> Gnome.Vfs.Vfs:ThrowException (System.String uri, Result result) in <0x00018> Gnome.Vfs.Vfs:ThrowException (Gnome.Vfs.Uri uri, Result result) in <0x00048> Gnome.Vfs.FileInfo:.ctor (Gnome.Vfs.Uri uri, FileInfoOptions options) in <0x00031> Gnome.Vfs.FileInfo:.ctor (System.String uri, FileInfoOptions options) in <0x0000f> Gnome.Vfs.FileInfo:.ctor (System.String uri) in <0x0004e> FSpot.ThumbnailGenerator:ThumbnailIsValid (Gdk.Pixbuf thumbnail, System.Uri uri) open uri = file:///home/user/f-spot_photos/2002/12/16/phto0031-1.jpg System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/16/phto0031-1.jpg". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x00024> FSpot.JpegFile:.ctor (System.Uri uri) open uri = file:///home/user/f-spot_photos/2002/12/16/phto0031-1.jpg System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/16/phto0031-1.jpg". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x0000a> FSpot.ImageFile:PixbufStream () in <0x00030> FSpot.ImageFile:Load (Int32 max_width, Int32 max_height) in <0x00086> PixbufLoader:ProcessRequest (.RequestItem request) in <0x00025> FSpot.ThumbnailGenerator:ProcessRequest (.RequestItem request) open uri = file:///home/user/f-spot_photos/2002/12/16/phto0030-1.jpg System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/16/phto0030-1.jpg". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x00024> FSpot.JpegFile:.ctor (System.Uri uri) open uri = file:///home/user/f-spot_photos/2002/12/16/phto0030-1.jpg System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/16/phto0030-1.jpg". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x0000a> FSpot.ImageFile:PixbufStream () in <0x00030> FSpot.ImageFile:Load (Int32 max_width, Int32 max_height) in <0x00086> PixbufLoader:ProcessRequest (.RequestItem request) in <0x00025> FSpot.ThumbnailGenerator:ProcessRequest (.RequestItem request) open uri = file:///home/user/f-spot_photos/2002/12/30/2002_1230_165958AA-1.JPG System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/30/2002_1230_165958AA-1.JPG". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x00024> FSpot.JpegFile:.ctor (System.Uri uri) open uri = file:///home/user/f-spot_photos/2002/12/30/2002_1230_165958AA-1.JPG System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/30/2002_1230_165958AA-1.JPG". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x0000b> FSpot.JpegFile:Select (StatementSink sink) in <0x00163> InfoBox+ImageInfo:.ctor (FSpot.ImageFile img) in <0x00129> InfoBox:Update () open uri = file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x00024> FSpot.JpegFile:.ctor (System.Uri uri) open uri = file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x0000b> FSpot.JpegFile:Select (StatementSink sink) in <0x00163> InfoBox+ImageInfo:.ctor (FSpot.ImageFile img) in <0x00129> InfoBox:Update () item changed open uri = file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x00024> FSpot.JpegFile:.ctor (System.Uri uri) open uri = file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG error checking orientation open uri = file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x0000a> FSpot.ImageFile:PixbufStream () in <0x0015f> FSpot.AsyncPixbufLoader:Load (System.Uri uri) in <0x00159> FSpot.PhotoImageView:PhotoItemChanged (FSpot.BrowsablePointer item, FSpot.BrowsablePointerChangedArgs args) open uri = file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x00024> FSpot.JpegFile:.ctor (System.Uri uri) open uri = file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG System.IO.FileNotFoundException: Could not find uri "file:///home/user/f-spot_photos/2002/12/30/2002_1230_200710AA-1.JPG". in <0x00962> Gnome.Vfs.VfsStream:.ctor (System.String text_uri, FileMode mode, Boolean async) in <0x00012> Gnome.Vfs.VfsStream:.ctor (System.String uri, FileMode mode) in (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) in <0x00045> FSpot.ImageFile:Open () in <0x00028> FSpot.JpegFile:get_Header () in <0x0000b> FSpot.JpegFile:Select (StatementSink sink) in <0x00163> InfoBox+ImageInfo:.ctor (FSpot.ImageFile img) in <0x00129> InfoBox:Update () Xlib: unexpected async reply (sequence 0x37eb7)!
The stupid question. The photo file:///home/user/f-spot_photos/2002/12/16/phto0028-1.jpg is that one readable, accessable etc? What happend after you started again? Could you access it from your cvs version?
The stupid question. The photo file:///home/user/f-spot_photos/2002/12/16/phto0028-1.jpg is that one readable, accessable etc? Yes, I checked that it was a valid file. As I've gone on to test the JobScheduler patch again, I've already nuked it (I always import on a fresh build to see how that goes). What happend after you started again? I didn't try to start again, I went right into another patch. Could you access it from your cvs version? The picture? It's in a different user's directory, so no. But I could access it with Konqi.
The marked patch is ready to go, it works great and really improves the experience for people w/ more than a handful of tags.
fixed in r 2997