Re: GtkText widget with "reflection"

[Owen Taylor <otaylor redhat com>]

dov@imagic.weizmann.ac.il (Dov Grobgeld) writes:

> I have patched the GtkText widget to support what I call reflected mode,
> which is a simple way of supporting Hebrew and possibly other Right-to-
> left (RTL) languages. This is not a perfect solution for RTL language,
> which lies in unicode and BiDi (bidirectional) algorithms, but it allows
> for supporting quite a big subset of programs. 
> 
> My patched widget with a test program is available from
> 
>     http://imagic.weizmann.ac.il/~dov/pdarchive/gtkrtext.tgz

This is very neat!
  
> I have some questions regarding the widget:
> 
> * Would it be appropriate to merge my changes into the main Gtk
>   development tree, or should I instead keep the widget as an 
>   independant archive?

For now, my feeling is that it is better to keep it separate.
This is because it has to be done over again in the near
future for a couple of reasons:

 - GTK+ will be switching over to Unicode in the next development
   cycle, and at that point, we presumably want to implement
   the real Unicode BiDi algorithms.

 - GtkText needs to be completely replaced, with something a lot
   more maintainable.

So, I'm a little hesitant to put stuff in, knowing that it
will be ripped out as soon as we get GTK+-1.2 out.

> * When in reflected mode the keys pressed have to be mapped into 
>   Hebrew characters. At the moment this mapping is hardwired into the
>   program. I would much rather have it being read from the resource
>   file. How can I do this?

I believe you can do this completely at the X level. (At least
in X11R6, probably for X11R5 too)

 - Set up your keyboard to produce Hebrew keysyms. (Either with
   modmap, or, for people using XFree86, xkb. There doesn't seem 
   to be an appropriate xkb keymap defined for Hebrew currently, 
   but if you copy, for example, /usr/lib/X11/xxkb/symbols/ru 
   and edit, it shouldn't be hard to come up with one)

 - Set up a gtkrc for your program that specifies a fontset
   which includes iso8859-8. The gtkrc would look something
   like:

=====
    style "defaultfont" {
       fontset = "*"
     }

    class "GtkWidget" style "defaultfont"
======

    or you could specify something more specific. To use the
    ETL fonts which come with MULE, you could do:

      fonset="-etl-fixed-medium-r-normal--14-140-72-72-c-70-iso8859-8"

  - export LANG="iw_IL"

This will set it up so when you can type and produce iso8859-8
strings in a GTK+ application, and they will display properly. 
(But, without a patch like yours, they will be backwards)

If you do it this way, it doesn't completely remove the need
for locale-specific knowledge; to keep the user from both
having to toggle their keyboard, and toggle push mode
to switch languages, one would probably want to implement
auto-switching into push-mode for LTR characters.

> * I'll probably add a fill algorithm for reformatting paragraphs to
>   the widget. Is this a desirable thing?

By this, do you mean simply breaking the lines where they 
wrap? I suspect, in any case, that this type of thing 
is probably best done in the context of a replacement
Text widget.
 
> While I'm at it I wonder about the following:
> 
> * Are there any plans of entering paragraph related tags, e.g. 
>   justification (right, center, left), margins, line spacing, and to be 
>   able to attach bindings to tags into the text widget?

Again, I don't see doing this with the current code base, which has
proved to be extremely fragile and prone to hard-to-find bugs. At
least some of this would be very nice to see in a replacement widget,
though my opinion is that the Text widget in GTK+ be rather lean - it
shouldn't attempt to be Emacs, MS Word, or Netscape - it should
concentrate on being good at editing moderate amounts of text with
moderate amounts of formatting.
 
> * How can keyboard bindings be defined in the resource file that
>   carries out editing commands?

You can look at the code in GtkMenu for an example of how 
to set up bindings that can be customized in the RC files.
(There isn't really much docs on this.) The system was
designed with the editable widgets in mind, and the appropriate
action signals have been added, but so far, nobody has
gone ahead and hooked them up. 

Regards,
                                        Owen