Re: Automatic paragraph direction and BiDirection layouts in Gtk+

[Behdad Esfahbod <behdad cs toronto edu>]

On Tue, 9 Mar 2004 dov imagic weizmann ac il wrote:

> Hi Behdad,

Hi Dov,

Quite like you, I have not digested your reply completely yet.
Just to send a quick note.  We definitely need to discuss this
thing in depth later.

> Thank you for your very clear write-up. It is as shame that this great
> summary was not available at the design stages of gtk+-2 as I think that
> a few mistakes may have been made that are not reversible.

I just had a look.  I didn't like it much, but I guess we can
handle it.

> * About "widget direction": gtk+ currently is employing a two layer scheme,
> called direction, and default direction. Both of these may take on the values
> LTR and RTL. The default direction is propagated, wheras the direction is not.
> This is not as good as what you proposed, but it may be good enough.

That's indeed good news that it has both of them.  But are you
sure that default direction is *propagated*?  Or simply falls
back to the locale direction?  I'm guessing this partly based on
the code I read, and partly on that you typically attach widgets
to their parents in a bottom-up manner, and I really wonder it
goes and propagates the default direction in a tree traversal
way.  BTW, when we know the exact semantics, we can extend it in
a clean way.

> * Align: gtk+ here uses a floating point value where 0 indicates
> align according to widget direction (which is determined by the contents), 0.5
> means center, and 1.0 means align in direction opposite to the layout direction.
> Here is the translation table between your description and gtk+'s:
>
> 	Behdad                  Gtk-xalign
> 	------                  ----------
> 	align                   0
> 	align-opposite		1.0
> 	center			0.5
> 	inherit			n/a
> 	opposite		n/a
> 	left			n/a
> 	right			n/a

Now that you say I remember seeing this align schema.  It's
indeed genius.  It is not quite prolematic.  The good point about
the whole story is that as not many non-left-to-right
applications exist today, we can slightly play with the
semantics.  So in this case, we let the align be there with a
float value between 0 and 1.0, then we define another attribute,
something that almost means "coordinate system":  It can be
either "absolute", or "relative":

  * In the "absolute" coordinate system, an "align" value of 0
always means "left", and 1 always means "right".

  * In the "relative" coordinate system, an "align" value of 0
means at the side that the resolved direction is, and 1 means at
the other side!

So we can define these semantics after we studied it well.  The
small problem with this approach is that we probably need to
deprecate some macros, and define new macros.  For example

GTK_DIRECTION_RIGHT should be deprecated and an alias for
GTK_NEW_DIRECTION_OPPOSITE, and a new GTK_NEW_DIRECTION_RIGHT
defined which really means "right", not the other side... (NEW is
apparently not the best name ;).

> The problem with the current gtk+ API is that since it was the choice
> of using a float instead of an enum, makes it very ugly to extend it and
> add the missing choices! The only way I see is to create floating point
> constants that are outside the 0.0-1.0 range.
>
> * Regarding "paragraph direction" - couldn't this be overloaded with the
> "widget direction". I'm not sure if you intend this to be a paragraph property
> or a widget property. As a widget property it seems that "the default widget
> paragraph direction" and the "widget direction" are close enough to be
> overloaded. As individual paragraphs I wonder why you chose "strong"
> instead of "rtl" and "ltr"? In any case gtk+ currently does not define this,
> and with the latest BiDi patch, the paragraph direction is always according
> to the resolved direction of the contents.

I meant it to be a paragraph property.  I thought that, Ok, a
text widget now has a default direction, which is the widget
direction property.  Now I propose three ways to handle
individual paragraph directions:  (Other ways can be added later)

  * auto: Using your patch, which is just one algorithm among
many others (it's the best IMO).

  * weak:  Means that resolve paragraph directions independently,
fall back to the "widget direction" if there is no strong
character in the paragraph.

  * strict:  Means that set all paragraph directions to "widget
direction", no matter what's in the paragraph.


> I have a few ideas of what may be done, but I'd prefer to send this away
> as soon as possible.

I still think better we meet in an IRC session, and first you
describe for Roozbeh and I and possibly Noah, how Gtk+ is doing,
and then we can state and decide the problems step by step.  As
this is not going to get into 2.4, we can delay it to some time
around early April.

> Thanks again for your great summary.
>
> Regards,
> Dov

Happy to see you liked it :)
--behdad
  behdad.org

PS.  There was a proposal to start a bidi working group on
freedesktop.org.  Perhaps we can try to document these things
after we came to some consensus and tested it in gtk+.   But
still a new mailing list does not hurt.