Re: My second file chooser proposal

> 3 Works from top to bottom and from left to right.
>   A human scans through information in this order, therefore the
>   widgets should be placed in this order. (See my previous mail for
>   more details.)

Umm.. I did see your disclaimer in your other email and I feel like perhaps
I should address it.

I think that in general, the left to right or right to left kind of thing
is a learned behaviour. Many Asian languages use RLTB for example so 
you read things vertically first instead of horizontally. If you did something
in english like that i suppose it would look like

w h
o e
r l
l l
d o

for "hello world". Most books in Japan are still printed this way, the newspaper
is printed this way, so for example, a Japanese person buying a newspaper would
immediately look at the upper right and scan vertically for the "top" headline.
Actually in the above example, it should start at the very right of the page,
but ah well.

Now for various reasons, in many cases Asian languages are also written
in the western TBLR.. i think it has to do with available technology,
mixing with english, but also the fact that at least cjk characters are
all meant to fit into squares, so you can in theory arrange them in in
which way you want w/o worrying too much about kerning and all that fun
stuff that western type has (i.e. nothing about the chars themselves dictates
an orientation).

Now on the other hand, most all computer systems in popular use default
to a TBLR kind of interface. Like I said, I think it is a learned thing,
and so far most computer users of the world have had no choice but to
learn the TBLR way. Once you realize that, you have to really think about
whether what we are doing is targeted at people who have used computers
for a while (and so are maybe used to having the "file" menu in the
upper left) or people who have never seen a computer before, in which
case they might look where their habits make them look.

In the former case, assuming TBLR is probably not so bad. Switching on them
is probably much more confusing than any advantage it may provide. And besides
we only care when we are 'learning' the interface. Once we know where a button
is, we expect it to be there every time.

In the latter case, I suppose we could make an interesting feature of gtk that
would re-arrange entire dialogs based on the locale. For example, one could
imagine a japanese dialog that looked like this

|                                          S|
|                                      +   e|
|                             +      + M   l|
|                         p p M  f f M y   e|
| o                       i i y  i i y     c|
| k                       c c    l l   D   t|
|                         2 1 P  e e M o    |
| c                       . . i  2 1 u c   F|
| a                       j j c  . . s s   i|
| n                       p p t  m m i     l|
| c                       g g u  p p c     e|
| e                           r  3 3        |
| l                           e             |

(ok this takes entirely too long to do on a text editor that assumes
TBLR.. but you get the idea)

This would require VBox'es becoming HBox'es and so on and so forth, and
would probably require a complete reworking of hte entier framework. Gtk
3 perhaps? <grin>

However given that most Japanese people can deal with TBLR w/o much
problem, it is probably not very worth it to make the entire interface
work in this way. If we really want to worry about these kinds of layout
issues, then we're talking A LOT more than just a FOSD here.
Interestingly, mlterm provides an output mode like the one above, but
just for textual output. One would really have to study if it really
makes a huge difference before going on and implementing such a
framework tho (and it makes custom widgets really difficult!)



(  Ken Deeter (Kentarou SHINOHARA)             (
 )                                              )
(  "If only God were alive to see this.. "     (
 )                             -Homer Simpson   )

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]