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 > BIDITEXT_OPTIONS 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 properties. -- mulix http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net/ ------------------------------------------------------------------------- Haifa Linux Club Projects Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
