Re: Automatic paragraph direction and BiDirection layouts in Gtk+

[Jonathan Ben Avraham <yba tkos co il>]

Hi Dov,
See inlines below...

On Thu, 18 Mar 2004 dov imagic weizmann ac il wrote:

> Hi Jonathan,
>
> Regarding Behdad's spec, note that there has been no decision to
> implemented it into gtk. I expect it will have to be changed in
> several ways until it may be implemented. Look at my comments
> regarding what Behdad wrote below. E.g.  the widget alignment
> today is assigned with a floating point number between 0.0 and
> 1.0. Adding "inherit" and "against" to such a scheme might require
> an API extension.

How did widget alignment ever get to be a floating point number? How
difficult would it be to change this to an enum or even an integer?

Actually, not being familiar with the code, I shouldn't be commenting on
this.

>
> Being familiar with the gtk-sources I feel that I can quite
> safely say that doing the actual implementation is quite easy
> once the spec has been written. The tough part was the
> automatic propagation of the base direction that is already
> in Gtk-2.4. All that remains is book-keeping of all the settings
> and then extracting and overriding the basedirection and the
> alignment from the agreed upon source.
>
> Thus most of the work is reaching an agreement of what should be
> done, and there Owen Taylor has the final word. Thus I believe
> that we should first use the mailing list to reach an agreement,
> and then I'll be happy to implement it.

Would it be possible to implement it in a test workspace so that we could
try it?

 - yba

>
> Regards,
> Dov
>
> On Thu, Mar 18, 2004 at 10:39:00AM +0200, Jonathan Ben Avraham wrote:
> > Hi Dov,
> > Thanks for the URL of Behdad's write-up. Indeed it is a fine piece of
> > specification. BTW, I have joined the gtk-i18n-list, so I should see
> > Behdad's posts now.
> >
> > If I understand the write up correctly, the inheritance of the "direction"
> > attribute allows us to override the Bidi algorithm and heuristic for the
> > "paragraph_direction" by setting the paragraph_direction to "strong". I
> > believe that this solves all of the Bidi problems that I currently forsee
> > in the Evolution Hebrew localization.
> >
> > The next question is who implements Behdad's spec and when? Do you have
> > the time to do it? I am talking to two possible sponsors to get some
> > funding for this, BTW.
> > Regards,
> >
> >  - yba
> >
> >
> >
> > On Wed, 17 Mar 2004 dov imagic weizmann ac il wrote:
> >
> > > Hi Jonathan,
> > >
> > > Here it is:
> > >
> > >   http://mail.gnome.org/archives/gtk-i18n-list/2004-March/msg00001.html
> > >
> > > I'm very interested to hearing your comments on it.
> > >
> > > I am also very interested to hear your comments on my response on
> > > the subject "RFC on Evolution Localization Requirements". Did you
> > > get it?
> > >
> > > Regards,
> > > Dov
> > >
> > > On Wed, Mar 17, 2004 at 04:47:23PM +0200, Jonathan Ben Avraham wrote:
> > > > Hi Dov,
> > > > Where can I see a copy of Behdad's write-up?
> > > >
> > > >  - yba
> > > >
> > > >
> > > >
> > > > On Tue, 9 Mar 2004 dov imagic weizmann ac il wrote:
> > > >
> > > > > Hi Behdad,
> > > > >
> > > > > 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'm still not ready to answer the question of how far gtk+ currently is
> > > > > from the view that you describe, but here are a few comments from reading
> > > > > your message and peaking at the gtk+ source code:
> > > > >
> > > > > * 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.
> > > > >
> > > > > * 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
> > > > >
> > > > > 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 have a few ideas of what may be done, but I'd prefer to send this away
> > > > > as soon as possible.
> > > > >
> > > > > Thanks again for your great summary.
> > > > >
> > > > > Regards,
> > > > > Dov
> > > > >
> > > > > ----
> > > > > Ivrix-discuss list. See http://ivrix.org.il.
> > > > > To unsubscribe, please send mail to ivrix-discuss-request ivrix org il with
> > > > > only the following line in the message body (NOT SUBJECT!): unsubscribe
> > > > >
> > > >
> > > > --
> > > >  EE 77 7F 30 4A 64 2E C5  83 5F E7 49 A6 82 29 BA    ~. .~   Tk Open Systems
> > > > =}------------------------------------------------ooO--U--Ooo------------{=
> > > >      - yba tkos co il - tel: +972.2.679.5364, http://www.tkos.co.il -
> > > >
> > > > ----
> > > > Ivrix-discuss list. See http://ivrix.org.il.
> > > > To unsubscribe, please send mail to ivrix-discuss-request ivrix org il with
> > > > only the following line in the message body (NOT SUBJECT!): unsubscribe
> > > ----
> > > Ivrix-discuss list. See http://ivrix.org.il.
> > > To unsubscribe, please send mail to ivrix-discuss-request ivrix org il with
> > > only the following line in the message body (NOT SUBJECT!): unsubscribe
> > >
> >
> > --
> >  EE 77 7F 30 4A 64 2E C5  83 5F E7 49 A6 82 29 BA    ~. .~   Tk Open Systems
> > =}------------------------------------------------ooO--U--Ooo------------{=
> >      - yba tkos co il - tel: +972.2.679.5364, http://www.tkos.co.il -
> >
> > ----
> > Ivrix-discuss list. See http://ivrix.org.il.
> > To unsubscribe, please send mail to ivrix-discuss-request ivrix org il with
> > only the following line in the message body (NOT SUBJECT!): unsubscribe
> _______________________________________________
> gtk-i18n-list mailing list
> gtk-i18n-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>

-- 
 EE 77 7F 30 4A 64 2E C5  83 5F E7 49 A6 82 29 BA    ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
     - yba tkos co il - tel: +972.2.679.5364, http://www.tkos.co.il -