On Mon, 29 May 2006 15:01:53 +0200 "Anselm R. Garbe" <[EMAIL PROTECTED]> 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?
pgp6v3PLEu58G.pgp
Description: PGP signature
_______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
