Re: [wmii] moving liblitz on

On Mon, 29 May 2006 15:01:53 +0200
"Anselm R. Garbe" <garbeam_AT_wmii.de> wrote:

> On Mon, May 29, 2006 at 02:31:23PM +0200, Denis Grelich wrote:
> > Now that we discussed the outlines of liblitz' future, we now need
> > to start with some specifics.
> > The first decision that has to be made is regarding text handling. I
> > would opt for dropping char* for strings and use some more
> > sophisticated structure instead. This would have several benefits:
> > a) one could use a gapped array internally for text, so that
> > insertions work in constant time.
> > b) as many operations on UTF-8 characters change their byte-length,
> > this would also work in constant time and wouldn't need any
> > reallocations most of the time
> > c) we wouldn't need two distinct sets of string manipulation
> > functions, one for gapped-array text, and one for char*-text
> > Of course random access in constant time would be quite lost, but on
> > the one hand, constant-time random access is seldom needed, and on
> > the other hand, a better access time than O(log(n)) still can be
> > achieved with some buffering.
>
> Why do you want do that? Within the widget ok, but I don't the
> need anywhere else. The widget should have a char * interface,
> whenever text is applied, it should handle char *, and convert
> the stuff to an encoding it is appropriate for the widget.
>
> I don't see any need to clutter the whole code with some
> obfuscated string replacement structure. Use instead something
> like src/cmd/sam/string.c (which should be sufficient for our
> needs).

That would mean duplicated code, or at least two sets of functions. One
set operating on char*, one set operating on gapped arrays that is only
used in the text widget, or in routines directly working with the text
widget. I suppose this is also some kind of obfuscation.
Conversion between gapped-array and char* doesn't work without copying
and thus is quite unperformant. Also, operations on a UTF-8
char* are quite unperformant, so we would pay in performance for that,
most of the time. Of course, Xlib and stuff still expect char*.

> > Then, how to get rid of all the Xlib crap from drawing routines?
>
> We can't, who else should draw than Xlib? liblitz' interface
> should hide all special X stuff in some Blitz * type

Sorry, that's what I meant

> the implementation of your widget, the labels and several drawing
> routines _has_ to use Xlib of course (if we want to port liblitz
> one day to something else, then this implementation has to be
> redone for a different toolkit). Whenever necessary use the
> blitz routines internally as well, but the real work has to be
> done with Xlib.

I am just thinking of functions like xdrawtext or so, which could be
used in other places than liblitz/draw.c too.
But well, suppose that this is the way to go.

> > Atm, the label drawing routines can't be really used for the text
> > widget for example, as they do spacing at the left and right and
> > text shortening themselves, which interferes with the text widget's
> > routines. Should every widget have a BlitzDraw thing? This would
> > allow to set
>
> Each function should take a Blitz * context structure which
> contains the important pointers to Display, Screen, etc. I'm not
> sure we need a BlitzDraw structure, we need Blitz, and
> structures for all primitives like BlitzColor, BlitzFont,
> BlitzLabel, BlitzText, etc. Some are already there.

So BlitzDraw is going to be removed?