| |||||||||||||
TerminalsTerminalsPosted Dec 2, 2004 13:31 UTC (Thu) by hmh (subscriber, #3838)In reply to: A look at Xfce 4.2 by terminator Parent article: A look at Xfce 4.2
What we do need is an easy way to embed xterm inside another window, and control it through some sort of IPC mechanism.
Or maybe we could have a libxterm :-) with the xterm terminal engine.
Then we can write bells-and-whistles such as tabs, and still have a terminal emulator that actually works, instead of the usual utter crap people who like bells-and-whistles too much end up writing when they try their hand at writing GUI consoles and terminal emulators.
I have very little faith that anyone will write a better terminal engine than the one in xterm. Even rxvt does not come close (but it is still vastly superior to certain crap we have out there...).
(Log in to post comments)
Terminals Posted Dec 2, 2004 17:38 UTC (Thu) by iabervon (subscriber, #722) [Link] I think that it would be great if someone took xterm's core engine, cleaned out the junk (tektronic mode, etc), and made it into a library (with a small program to take command line arguments and run a program attached to the tty). I suspect that having other terminal emulators be based on replacing the widget set in this, rather than starting from scratch, would give much better results (while still producing scroll bars that people these days know how to use and menus people can find).
Terminals (xterm library) Posted Dec 2, 2004 19:22 UTC (Thu) by smoogen (subscriber, #97) [Link] Everyone I know who has started down this path (about 8 people so far) get about 2 weeks into it.. and then decide that rewriting it from scratch would be easier on the brain.
Terminals (xterm library) Posted Dec 2, 2004 20:35 UTC (Thu) by iabervon (subscriber, #722) [Link] I think there's a certain amount of work that could be done on it to clean up things that are obvious to fix (e.g., xstrings) or that are no longer desired (Tek mode). This would at least save future people 2 weeks of thinking they might get somewhere.
Beyond that, I suspect that there's some stuff that could be salvaged, which could be used to make a new program that works as well. charproc.c seems to me to be a relatively clean ANSI escape sequence processor (relative to, e.g., the kernel's console one...).
|
|||||||||||||