On Tue, 25 Dec 2001, Tzafrir Cohen wrote:

> Hi
> As a reminder of the current status of R2L:
> It currently builds and works. However building may require editing some
> makefiles, or giving a big "make" command. R2l control front-ends are
> available for:
> Current files are in:
> http://www.technion.ac.il/~tzafrir/R2L/r2l-tarball/
> Is R2L Still Needed?
> """"""""""""""""""""
> Basically, Yes, until KDE3 and gnome 2 will become widely deployed. KDE3
> (actually: QT3) and gnome2 (actually: GTK+2) include reasonable
> bidirectional Hebrew support. Once all the programs on the desktop will
> have native bidi support, there will be no need for hacked bidi support.
> As for the hack value: this is a seperate issue.
> What is Missing?
> """"""""""""""""

considering the state of the project, i vote for making a release
*right* *now*. get everything we have now out where it will be somewhat
usable to people, then work in leisure on the rest of the stuff.
remember, some code/support is infinitely better than no code/support.

> * autoconf (or some other automatic configuration)
> I have an almost-working autoconf script now. However, I encountered soe
> problems. Anybody here with an experince with autoconf?

sorry, can't help there.

> * Documentation e.g: a man page, that will also document

i could probably help there. i'll try to scrounge an hour to write it

> * Missing features:
>   - KDE front-end
>   Also, In the light of a recent thread in linux-il I thought that the
>   following features may be useful:

see my previous remark - delaying the long awaited release in order to
add features would absolutely kill this project, imho.

>   - Tracing to a file (?)
>     Currently the debug tracing is done to the standard input. However,
>     it seems that some programs (like bonobo components) are created by
>     daemons with no attached terminal. It seems that if I want to print
>     traces I need to print it to a file.
>     I know how to pass the file name (through BIDITEXT_OPTIONS). However
>     writing to the file itself is more problematic, as there may be
>     multiple processes writing to it.
>     Do you think that adding this is something simple? (I have no
>     experince with file locking, etc.)

synchronization is never simple, more so when you have no idea what are
the working conditions of the application. i dont think the effort is
worth it, and it's definitely not worth it right now.

>   - r2llib implementation with window properties
>     This has been discussed in the past, and rejected. However, in light
>     of a program like evolution, it might be worth reconsidering.
>     The idea is that r2llib should hold the information not in a size of
>     a file, but in properties of a top-level window.
>     What will it take to re-implement r2llib that way?

someone who's familiar with both r2llib (not too difficult, if i may say
so myself, it uses a very easy to follow abstraction model) and window


Haifa Linux Club Projects Mailing List (http://linuxclub.il.eu.org)
To unsub send an empty message to [EMAIL PROTECTED]

Reply via email to