Re: [dev] mret

From: Kamil Cholewiński <>
Date: Thu, 26 May 2011 02:09:03 +0300


> It would be nice if the textbox can be more 'canvas-like', such as
> drawing a horizontal or vertical line to indicate each individual
> commands output? Stuff like that.

Right now you can embed virtually any Tk widget or any image, simply
use the wishpipe. I only started learning Tcl&Tk a few days ago, so
can't really tell if it has any standard way of doing such lines.

The problem here is to tell when did a command complete. A subthread
waiting for grandchildren of the main thread? It's gonna be a hack
either way. See the next paragraph.

> imo (and stealing some ideas from Kurt) you should have separate boxes
> which are filled with the output of the given command; you just type a
> command and the box appears and starts to be filled. You can then type
> your next command whenever you want, completely asynchronously, and
> that's added on the end, and starts to be filled, too. You can see
> past jobs, kill them, etc... That's what I'd like to see in a
> terminal, stuff that really improves the user experience just by
> making things less like a teletype. Can we prototype things like that?
> That would be cool.

mret did that in its previous life. This is high on my TODO list, I've
already toyed with that, it's not obvious how to make it not suck, and
generally much harder to get right than I thought it'd be. Basically
you will need very tight coupling between the shell and the terminal.
Your terminal needs to *become* the shell. It needs to know when
processes are started, ended, needs to do its own command parsing,
etc. Actually nothing is simpler than using popen(3), it was way more
hassle to make mret fork and keep a real shell in the background. But
it starts to get funny as soon as you realize that "cd" doesn't work.
Or "export". Or "ulimit". Or, for that matter, any other functionality
provided by the shell...

I'll try to revive that older version, clean it up and post here.

> Like I said in the TermKit thread, I think the best approach would be
> to use the existing Xembed protocol.

One of the things I've been considering is how to make a mret-like
terminal possible with nothing but a grid of characters, like a VGA
console, or on top of ncurses. If we could provide a standard and
well-defined set of widgets, some of them (like progress bars) could
be supported even if we wouldn't have a graphical display.

> I don't like the dividing line between the input and output, so
> much, but that's just an aesthetic choice...

No idea how to get rid of it. I guess it's a part of the price for
using a high-level GUI toolkit.

Received on Thu May 26 2011 - 01:09:03 CEST

This archive was generated by hypermail 2.2.0 : Thu May 26 2011 - 01:12:02 CEST