On 20 May 2011 14:17, Kurt H Maier <karmaf...@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 <yo...@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 <die...@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
