On Sat, 18 Jun 2011 09:34:42 +0100 garbeam <garb...@gmail.com> wrote:
> 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. > > I stopped writing it because i didnt wanted to reimplement a text editor > > stuff.. > > But i think that conceptually swk can fit well in different emvironments > > like desktops or phones.. But it really need a rebump to emhace layouts. > > Another thing is that its redrawing everything all the time. There's no use > > of damaged areas or so. I was waiting for anselm here. > > I would like to hear from your project. It looks interesting and it can be a > > swk2.. > > Well, my swk conclusion is, that its interface as of now is some yet > another GUI TK interface with limitations, but not really what I have > concluded it should be. > > I believe the most important aspect of a potential revised swk is, > that it should only be totally text based -- this limitation should be > good enough. Starting dealing with bitmaps etc. makes its purpose > blurry and might leat to the yet another GUI TK interface idea once > again. > > 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. > > I really think, the inner workings of such a library should be cursor > based, in that regard it is a question of abstracting the cursor > movements into a drawing interface and to define higher level stuff > using this approach. So the basic thing is a monospaced matrix. This > could also be used for a terminal and of course editor... That library already exists -- it's called ‘pdcurses’. We don't need more curses. Robert Ransom
