Tzafrir Cohen
Tue, 24 Jul 2001 10:32:30 -0700
On Mon, 23 Jul 2001, mulix wrote: > another night, another release. and it's not even dawn yet. > > http://www.pointer.co.il/~mulix/r2l/biditext-mulix-0.04.tar.gz > http://www.pointer.co.il/~mulix/r2l/r2llib-0.08.tar.gz > > * please help test biditext. get it, compile it, install it, run it. * > * thanks to tzafrir for the rpm and doxygen stuff in r2llib * > * any X gurus know if XDrawString has a limit on the size of the string > it accepts for drawing? * > > r2llib Changelog: > 0.08: > added doxygen support and rpm support (tzafrir) I decided that it would be nice to use such a system. Generally it means that every function should be preceded with remarks in a special (but not very complicated) syntax. There is a utility (doxygen) that extracts this documentation, along with the general structure, to generate API documentation. But even without this utility, I believe those comments make the code more eadable. Any /** */ /** */ ? The output can be found at: http://www.technion.ac.il/~tzafrir/R2L/r2llib-doc-html-0.09/ http://www.technion.ac.il/~tzafrir/R2L/r2llib-doc-html-0.09.tar.gz > added packaging support to Makefile (tzafrir) Well, I decided to play with library creatin a little. Currently the r2llib is an independent library (still static, though) I have now added the compulsory r2llib-config (and also fixed a number of other small issues). You can now get: http://www.technion.ac.il/~tzafrir/R2L/r2llib-0.09.tar.gz http://www.technion.ac.il/~tzafrir/R2L/r2llib-0.09-2.i586.rpm (I hardly see the point for others to use that binary rpm, when they can just as easily install from the tarball, or create a binary rpm from the tarball. But since I need it for my system, I might as well just post it). Now I got to building biditext: I had to change the makefile, and even the sources. The change in the sources: - #include <r2llib/r2llib.h> - #include <r2llib.h> I think that it is the job of the nakefile to worry about the exact path of r2llib, right? or do we want to hardwire r2llib to be in <source_dir>/r2llib (or have the include files in a seperate r2llib dir under ${PREFIX}include/ ) Not a big deal, anyway. http://www.technion.ac.il/~tzafrir/R2L/biditext-0.9.2.tar.gz http://www.technion.ac.il/~tzafrir/R2L/biditext-0.9.2-2.i586.rpm http://www.technion.ac.il/~tzafrir/R2L/biditext-menu-0.9.2-2.i586.rpm The last package includes some menu items for the mandrake/debian menu system. It is in a seperate package because it depends on the mandrake menu system. Next I'll package the diffeernt r2llib clients (beginning, probably, with the dock applet ;-) ). > > biditext-mulix Changelog: > 0.04: > do_biditext8() and do_biditext16() now return the buffer on success > and NULL on failure > added internal 4096 chars limit test to do_biditext8() and > do_biditext16() > moved do_biditext8() and do_biditext16() into common.c > commo8.c, common16.c - removed > ripped out the biditext initialization code from > init_biditext(), now it uses r2llib_init() only > Makefile - made r2llib location relative to biditext dir There are some noticable differences. I tried running rxvt with and without biditext. In both I ran 'ls' on a directory that has a couple of subdirectories and compressed files. ls is aliased to: 'ls --color=auto -F' . Maybe color displaying with rxvt is a bit inefficient, and maybe it is just that this requires seperate XDrawString calls. /bin/ls doesn't have any noticable difference. But displaying a colored 'ls' takes long (around 2 seconds from 10 lines of text with no scrolling). I checked this also with biditext 0.0.3, and 0.0.3 seems to perform well. Maybe the problem is with the checks of the codepage of the font. (Hmm... This project started as something of a GUI to biditext) -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir