On Sun, May 21, 2006 at 10:03:46PM +0200, Denis Grelich wrote: > On Sun, 21 May 2006 21:53:07 +0200 > "Anselm R. Garbe" <[EMAIL PROTECTED]> wrote: > > > 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. > > Okay, sticking with X is alright. But as an application programmer, I > really don't want to cope with at least X11's drawing stuff. I don't > want to care about sizes, font handling, screens, displays and so on.
Yes, that I agree on, and this can be done internally. > > The only way is UTF8 with 16bit types. > > How is this supposed to work? Unicode is a 8-bit encoding, characters > can be up to 4 bit, and grapheme clusters can be as large as they want > (and you have to handle the clusters as /one/ character. Anything else > is just wrong.) For 0000 0000 - 0000 07FF you use a 16bit Rune, for 0000 0800 - 0010 FFFF you use two 16bit Runes, that is what I mean with 16bit types. (I only looked at the libutf9 implementation until now). > > > 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. > > We don't need to define all of the API at once. Just step by step what > is needed, and adjust it if it is needed. Yes. -- Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
