On Sun, May 21, 2006 at 09:25:17PM +0200, Denis Grelich wrote: > 1) Liblitz should provide a total abstraction from X11 > insanity. The applications should not need to access any X > library calls, as long as they don't need them for explicitely > interacting with the X server. This would make applications > easily portable to any platform liblitz is ported to. Linux is > not /the/ OS (some say so at least ;) To accomplish this task, > it is necessary to provide a full-featured window abstraction > and widget model. It must be easy to use and fulfill all > requirements that dwm [dynamic window management ;)] poses > upon it. This is firstly: absolute values for the layout of > widgets should not be needed as long as it is reasonable. It > makes sense for multiline text widgets, but not for > single-line text widgets and to buttons only to a limited > extent. Then, widgets should be layouted in a dynamic manner > too, meaning some more or less extreme geometries (which > should be needed/useful for one application) should not make > the widgets unusable. On the other hand, in-window frames and > sub-windows shoulb be omitted, as they interfere with dwm. The > window and widget model should rather encourage to use > multiple windows that are layouted by the WM.
I think these requirements are far beyond to what I intend with liblitz. I would like to do smaller steps. I don't think designing liblitz independent from Xlib is a good idea. Have a look at the cairo project where this ends. I don't believe that there are chances to replace X in the near future, thus stick with X. > is possibly the most rational, at least for us. Thus, we must > handle text as a stream of variable-width characters. No > direct access via C-type arrays is possible. No use of all the > C standard library string functions, like it is done > throughout /all of wmii's source!/ As Unicode is a 21-bit > encoding, the amount of characters is gigantic, and this poses > extra difficulties. There are a lot of languages that are > possibly represented, and the amount of features NEEDED is > somewhat overwhelming. Even simple upper-lowercase mappings or > algorithms for line-breaking are not trivial anymore! One has > to deal with character classes, combining characters, grapheme > clusters or whatever. It is absolutely impossible to handle > that in C-style arrays for an application programmer. So, > liblitz or some other library has to provide that > functionality. I don't know of any library that can do that > and is not bloated like hell (the only library of that I know > that it can do almost everything in the Unicode standard is > IBM's ICU[2], the binaries are more than 5 MB large oO, and > the source is the incarnation of C Preprocessor). I am > convinced that this can be done better. The only way is UTF8 with 16bit types. > > I began with extending liblitz by implementing the basic > functionality of a text widget[3]. It is not possible to > proceed without further embedding into liblitz. It is not even > near to being finished, not only technically, but also and > especially in design. There is also some implementing of some > text handling routines. This includes the representation of > the text as a gapped array for insertion/deletion of text in > Θ(1) most of the time. Maybe it could be used as the default > representation of text in liblitz, just for simplicity's sake, > but maybe the routines can be rewritten in such a way that > they easily work both with gapped and non-gapped arrays. I > didn't find a way to accomplish this. > I hereby request some discussion on this topic, and especially > about the code I wrote so far. I followed your implementation, and I think it is a starting point as proof-of-concept, but it can and it has to be done in a much simpler way. I propose to do it in smaller steps. We cannot define an API before having a prototypical text widget which works well. We will need to implement liblitz twice in any case. > platforms (that's also what Java uses internally) sloc stats > of the source: cpp: 185897 (54.63%) ansic: > 148004 (43.49%) sh: 3452 (1.01%) perl: > 2938 (0.86%) sed: 14 (0.00%) [3] No way. Regards, -- Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
