Re: [wmii] moving liblitz on

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" <garbeam_AT_wmii.de> 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