Re: [dev] TermKit

On 20 May 2011 14:17, Kurt H Maier <karmaflux_AT_gmail.com> wrote:
> I've never understood why there isn't a terminal with one window per
> filehandle.  Something like sam's interface, but the top window would
> just hold stdin and the bottom window should toggle between stdout and
> stderr.

I suppose that could be a useful interface, so long as it was clear
which commands are associated with which output. Otherwise stdout
could get a little messy. Also, by default stdout and stderr ought to
be combined, perhaps with stderr in yellow or something.

On 20 May 2011 14:21, Yoshi Rokuko <yoshi_AT_rokuko.net> wrote:
> actually i really like this 'replacing the term entirely' very much,
> that is why i sometimes use the monocle layout on my old thinkpad x30.

I prefer it to the "create an entire new window" approach, but for
smaller things I'd rather they were drawn directly to the terminal so
I could see them later on just by scrolling up.

On 20 May 2011 14:27, Dieter Plaetinck <dieter_AT_plaetinck.be> wrote:
>  I think a fd to write something to like "here's an image, please
>  render it somewhere" is better than cls's suggestion of having apps
>  directly write to the terminal.  I think the latter idea would get
>  messy quickly. It's as if X windows would draw themself to the screen
>  rather then having a window manager take care of it.

I disagree. Your approach is as if X windows would have no control
over their interface besides "draw me now!" My approach would probably
involve Xembed: the program creates a new window, the terminal embeds
it into the right place, and then the program can draw to this (like
how tabbed works, only downward-scrolling). Each process can ask for a
little space in the canvas and they can draw only within that.

(Can you XCopyArea a child window?)

cls
Received on Fri May 20 2011 - 15:40:39 CEST