screen and dvtm and screen and dvtm and

Edit: Unfortunately, the images originally included in this post are gone, because of hosting problems in late 2009. My apologies.

I touched on an idea in the last post, of running a tabbed terminal emulator on a graphical desktop, and partitioning each emulator with dvtm. The idea was that it would allow an immense number of console-based programs to simultaneously co-exist, in a way that really has no impediment aside from your own needs and your ability to keep track of all those things.

The fact is though, that part of that idea stemmed from using both dvtm and screen in tandem on my Thinkpad, which is running completely without X and throwing everything against the framebuffer. And the amount of flexibility there is likewise staggering.

Maybe this screenshot (framebuffershot?) will give you an idea.

See, screen itself can do split screens, and you can bounce between applications individually, pane by pane. And as you can see there, dvtm is quite happy to further segment the available screen space into smaller and smaller areas.

It’s like those Russian dolls.

Perhaps its just me, because of the proximity of it all, and the immediacy of how flexible the two are together. But to know that screen itself is keeping everything neatly bundled together, and can show two or three at a time, and all that on an 800×600 screen … it’s staggering, and cool at the same time.

This is a clean installation of Crux, by the way. Start times at 550Mhz are just over 12 seconds, and I have .screenrc set up to spawn dvtm with elinks, calcurse and alpine all at once. moc is on one window, mc on another, and htop (in a much-customized state) is on the last.

And best of all, I have my customized version of MPlayer for watching my DVD rips on the framebuffer. What in the world was I bothering with X for?! 😯