After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 536113 - Next-button gets greyed out with certain picturenames
Next-button gets greyed out with certain picturenames
Status: RESOLVED OBSOLETE
Product: gthumb
Classification: Other
Component: general
2.10.x
Other Linux
: Normal normal
: ---
Assigned To: Paolo Bacchilega
Paolo Bacchilega
: 552035 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-06-01 20:14 UTC by Askar Andersson
Modified: 2011-07-05 11:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
uricmp: Use canonical path for comparison, avoid problems with quoting of special characters (1.12 KB, patch)
2010-05-16 21:31 UTC, Marcel Stimberg
none Details | Review

Description Askar Andersson 2008-06-01 20:14:46 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?
Comment 1 Askar Andersson 2008-06-01 23:26:47 UTC
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.
Comment 2 Michael Chudobiak 2008-06-02 12:26:44 UTC
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
Comment 3 suman chakravartula 2008-08-12 16:30:04 UTC
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.
Comment 4 Askar Andersson 2008-08-27 22:36:57 UTC
gThumb is now ported to gio, right? Is the problem still in trunk?
Comment 5 Michael Chudobiak 2008-08-28 11:56:35 UTC
No, the gio porting is not complete yet. It is being worked on (bug 525482).

- Mike
Comment 6 Darren W. Hill 2009-04-10 04:07:45 UTC
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.
Comment 7 Darren W. Hill 2009-04-18 14:51:05 UTC
*** Bug 552035 has been marked as a duplicate of this bug. ***
Comment 8 Marcel Stimberg 2010-05-16 21:31:19 UTC
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.
Comment 9 Paolo Bacchilega 2011-07-05 11:41:56 UTC
version 2.12 doesn't have this issue anymore.