Re: [wmii] moving liblitz on

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