Re: [dev] mret

You are doing it wrong. Mixing code and data is one of the worst things you can do. Not only for security reasons.

Apart that depending on tcl/tk is somewhat sucky. Stetically and in size.. And not really keyboard friendly.

The mimetype hint used in termkit is somewhat more elegant, but sucky too.

If you want to make a decent ui design you cant expect programs designed in the 70's to work.

Plan9 just disables all screen control stuff to just a serial communication channel. And all the graphical stuff is done on top of it using a different channel with a text based protoxol. Not executimg code, just using a simple api.

The monster you wrote looks fun to see.. But I dont thunk is the way to go. Libdraw and swk are probably much suckless that this.. And the point is that things should be simpler. So, I would suggest keeping st as is. For running standard console programs.. But we need a way to describe interfaces in a nonlang/arch/backend specific way.

Swk did some good job here.. But i stopped when i realized i was redoing stuff that doesnt relays on swk... Like text editing.

Im thinking in the possibility to embed st as a libdraw buffer and e able to run vi inside an swk app seamlessly and without depening on x11. As long as swk runs in sdl too.

What i think we need o get a suckless ui is a better libdraw. And build the rest of stuff on top of it. So we can using all unix programs as they are without depending on weird interfaces, 3rd party langs and magical monsters.

My 5c

On 25/05/2011, at 16:50, Kamil Cholewiński <harry666t_AT_gmail.com> wrote:

> Hi all,
>
> I recently did some UI experiments, and wanted to share the results
> and ask for insights.
>
> It's been long that I've suspected that there must be something
> fundamentally wrong about depending on emulation of a 1970's piece of
> hardware in order to give power to our command lines. So far I've only
> been trying out ideas on paper and in my head, thinking what could
> work the best. A few days ago I saw TermKit[0] announced, also saw the
> thread on this list[1]. So I've decided to turn some of my ideas into
> code and over the past few days came up with mret. Grab the code[2],
> it depends on Python and Tkinter.
>
> Basically, it's just a working prototype. It's a frankenstein made up
> of bits of Python, shell and Tcl. A quick and dirty hack that gave
> interesting results. And I believe that a rewrite in C or Tcl will be
> necessary - it seems that Python doesn't really give you complete
> control over Tk.
>
> So, what you get is something like a terminal emulator, but not
> exactly. There's a window with two buffers, one for input and one for
> output. You type in shell commands into one and see their results in
> the other. You could choose which shell to run - so far tested only
> with dash, but it might work unchanged with python, rc, whatever.
> Surprisingly, many standard Unix commands either Just Work, or fail
> gracefully (like su, complaining that it isn't attached to a
> terminal). I even did an "aptitude dist-upgrade": when it asked
> questions interactively, it worked, and it didn't mess up the output
> buffer trying to "draw" progress bars during download.
>
> However, this isn't really what is interesting here. (As a matter of
> fact, mret is incredibly crappy as a typical terminal emulator.) The
> nice thing is that Tk's text widget is actually a real editor widget.
> Features like: dynamic line wrapping upon resize, X selection,
> scrolling - those all work out of the box with no additional code. But
> the one thing I really like about Tk is that the text widget can embed
> arbitrary stuff in it: images, drawable canvases, buttons, progress
> bars, entire windows, whatever you wish.
>
> So I've been trying to come up with a sane interface exposing this
> capability to programs and scripts running under mret. I thought about
> creating an ad-hoc language of escape codes, but that would probably
> end up being a total mess and still wouldn't expose full capabilities
> of Tk. So, why not simply pipe Tcl commands right into the interpreter
> governing the Tk GUI?
>
> In the end, you are able to run scripts like this:
>
> #!/bin/sh
> [ -z "$WISHPIPE" ] && exit 1
> echo "image create photo mypic -file mypic.gif" >&$WISHPIPE
> echo ".mret.output image create end -image mypic" >&$WISHPIPE
>
> WISHPIPE is exported by mret and holds a file descriptor, pointing to
> a pipe. At the other end of that pipe is the same Tcl interpreter that
> Python uses to draw the Tk GUI. The interface seems fairly nice to me,
> and properly written programs should be always able to detect if they
> can take advantage of mret's capabilities.
>
> There are a few simple scripts in the distribution. Try typing these
> commands into mret's input:
>
> ./button.sh
> ./image.sh sr sr.gif
>
> I imagine that if this thing would take off, there could be a standard
> library of scripts for displaying and manipulating thumbnails,
> progress bars, canvases, whatever we could come up with. Also, it
> seems that there's much more you could do with Tcl&Tk: I'm thinking,
> dynamically adding a statusbar widget to the window, hacking the input
> buffer to do history/command completion, things like this. But I'm a
> Tcl newbie so no idea.
>
> Feedback is very welcome.
>
> Thanks,
> Kamil
>
> [0] http://acko.net/blog/on-termkit
> [1] http://lists.suckless.org/dev/1105/7965.html
> [2] http://diogenis.ceid.upatras.gr/~cholewinski/mret-0.2.tgz
>
Received on Wed May 25 2011 - 18:55:59 CEST