Changes from your version:

 - flip_dir wasn't getting since set when the direction
   came from the widget direction, which seemed wrong
   to me.
 - Added draw_cursor() convenience functions
 - Make resolved_dir a bitfield to maintain bincompat.
 - Indentation and cleanups.

Created attachment 18765 [details] [review]
Revised GtkLabel patch

One thing to note is that this change broke one of the 
labels in the label test in testgtk+:

      label = gtk_label_new ("Arabic  
\330\247\331\204\330\263\331\204\330\247\331\205
\330\271\331\204\331\212\331\203\331\205\n"
                             "Hebrew   
\327\251\327\234\327\225\327\235");
      gtk_widget_set_direction (label, GTK_TEXT_DIR_RTL);
      gtk_label_set_justify (GTK_LABEL (label), GTK_JUSTIFY_RIGHT);

In several ways:

 - The autoguess algorithm gets things wrong for this,
   so adding RLM on both paragraphs is necessary
 - The code actually wanted right-justification, not 
   "against-the-widget-direction justification, 
   so the call to set_direction() needs to be removed.

I'm not really worried about compatibility here; I suspect
the set of GTK+ programs with explicitely specified 
bidi strings is pretty tiny.

But this issue did raise a couple of questions in my mind:

 - I think that at least for xalign (get_layout_location())
   basing it off the auto-computed direction isn't right.

   Imagine say, a dialog where one of the label's was
   based on text entered by the user... flipping the direction
   of the label would break the layout.
   
   the choice of flipping the xalign value, it seems to me 
   should come from gtk_widget_get_direction().

   The right behavior for justification is less clear to
   me; my guess is that the right behavior is that it
   should depend on the paragraph-by-paragraph resolved
   direction (see below)

   The only way I can think of implementing this is to
   extend PangoAlignment to have PANGO_ALIGN_WITH
   PANGO_ALIGN_AGAINST or something like that.... values
   that depended on the paragraph direction of the current
   paragraph.

 - There's a mismatch between GtkTextView and GtkLabel in
   the handling of multiple paragraph setups; consider
   a 2 paragraph string

     abc
     ABC

   For GtkLabel, the second paragraph will have a ltr paragraph
   direction, while for GtkTextView, it will be rtl.

   To fix this, the GtkTextView propagation algorithm would
   need to be introduced into PangoLayout. (Nothing so
   sophisticated for the implementation though, we could
   just scan the whole text to find the first paragraph
   direction and propagate from there.)

 - It seems to me that there should some way to set bidi
   direction other than inserting ‎ into GMarkup
   or literal unicode into the strings.

   Maybe just wait for bug 70399 and use GMarkup; the only
   other things I can think of are:

    - Use the *unpropagated* value from gtk_widget_set_direction()
      if not GTK_TEXT_DIR_NONE, to provide the paragraph
      direction for the layout.
 
      But this is especially funny if we are using the propagated
      value to set the xalign.

    - Add separate API

   Neither of which I like very much.

This becomes a lot simpler with the PangoLayout changes
for bidi propagation.

I decided not to make xalign depend on the resolved
direction; (what resolved direction, for one thing,
for multi-paragraph labels?)

Mon Mar  1 12:23:06 2004  Owen Taylor  <otaylor@redhat.com>
 
        * gtk/gtklabel.c: Handle dynamically resolved bidi direction
        when drawing the cursor. (#118541)