Good lightweight xterm to modify from?

[IsaacKuo]

I'm thinking of making a vector graphics based terminal program that uses vector graphics instead of normal fonts for a retro-demo look. I can see at SourceForge there are quite a number of terminal programs I could start off with. However, I'm wondering what would be a good lightweight one to start off from.

I notice aterm is based off of rxvt. Would rxvt be a good one to start with?

Eventually, I'm hoping to create a mini desktop environment with vector based pseudo-windows within a single full screen X window. These pseudo-windows could have vector based terminals, file browsers, text editors, and perhaps other applications, all featuring transparency, shadows, rotation, and pseudo-3D perspective transformations. Since everything would be vector based all sorts of flashy special effects could be possible without too much processer power.

But to start off, I'd just like to just implement a simple X terminal. Any suggestions on which one would be best to start off from?

Thanks!

[maccorin]

i would say just 'xterm', but if your going the OGL route (which i guess i'm just assuming...) it would probably be easier to just start from the beginning, i built a in-game console for a gaming engine in OGL, it wasn't to difficult, I just used glut for the fonts, but i guess you could use whatever you want ;p

[IsaacKuo]

OGL? Do you mean Open GL? I don't know any 3D graphics programming. I was just going to use X. The vector graphics I'm talking about are simple straight lines and solid filled polygons--like in old fashioned screensavers.

I don't want to assume 3D acceleration--for one thing, my computers have Ati cards and I don't even know how to get 3D acceleration to work with them.

Anyway, I'm a little too much of a novice to start from scratch. I have no idea how to support all of the "visual" stuff. Like when running vi, vi is able to clear the screen, move the cursor in any direction, scroll vertically, delete and insert text, and even detect the screen dimensions...just looking at all of the VT102 escape code sequences is daunting to me.

Anyway, thanks for the advice! I'm looking at the source code for xterm as well as rxvt.

[maccorin]

yea, i'm talking OpenGL when i say OGL, IMHO OGL is _much_ easier to understand/learn the X11, X11 has a horrible interface as far as I'm concerned, so I stay as far away from it as possible.

[psi42]

Well, as far as xterm goes...


/*
* W A R N I N G
*
* If you think you know what all of this code is doing, you are
* probably very mistaken. There be serious and nasty dragons here.
*
* This client is *not* to be taken as an example of how to write X
* Toolkit applications. It is in need of a substantial rewrite,
* ideally to create a generic tty widget with several different parsing
* widgets so that you can plug 'em together any way you want. Don't
* hold your breath, though....
*/


Found that when I happened to glance at the source (I had a crazy idea I could pull the xft code out of it and slap it into aterm :rolleyes: :D ). One day I'll be able to do something like that. Maybe. :)

~psi42

[maccorin]

LOL @ that comment...

i guess i should check out the source before i recommend something to be used as a code base next time, huh?

[IsaacKuo]

I think I may have been barking up the wrong tree, in any case. Considering my eventual goals of supporting multiple terminals, and my rendering strategy, maybe GNU screen is a better place to start from.

My rendering strategy is more like a videogame than normal desktop software--the display is built up out of components such that the whole screen gets redrawn at once, instead of being incrementally updated. This is good for a videogame, particularly a 3D videogame, where more or less the whole screen changes from moment to moment.

Hopefully, I can modify GNU screen so that I can scrape text data from the "virtual" screen buffers for display. The "attached" screen is not displayed in any different way; any output which would have streamed to std.out would simply be ignored. "Attaching" the currently focused screen would only be used for the sake of channeling keyboard input.

Well...I think it could work...

[maccorin]

i'm not sure what your driving at w/ the gnu screen

i think your making it a bit more difficult then need be....

heres some (very) psuedo code of what i would do (similar to what i did for a game console)



FILE *pipe

display_output() {
while(1) {
fread(pipe);
display();
}
}

main() {
mkfifo("/path/to/pipe.3dterm"....);
if(!fork()) {
freopen("/path/to/pipe.3dterm, .... , stdout);
execve("/bin/bash", ...);
}
pthread_create(....display_output....);
pthread_join(....);
}



you'll also need to redirect stdin, and stderr, but writing pseudo-code sucsk w/o a working tab key... damn forums

[IsaacKuo]

Well, I'm thinking that GNU Screen already handles all of the VT100 emulation and such so that somewhere it will be keeping convenient screen buffers that I can essentially dump to display.

Otherwise, I'd have to figure out all of that stuff myself.

For your console, did visual programs like vi and emacs and lynx work? I can't imagine how they could have worked unless you put some good effort into the "display()" portion of the code. Right?

[maccorin]

Originally posted by IsaacKuo
Well, I'm thinking that GNU Screen already handles all of the VT100 emulation and such so that somewhere it will be keeping convenient screen buffers that I can essentially dump to display.

Otherwise, I'd have to figure out all of that stuff myself.

For your console, did visual programs like vi and emacs and lynx work? I can't imagine how they could have worked unless you put some good effort into the "display()" portion of the code. Right?

no, they didn't... my console didn't run bash either, it ran a scripting language i made for the engine.

for those things i _think_ you need to look into curses, and readline, but i'm not 100%

[IsaacKuo]

Or maybe I'm just overestimating how difficult it is to write a VT100 emulator. It would be nicer that way, in the long run, because it could potentially lead to special effects like smooth scrolling and animated text "writing".

[maccorin]

after thinking about it for a few, I'm _really_ not sure how you would get the vt100 functionality, i'm sure it's not to difficult (i hope...), check the source of others like you were saying, i've been talking out of my *** for this entire thread i think.

[IsaacKuo]

Okay, at this point I've given up on modifying an existing term and will start from scratch more or less as you suggested. GNU screen's source code is bewildering and bloated--probably to do with its multi-viewport capability.

I've found a number of very slim examples of VT100 emulation in source code in various languages. The easiest to understand so far is a Visual Basic VT100 emulator :p ...but its implementation is very limited. Still, it's a good start!

[bwkaz]

Also look into the ptmx manpage, and the pages linked to off from that.

You'll need to have a pseudo-terminal available to the programs that you run in your emulator (that's how you do the VT100 emulation) so that they can communicate with you.

Basically, your program opens /dev/ptmx, then passes the file descriptor that you get back to ptsname() to get the name of the corresponding slave terminal device. Then you pass the file descriptor to grantpt() and then unlockpt(), then you fork.

In the child, you close file descriptors 0, 1, and 2, and then open the string that you got back from ptsname(). This is the slave end of the pseudo terminal. Anything that the child writes to this file can be read from the file descriptor that the parent has, and anything that the parent writes into its file descriptor can be read out of this file. Once you've got the file open, dup() it into file descriptor 0, 1, and 2 (stdin, stdout, and stderr).

Then exec the shell (or vim, or whatever).

The shell will write VT100 escape sequences into the slave end of the PTY, and the parent will be able to read them out and do whatever is appropriate. You'll probably want to also set the TERM variable to be something appropriate to the terminal emulation that your master is capable of doing...