Re: [dev] st patch for draw() etc.

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Thu, 21 Apr 2011 10:20:41 +0200

On 20 April 2011 21:36, Claudio <smoppy_AT_gmail.com> wrote:
> Line buffer editing/positioning shouldn't be handled by st itself, it
> should be delegated to an external tools (most likely the shell). Else
> none of ^e, ^a, and such keystrokes should be available/hardcoded into
> the terminal emulator. We should think in terms of "shell container"
> rather than "terminal emulator".
> Well, I'm pretty aware it's a bit extreme but hope someone else will
> agree with me.

There is always the danger of designing something for re-use, that
isn't actually reused at all later on.

In dwm/dmenu and probably st I see some potential to share a single
implementation of draw.c. At first I wanted to create a lib for this,
but when Connor tested this approach in dmenu we concluded, that
additional library dependencies suck.

The best compromise we came up with is having a shared draw.c among
dwm and dmenu at least, which is on the agenda for dwm 6.0. Probably
this could also be used for st.

The idea is to allow different draw.c implementations, by default it
will hook on top of plain old xlib, but other backends are probably
worth to be considered as well.

In a second step I also see the potential to exclude all X related
functionality into ws.c, but this won't be a shareable implementation,
as the purpose of a WM is quite different to a classic X client like
dmenu. With a separate ws.c and a platform independent dwm.c core, it
will be easy to implement ws.c on top of wayland. However, it might
turn out, that the ws.c idea is crap.

There are also the projects libswk (pancake referred to) and the idea
of a libsuckless lurking around.

As for libswk: I'm a bit undecided which way this lib should go.
Currently it is designed as portable interface that pancake
implemented for different backends. I have not a great feeling about
the current libswk state tbh, I think if something with a broader
scope like libswk becomes a portable interface it will suck. I tend to
wait what wayland comes up with this summer and then I can imagine
designing a minimalist UI interface on top of wayland. The original
idea of libswk in my understanding was more like curses than a
traditional UI toolkit -- in theory one could implement curses on top
of a graphical user interface, and still have a tty fallback. But the
details are quite hard and the ideas of the people involved a bit
different I guess.

As for libsuckless: The idea was to put commonly shared stuff of the
most popular suckless projects into such a library. But I think this
might be a something far-away in the future thing to achieve.

Kind regards,
Anselm
Received on Thu Apr 21 2011 - 10:20:41 CEST

This archive was generated by hypermail 2.2.0 : Thu Apr 21 2011 - 10:24:02 CEST