GNOME Bugzilla – Bug 536113
Next-button gets greyed out with certain picturenames
Last modified: 2011-07-05 11:41:56 UTC
I have a folder with pictures named as "day-month-year-hh:mm.jpg", e.g "21-Oct-07-15:55.jpg". Normally after I have opened a picture I am able to press the next button to go to the next image, but I cant when I name the pictures this way. I can still use the nextbutton with files named DSC_0005.JPG Does this have anything to do with the ending? jpg vs. JPG?
More info: If I close the image currently open in gthumb to get into gthumbs thumbnailmode and then open an image everything works good. The problem is coming when opening the image from nautilus. Is it perhaps some kind of conflict between these two programs way to sort files? Steps to reproduce: Make a folder and copy 4 jpg images into it. Name them as follows: 12-May-08-15:27.jpg 28-Oct-06-14:18.jpg 28-Oct-06-14:50.jpg 29-Oct-06-13:26.jpg Then open one of the images from nautilus, for example 28-Oct-06-14:18.jpg. The result is gray next and backbuttons. If you now press N (normally to go to the next image) you get to the first picture, 12-May-08-15:27.jpg.
Confirmed in trunk (svn rev 2334). It doesn't happen if the colons are removed from the filenames. Perhaps this is a gnome-vfs/uri issue that will disappear when gthumb is ported to gio. We'll see... - Mike
Hi, I am on the ubuntu bugsquad and a user reported a bug root cause of which seems to be the same as this bug. The ubuntu bug link is: https://bugs.launchpad.net/ubuntu/+source/gthumb/+bug/256755 The difference in that bug is that the character messing things up is comma, not a colon. I verified that the behavior is same either with a comma or a colon. Suman.
gThumb is now ported to gio, right? Is the problem still in trunk?
No, the gio porting is not complete yet. It is being worked on (bug 525482). - Mike
I can confirm that this bug occurs with the following set of characters: ,:&@$=+ Please mark bug 552035 as a duplicate, as I only encountered a problem with ampersands initially. I will incorporate my investigation here: From Nautilus or the command-line, the user can open an image with an ampersand in its filename, but gThumb considers it as the 0th image of the directory and behaves accordingly: + The titlebar shows (0/###), where ### is the number of images in the directory. + Previous Image command (PgUp) is disabled, since there are no images before the 0th image. + Next Image command (PgDn) will show image #1 of the directory. Additionally, opening the ampersand image and hitting Return or Esc to get the image browser will not select the image as expected; however, opening a ampersand image from within the browser will not trigger this bug.
*** Bug 552035 has been marked as a duplicate of this bug. ***
Created attachment 161183 [details] [review] uricmp: Use canonical path for comparison, avoid problems with quoting of special characters Although this should be no longer a problem with 2.11., here a fix for the 2.10 branch (that is still used in Debian testing and Ubuntu). The problem is that gth_file_list_pos_from_path does not succeed on finding the picture gthumb was started with, because it tries to compare differently escaped paths. Instead of fixing all the escaping going on, the attached patch simply uses the "canonical paths" in the uricmp function -- so different escapings no longer make a difference there. The patch is against the 2.10 branch.
version 2.12 doesn't have this issue anymore.