On 18 June 2011 09:34, garbeam <garb...@gmail.com> wrote: > The closest thing that came to my mind is this idea of seeing swk as a > curses replacement. With this, the clients that are written with it, > could also run perfectly fine in text mode, but if you have a > graphical environment at hand, the implementation could pack the UI > more efficiently into graphical use.
The way my abstraction library is working at the moment, we can basically draw rectangles or text. The interface for this editor (I need to come up with a name...) will more-or-less be a lot of text with a scrollbar on the right. I don't see any need for much else. If you were to write a curses back-end I suppose you could snap to the nearest cell; but I'm leaving that as an exercise to that poor soul. On 18 June 2011 09:21, pancake <panc...@youterm.com> wrote: > The plan for swk was to move all drawing stuff to draw.c at some point. I > will be happy to hear from what you are writing for. As we're trying to abstract the interface completely, and not just provide useful X utility functions, I'm not using draw.c, since its and libdpy's (as I'm calling it right now) interfaces don't quite map one-to-one. > I stopped writing it because i didnt wanted to reimplement a text editor > stuff.. That's the problem with widgets: you need to basically write a text editor. Just using drawing routines, on the other hand, means we can just implement a few functions and then write the text editor as an actual text editor. > Another thing is that its redrawing everything all the time. There's no use > of damaged areas or so. I'll be solving this with a poor man's approach, which should basically mean that everything is redrawn only when the window is resized, and otherwise the editor can redraw only what has changed or been damaged. There are even more sophisticated approaches than this, but I don't think we need to care. Thanks, cls