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 704592 - Better handling of self-localized translation language list
Better handling of self-localized translation language list
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: User Interface
git master
Other All
: Normal normal
: 2.10
Assigned To: Jehan
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2013-07-20 06:43 UTC by Jehan
Modified: 2013-07-28 14:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Only load the language list at startup and simplify the code. (27.91 KB, patch)
2013-07-20 06:43 UTC, Jehan
none Details | Review
Only load the language list at startup and simplify the code. (27.85 KB, patch)
2013-07-27 15:55 UTC, Jehan
none Details | Review

Description Jehan 2013-07-20 06:43:24 UTC
Created attachment 249674 [details] [review]
Only load the language list at startup and simplify the code.

After looking a little more at the language list for Bug 704510, I saw various issues with the current implementation:

1/ It reloads and fully parse the huge XML list of ISO-639 languages (on my system for instance, this XML file is 2175 lines) each time it constructs a GimpLanguageStore, which means in other words each time the user opens the preferences dialog. That's a waste of resources (actually I can feel the slight delay on my computer when I open the preferences, which disappeared with my new implementation);

2/ Because of 1/, we have to also localize each language name in itself each time the user opens the preferences as well, which is again a waste of resources, but even more can be a security risk. As pointed by glib docs:

"Environment variable handling in UNIX is not thread-safe, and your program may crash if one thread calls g_setenv() while another thread is calling getenv(). (And note that many functions, such as gettext(), call getenv() internally.)"

Well we have a lot of calls to gettext or other, and I think we want to be thread-safe. ;-) In any case, why take the risk?

3/ The current implementation is kind of doing a lot more of useless work. For instance as I said, it would first parse and save the whole list of languages, then only we check if we have a gettext translation for this language. As there are hundreds of languages but only a few dozen of available translations, we want to do the opposite: first check which language we have translations for, then check their name in the file.

4/ There was this class GimpTranslationStore which was only some kind of useless buffer after GimpLanguageStore. It has absolutely no interest (or I did not get it), and just does some convoluted processing for no reason (I had to concentrate hard to understand what was going on between GimpLanguagestore and GimpTranslationStore (basically save all the languages first in a hash table, then later save them in the GtkListStore, doing all twice).
I propose to get rid of this intermediate useless class, thus simplify the code.

The attached patch implements all this, making in my opinion a safer and cleaner code for managing this list.
Comment 1 Michael Natterer 2013-07-20 10:38:23 UTC
Won't be able to look closer until back from vacation, but maybe it was
for providing either untranslated or translated language names (depending
on which you used, language or translation store). Didn't we want the
language selection in tool options be untranslated?
Comment 2 Jehan 2013-07-20 22:07:14 UTC
Hi,

Right. Let me have a look at this again.
Comment 3 Jehan 2013-07-27 15:55:46 UTC
Created attachment 250272 [details] [review]
Only load the language list at startup and simplify the code.

Mitch, attached a new version of the patch. I got back the GimpTranslationStore from the dead but cleaned out a lot of redundant code.

I believe this is kind of an important patch because setenv/getenv are not thread-safe. And even though I had no problem because of this since we made this self-localized language feature, let's not take a chance of problems and crashes in the future or in some particular platforms.
Also it avoids parsing the ISO-639 language list each time the user opens the preference or the text tool. :-)
Comment 4 Michael Natterer 2013-07-27 16:10:30 UTC
I don't think I understand this patch any longer, go ahead and push if
you think it's the right thing to do :)
Comment 5 Jehan 2013-07-27 16:59:16 UTC
Ok. Done. :-)

commit a129f84c68568cc96c3f06a40e8bab6fba035a01
Author: Jehan <jehan@girinstud.io>
Date:   Sat Jul 20 14:51:13 2013 +0900

    Bug 704592 - only load language lists once at gui startup.
    
    Improvements:
    - setenv/getenv() are not thread-safe, hence they should be run only at
    startup before any threading occurs.
    - it is counter-productive to load the huge ISO-639 XML file each time
    the user opens the Preferences dialog or the text tool options.
Comment 6 su-v 2013-07-27 19:41:01 UTC
Now again crashes on OS X when opening preferences dialog (see also bug #704510, comments #4ff):

$ gimp-git.sh quartz --verbose --version
GNU Image Manipulation Program version 2.9.1
git-describe: soc-2012-unified-transform-after-gsoc-1145-ga129f84

using GEGL version 0.3.0 (compiled against version 0.3.0)
using GLib version 2.36.3 (compiled against version 2.36.3)
using GdkPixbuf version 2.28.2 (compiled against version 2.28.2)
using GTK+ version 2.24.20 (compiled against version 2.24.20)
using Pango version 1.34.1 (compiled against version 1.34.1)
using Fontconfig version 2.10.93 (compiled against version 2.10.93)
using Cairo version 1.12.14 (compiled against version 1.12.14)
$
$ gimp-git.sh quartz 
This is a development version of GIMP.  Debug messages may appear here.

/Volumes/magenta/mp-trunk/quartz/../src/gimp/local/bin/gimp-2.9: fatal error: Segmentation fault: 11
/Volumes/magenta/mp-trunk/quartz/../src/gimp/local/bin/gimp-2.9 (pid:89695): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s
  • #0 __wait4
  • #1 g_on_error_stack_trace
  • #2 g_on_error_query
  • #3 gimp_eek
  • #4 gimp_fatal_error
  • #5 gimp_sigfatal_handler
  • #6 <signal handler called>
  • #7 g_hash_table_iter_init
  • #8 gimp_translation_store_constructed
  • #9 g_object_newv
  • #10 g_object_new
  • #11 gimp_translation_store_new
  • #12 gimp_language_combo_box_new
  • #13 gimp_prop_language_combo_box_new
  • #14 prefs_dialog_new
  • #15 preferences_dialog_create
  • #16 gimp_dialog_factory_constructor
  • #17 gimp_dialog_factory_dialog_new_internal
  • #18 gimp_dialog_factory_dialog_new
  • #19 g_cclosure_marshal_VOID__STRINGv
  • #20 _g_closure_invoke_va
  • #21 g_signal_emit_valist
  • #22 g_signal_emit
  • #23 gimp_string_action_activate
  • #24 g_closure_invoke
  • #25 signal_emit_unlocked_R
  • #26 g_signal_emit_valist
  • #27 g_signal_emit
  • #28 _gtk_action_emit_activate
  • #29 _g_closure_invoke_va
  • #30 g_signal_emit_valist
  • #31 g_signal_emit
  • #32 menu_event_activate_callback
  • #33 source_closure_marshal_BOOLEAN__VOID
  • #34 g_closure_invoke
  • #35 source_closure_callback
  • #36 g_main_context_dispatch
  • #37 g_main_context_iterate
  • #38 g_main_loop_run
  • #39 app_run
  • #40 main

(script-fu:89696): LibGimpBase-WARNING **: script-fu: gimp_wire_read(): error
$
Comment 7 Jehan 2013-07-28 14:21:43 UTC
As discussed on the mailing list, normally all fixed. :-) Tell me if there is any more issue.

commit f0b3c76c9d1b8a2e1ae8960fad108d5f63687700
Author: Jehan <jehan@girinstud.io>
Date:   Mon Jul 29 02:12:17 2013 +1200

    app - fix crash of the language parser on OSX.
    
    Stupid bug. I misused the GINT_TO_POINTER macro.
Comment 8 su-v 2013-07-28 14:39:46 UTC
Just to confirm: on OS X 10.7.5 with dependencies installed via MacPorts, f0b3c76 launches ok and does not crash when opening preferences. thx :)