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 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
