Re: [wmii] moving liblitz on

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).

> 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, 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.

> Liblitz should provide better geometrical primitives drawing routines,
> for example for filled and un-filled rectangles, and for text.
> blitz_drawlabel and friends should be replaced by a label widget.

Don't add any drawing routine, if it is not needed. We only add
new functions if they are really needed.

> 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.

> fonts and colours on a per-widget basis, and would eliminated much
> copying/changing properties of the window's BlitzDraw. I suppose dpy
> and screen can be incorporated into BlitzDraw too, or will that
> interfere with Xinerama support in the future?

Yes, that should be on widget basis (everything else, like using
a global structure, would be too messy).

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361