GNOME Bugzilla – Bug 560337
GtkFileChooser hour time missing for current date files
Last modified: 2014-08-29 08:12:11 UTC
Please describe the problem: The hour is missing in file modified today Steps to reproduce: 1. Menu File, Open 2. open a folder with a file modified today 3. see modification time Actual results: no hour is shown, only minutes Expected results: see HH.MM Does this happen every time? yes Other information: I see it on GIMP 2.6.2 on Win32
does not happen on Linux. does not happen on Win32 with a self builed application and Gtk 2.14.4 So probably is GIMP Win32 only related.
Created attachment 222211 [details] open dialog show only minutes for recent files
happen with GIMP 2.8.0 too
changed Component from GtkFileChooser to User interface changed version from (GtkFileChooser) 2.14 to GIMP 2.6.2 (happen on 2.8.0 too) changed OS from All to Windows please someone can CONFIRM this bug, it is very easy to reproduce
there is no substantial difference between an unconfirmed/new bug; if it's not possible to reproduce, it'll be marked as resolved or needinfo until we get the proper steps to reproduce.
ok, I thinked that uncormirmed bug, no developer try to fix, while new are open to assignment. Anyway, I wrote the 3 steps to reproduce the bug in 2008 https://bugzilla.gnome.org/show_bug.cgi?id=560337#c0 really happen only on my Windows installation?
hope the new attachment help to understand what happen. The problem happen also on yesterday modified files.
Created attachment 222243 [details] testtime.c
The Italian translation has this for what the file chooser shows: #: gtk/gtkfilechooserdefault.c:11084 msgid "%H:%M" msgstr "%k.%M" And %k means this to strftime(): %k The hour (24-hour clock) as a decimal number (range 0 to 23); single digits are preceded by a blank. (See also %H.) (TZ) So I don't know why the hour would be missing. However, the Windows version of GTK+ has some magic to convert that UTF-8 string from the translation into the locale of Microsoft's C library. I can't think of how this conversion could screw up the initial "%k". (Or maybe strftime() is buggy in Windows?) Valerio, is it possible for you to compile the attached program and run it? It should print "time: xx.yy" with the local time. Does it show the right thing, or are the hours also removed?
Created attachment 222344 [details] modified source with %H too
I tested the above modified source to show the result of %H too. The problem seems that msvcrt (used by MinGw) doesn't support %k conversion type Attached the WARN output while compiling with MinGw and the output. Attached also the Cygwin output that is consistant with Linux/Posix output
Created attachment 222345 [details] compilation and output with MinGw so msvcrt.dll
Created attachment 222346 [details] compilation and output with Cygwin so newlib
the single quote around %s let understand from where is the space in case of H<10
so the simplest patch is to substitute %k with %H
I asked in MinGw user list, they linked the MS supported conversion chars: http://msdn.microsoft.com/en-us/library/fe06s4ak(v=vs.100).aspx no (TZ) Olson's timezone package like on Linux, this is an uncommon extension. Them suggestion is to use %H instead, my is to use a _WIN32 guard if there are reasons to use the space in front of H<10 instead of zero (I can't find one), and remove all warn on compilation, before or after something bad happen. The patch is simple enough that I can try to submit myself to speedup the inclusion. Is this desired?
I'm not a professional sw developer, I never try to post a patch to GIMP. Anyway I can try to manage this. Please tell me if as alternative you prefer to do by yourself
Um, so what is the conclusion here?
And why was this moved to GIMP? Moving back to GTK+
I moved to GIMP because of https://bugzilla.gnome.org/show_bug.cgi?id=560337#c1 Anyway now I had not retested with current GTK used by current GIMP. Plase let me know if I had to propose a simple patch or was already done by someone?
I just tested with GIMP 2.8.2 on Win7, 32 bit (from gimp-win.sourceforge.net), including GTK 2.24.10. The Italian File-Open-dialog shows 'Sconosciuto' (='Unknown') behind a file from today. Other translations show the proper time with hours and minutes. Please post your patch here. I can't guarantee, that it will be accepted, but at least this will bring us a step further.
as po/it.po and po/hu.po are the only locales that use %k instead of %H, the patch change those files to %H. Best would be to add a guard with G_OS_WIN32 so the %H apply to Win32 only, as on Linux+it|hu the %k work. But, as I cannot find a reason to keep the %k on it&hu only, a simple solution is to use always %H
Created attachment 223959 [details] [review] patch for locale=it file: po/it.po
Created attachment 223960 [details] [review] patch for locale=hu file: po/hu.po
as the it.po and hu.po files are not updated to last .pot (I do not checked the other locale .po files), I regenerated them with: $ mv it.po it.orig.po # backup $ msgmerge it.orig.po gtk20.pot --output-file=it.po here I modified %k in %H $ mv it.gmo it.orig.gmo # backup $ msgfmt --output-file=it.gmo it.po $ mv hu.po hu.orig.po # backup $ msgmerge hu.orig.po gtk20.pot --output-file=hu.po here I modified %k in %H $ mv hu.gmo hu.orig.gmo # backup $ msgfmt --output-file=hu.gmo hu.po I attach the newly generated .po files. Tell me if you need the .gmo files too, and if I can attach binary files to this bug
Created attachment 224054 [details] [review] locale=it file: po/it.po
Created attachment 224055 [details] [review] locale=hu file: po/hu.po
those files apply to the last Gtk ported to Win32, so 2.24.10 I will try to do the same for 3.x series if needed
Created attachment 224166 [details] [review] compiled binary messages for it
Created attachment 224167 [details] [review] compiled binary messages for hu.gmo
and now follow the files for 3.4.4
Created attachment 224168 [details] [review] po/it.po
Created attachment 224169 [details] [review] po/it.gmo
Created attachment 224170 [details] [review] po/hu.po
Created attachment 224171 [details] [review] po/hu.gmo
and below the files for 3.5.16
Created attachment 224172 [details] [review] po/it.po
Created attachment 224174 [details] [review] po/it.gmo
Created attachment 224175 [details] [review] po/hu.po 3.5.16
Created attachment 224176 [details] [review] po/hu.gmo 3.5.16
just tested with GIMP 2.8.4 still present on Italian locale on Win32, no commit was done?
Please see https://live.gnome.org/GnomeLove/SubmittingPatches for a guide on creating a patch
the bug is still marked as NEEDINFO, really noone can reproduce this bug?
I will try to use the git patch format instead of diff
Created attachment 246770 [details] [review] fix compile warn & open dialog hour miss for today files on it & hu locales on Win32
the patch is against git sources, so newer than version 3.6 Hope the previous attached diffs can be applied also to next Win32 port of GTK, so the version next to current stable 2.24.10: http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+ or this patch will be unusefull as the bug happen only on Win32
Patch looks good to me. You can make a patch for that latest 2.24 branch by switching to that branch in git.
thanks. To select 2.24 branch with git I need help, as I do not know how to do that, neither found help on: https://live.gnome.org/GnomeLove/SubmittingPatches Anyway I tried: $ git clone git://git.gnome.org/gtk+-2.24.10 and $ git clone git://git.gnome.org/gtk+-2.24 but seems exist only the last <gtk+> module without version in it
That works for me: cd $your_workspace_directory git clone git://git.gnome.org/gtk+ cd gtk+ git checkout --track origin/gtk-2-24 (or origin/gtk-2-24-win32) The last command creates a tracking branch of the original branch - you will receive all changes in the upstream Gtk+ Git repository on a 'git pull origin'.
Created attachment 246850 [details] [review] fix compile warn & open dialog hour miss for today files on it & hu locales on Win32. On branch gtk-2-24 On branch gtk-2-24
hope this patch is ok also for 2.24 so we can have a fix on Win32 (thinking to GIMP)
Thank you for your careful work, Valerio :) I've just pushed your patches. These are the commits: master branch - commit 54e2091740 gtk-2-24 branch - commit 4292fb433c
Created attachment 247714 [details] GIMP 2.8.6, GTK+ 2.24.18 on Win32
thanks, sometimes newbies require only some hints. Just tested with GIMP 2.8.6 released on June 21th on Win32. This version is still packaged with GTK 2.24.18, so the bug is still there, see shot.
it is discouraging to see that just released GIMP 2.8.8 is still packaged with GTK 2.24.18, so the bug is still there, see shot.
Created attachment 259909 [details] GIMP 2.8.8 open dialog, GTK+ 2.24.18 on Win32
Well it sounds like maybe you should create a gimp bug about using a newer gtk2 version On windows. Comments in this bug are unlikely to be seen by the gimp devs
I will do, thank you. I saw that the official repository for GTK+, still propose to download 2.24.10 (or newer 3.6.4) on Win32: http://www.gtk.org/download/win32.php or 2.22.1 for Win64: http://www.gtk.org/download/win64.php when the last of 2.24.x series is .22: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.24/ So picking last official Win binaries, and package them in GIMP, still hit this bug. As GTK+ Win .dll file is 2.24.18, I imagine that GIMP packagers, already build a newer Win version than official binary, but not from last sources, that maybe are only in current trunk? Am I doing wrong?
GIMP win package bug: https://bugzilla.gnome.org/show_bug.cgi?id=712380
it is not clear to me, which is the first released GTK+ version of 2.24.x series, that include this fix? Should be next to 2.24.18, but which one?
found, is 2.24.20: http://ftp.gnome.org/pub/gnome/sources/gtk+/2.24/gtk+-2.24.20.news
Created attachment 284794 [details] Open Dialog of GIMP 2.8.14 on Win32 with GTK 2.24.23 GIMP 2.8.14 on Win32 include the fix and work