Re: [dev] Experimental editor

Swk is based on a monospaced drawing area.. You just have a simple layout foo plus the possibility to draw on sub buffers.

Which limiations do you see in swk?

I dont want a mainframe like ui. It will not be usable in touchscreen interfaces for example.

One thing i mss in swk is the possibility to handle global keybindings.. So you can use the interface without having to move between the widgets.

This can be done like in config.h at every application that uses swk. We just need to register that array.

Those events should be handled after the widget event handling callback (text edit..)

On 18/06/2011, at 11:01, garbeam <garbeam_AT_gmail.com> wrote:

> On 18 June 2011 09:44, Robert Ransom <rransom.8774_AT_gmail.com> wrote:
>> On Sat, 18 Jun 2011 09:34:42 +0100
>> garbeam <garbeam_AT_gmail.com> wrote:
>>
>>> 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.
>>>> 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.
>
> I did not intend to say it should be curses compliant as this would be
> a nightmare. I was rather referring to the concept of being cursor and
> matrix based in the core as this will make a very simple interface,
> that can work across a range of devices.
>
> --garbeam
>
Received on Sat Jun 18 2011 - 11:13:05 CEST