Bug 1008821 - Gtk should export a function to get default direction of the widgets
Gtk should export a function to get default direction of the widgets
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gtk3 (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-17 02:54 EDT by Vratislav Podzimek
Modified: 2014-09-04 00:31 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-04 00:31:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Possible (untested) patch (2.36 KB, patch)
2013-09-17 04:07 EDT, Vratislav Podzimek
no flags Details | Diff

  None (edit)
Description Vratislav Podzimek 2013-09-17 02:54:00 EDT
Description of problem:
Gtk internally uses the following check to decide whether to use RTL or LTR widgets direction:

  /* Translate to default:RTL if you want your widgets
   * to be RTL, otherwise translate to default:LTR.
   * Do *not* translate it to "predefinito:LTR", if it
   * it isn't default:LTR or default:RTL it will not work 
   */
    char *e = _("default:LTR");
    if (strcmp (e, "default:RTL")==0) 
      gtk_widget_set_default_direction (GTK_TEXT_DIR_RTL);
    else if (strcmp (e, "default:LTR"))
      g_warning ("Whoever translated default:LTR did so wrongly.\n");

However, if an external tool/library wants to decide whether Gtk would use RTL or LTR, it needs to do the same check, e.g. (in Python):

    xlated = gettext.ldgettext("gtk30", "default:LTR")
    if xlated == "default:LTR":
        Gtk.Widget.set_default_direction(Gtk.TextDirection.LTR)
    else:
        Gtk.Widget.set_default_direction(Gtk.TextDirection.RTL)

This is not a good solution as it depends on an internal implementation of the check used by the Gtk toolkit. If Gtk developers decide to change it or for example just change the particular string used for the check, such a solution will stop working.

Version-Release number of selected component (if applicable):
gtk3-3.9.14-1.fc20

Actual results:
No function providing information about the default widget direction exported by the Gtk library.

Expected results:
A function hiding the internal implementation.

Additional info:
I understand this information is quite rarely needed, but there are some applications that make use of it (e.g. the Anaconda installer).
Comment 1 Vratislav Podzimek 2013-09-17 04:07:51 EDT
Created attachment 798660 [details]
Possible (untested) patch
Comment 2 Matthias Clasen 2013-12-05 07:44:05 EST
use gtk_widget_get_text_direction
Comment 3 Vratislav Podzimek 2013-12-10 03:58:36 EST
(In reply to Matthias Clasen from comment #2)
> use gtk_widget_get_text_direction
I wish I could. Output from testing in the installer:

> gtk_widget_get_default_direction tells: LTR
> the right direction: RTL

The problem is that Gtk is initialized before language is chosen in the installer and the value returned by the gtk_widget_get_text_direction function uses some cached value. So, either there has to be a function to get the right (current) value, or gtk_widget_get_text_direction has to be modified to return the right (current) value. Since I have no idea what side effects the latter solution could have, I proposed a patch implementing the former one.
Comment 4 Matthias Clasen 2013-12-10 10:50:13 EST
I misunderstood the problem. There is indeed not good way to do this sort of reinitialization right now, short of looking at the 'special' translations yourself.

I'll look at adding a gtk_get_locale_direction() to the API for 3.12, then you can use that instead of duplicating the translation hack.

https://bugzilla.gnome.org/show_bug.cgi?id=720200
Comment 5 Vratislav Podzimek 2013-12-11 02:39:47 EST
Works for me, thanks!

Note You need to log in before you can comment on or make changes to this bug.