Hi

On Tue, 3 Jul 2001, Eli Billauer wrote:

> I've been trying to imagine what a working biditext system should feel like,
> and I'm starting to think that if we want something that will be
> user-friendly, we'll have to rethink a bit.
> 
> I can't see the big deal in remaining back compatible with such a .rev-file
> based system. It's not like there is a lot of software depending on that .rev
> file (well, there was some written over the last week :) ).
> 
> Let's try to think what would make a user feel comforable. In my opinion, the
> switch from right to left should, if possible, be done on a window basis.
> Meaning: Give a quick interface to change the direction in one window at a
> time. The default may be set by .rev, if you insist.
> 

What do you mean by a "window"?

Do you mean a "top-level window"? This rouchly corresponds to
"application" and "process" (and technically: biditext works on process
trees!). Note that this may break badly under KDE2 (and maybe
gnome/bonobo?) where processes are often spawned from a main kinitd (?)
process, and processes can reside in top-level windows of other proccesses
without being created by the "host" process. (Is this really the case?)

You can also mean "A window with a certain name". Every window has a
"name" and a "class" strings, which generally indocate which program is
running this application.  If you have ever worked with fvwm/ice/afterstem
and tried to set the icon for some program, you would know what I mean. 

> The logic behind this? Let's face it: If you're running hebrew on Linux,
> you're about to view files with both logical and visual Hebrew at the same
> time. Let's imagine that you have two Netscape windows open, one page happens
> to be in logic hebrew, the second in visual. I think that anything but a nice
> way to switch only one of them, will be very annoying.
> 
> The nicest possible GUI, IMHO, is a little button on the title bar. Press it,
> and the text in that window switches. The refresh can be done on the entire
> window -- I think that the user will forgive a heavy refresh, if that ends up
> with readable text.

I'm not sure here. The user will not necessarily know why the app is
sudeny so slow. Keep in mind that if the connection to the remote app is
slow, a refresh operation is costly.

However, the windows in the refresh-deamon's list can be aranged in a
per-top-level structure, and allow such an operation.

> 
> This meaning playing with the Window manager. I think.  Does the window
> manager have any way to pass the application some attributes?
> 

Nadav has suggested some reading here.

Nadav: was your wording ("try to read" instead of "read") an indication of
the quality oof this doc? ;-)

BTW: WindowMaker currently has a code for something relatively similar,
which is a control of the keyboard language based on the active window,
and this is imlemented with a buttonon the title bar and a key
combination.

I suggest that you have a look at WindowMaker. I t has the beggining of a
GUI for handling windows differently based on name and class.

And we must all keep in mind that biditext is inherently limited, because
it works at a very low level, and the application is not aware of it by
any means. Therefore it cannot be easily cotrolled from within the app.

It can probably not be made an optimal solution for that reason.

BTW: I think that there's some commercial product that is doing something
similar:

  http://www.langbox.com

-- 
Tzafrir Cohen
mailto:[EMAIL PROTECTED]
http://www.technion.ac.il/~tzafrir

Reply via email to