Re: [dev] ncurses or ...

From: Carlos Torres <>
Date: Fri, 31 Jan 2014 09:35:07 -0500


On 1/31/14, Christoph Lohmann <> wrote:
> Greetings.
> A different paradigm has to be solved here. The paradigm of 2D inter‐
> faces to complex tasks. This could be done using swk. If you have swk
> done right, then it could be easily run in text or graphics mode.

Currently swk supports SDL and X11, I suppose you either add another gc_VT100
or something so that text is also available.

> The idea of the GUI abstractions is like in every software aimed at
> clueless programmers to add more and more layers.

I might be a little clueless :)

> That’s where the suckless solution should begin, by having reusable mod‐
> ules. For example there was the idea on the IRC channel to have a sepa‐
> rate GUI process handling the output and giving callbacks via a simple
> text interface over a pipe. That process could display the meta‐informa‐
> tion of arranging UI elements (buttons, listbox, entry, forms, menus)
> however it is needed. Of course supporting the OpenGL widget won’t work
> in text mode.

I started something i'm calling swt [1] which aims at the idea above. Though
i've been feeling rather clueless about the direction it should go. Currently
it has a fifo for input and an output file. its using libsl but it
will fork off on its
own with the need for further text control. it doesn't handle multi-byte yet.
and it can only do equidistant horizontal and vertical layouts of text regions.
you can create windows, and add text regions to those windows, you can close
windows and possibly remove text regions too...(so still work in progress...)
and you can somewhat toggle focus of those text regions.

The input fifo should handle things like window creations,
creation/manipulation if text regions within those windows and dynamic
mapping of key bindings that simply echo to the output for the controlling
script to do its thing. On the output side it either echos whats its doing
or errors, possible keybindings pressed and information about the state
of the ui. it probably should provide drawing to hidden Drawables for future
mapping, hiding/unhiding of regions. and multi-byte or UTF-8 of course.

With regard to widgets i think for menus we have dmenu, listboxes
might be needed given the different modes one can toggle, perhaps
a tree view too. buttons seems a bit like a hack to a bad interface
or they should be simple standard key mappings (vim?). forms
sound like glue around the former. maybe there is a status bar to
suggest actions to perform or caret navigation as soon as ":" is pressed
like line numbers in vi, every major widget/text region has an assigned
number...that could get out of hand.

with swt i've tried to define how one would interact with it to create the
UI, it could be driven by any language able to read and write to files.
its interesting that surf and dwm just got fifo in them...perhaps tabbed
should too. perhaps really we should have separate embedable
applications with fifos. one for listboxes, one for tree views, an embedable
lil'd (son of dwm) for layouts within an app, a keyboard listener for focus

this feels like a re-invention of the wheel...

One aspect i feel should make this effort legitimate is the amount of
keystrokes it takes to navigate this environment. i would like an
environment that is navigable by keyboard. but i sometimes question
the efficiency of it. and certainly if you are pressing more keys with this env
when you could quickly click on something with the mouse, then the battle
has been lost. (or is that a smell of a bad application?)

> What’s left is writing this by pointing out the really needed widgets.
> Here new ones evolved, like the command line of vim added to browsers,
> which could be reused in such applications to always have all UI ele‐
> ments available via a text interface and make it automatically script‐
> able. Then the menu, buttons, of course an editable text field with the
> $EDITOR you wish, some way to display graphics (w3mimage for st maybe?),
> tables ….


Received on Fri Jan 31 2014 - 15:35:07 CET

This archive was generated by hypermail 2.3.0 : Fri Jan 31 2014 - 15:36:17 CET