Re: [dev] Experimental editor

On 18 June 2011 09:34, garbeam <garbeam_AT_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 <pancake_AT_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
Received on Sat Jun 18 2011 - 16:09:06 CEST