Hacker News new | past | comments | ask | show | jobs | submit login
VTM: A Text-Based Desktop Environment (netxs.online)
524 points by mssdvd 64 days ago | hide | past | favorite | 141 comments

Related: The MGR Window System https://hack.org/mc/mgr/

“MGR provides each client window with: curses-like terminal control functions, graphics primitives such as line and circle drawing; facilities for manipulating bitmaps, fonts, icons, and pop-up menus; commands to reshape and position windows; and a message passing facility enabling client programs to rendezvous and exchange messages.”

Essentially, each window was a souped up ASCII terminal with extra escape sequences which implemented primitive graphics. It competed with X-Windows on low-end workstations during the 1980s.

Discussion: https://news.ycombinator.com/item?id=18742611

Love it! I have a strange desire to try to make that work in WASM over HTTP/2 and hack in MGR server hyperlinks.


SVG over HTTP/2 in Wasm with WebGL1 (for compat)

Ran this on my Atari ST for a bit back in 1990 or so. And then again on my 486 running early Linux a couple years later.

It's a really neat idea. But it was of limited use as not many applications were made for it.

I wonder how hard it would be to write an MGR terminal emulator today.

I suspect a lot easier with modern graphics libraries and so on

Not sure I'd bother with MGR itself, but instead do something similar.

It's not as compelling now that we don't do much over serial links anymore.

The modern day version of this really is the browser/HTML.

I remember being intrigued at the time by the idea of using this protocol over a MUD (telnet / TCP socket carrying text) connection.

The width of the display used in the screenshot appears to be less than 150 characters. Why would you add the clutter and distraction of transparent windows with frame decorations in such a limited environment? 30% of the real estate is consumed by elements that don't present any information to the user.

On a modern display, this could far more productively be replaced with (1) any number of tiling WMs with console terminals in the panes (I use stumpwm for this), or---and you don't even need a GUI/WM for these---tmux or screen, or even emacs -nw, which give you a much more configurable and robust text-only environment. My normal working environment is a pretty heavily customized tmux (including powerline and full 256-color/unicode support) running on a machine that doesn't even have a GUI installed. (I do cheat a bit by using kmscon---or fbcon in the past---to get colour and font support on linux vttys.).

The demo video (https://www.youtube.com/watch?v=fLumnSctakY&feature=youtu.be) reveals that this is not just a traditional window manager for a static screen, it's got a much larger virtual canvas that the display can scroll around in. So there's a LOT more space to make an aesthetic decision for big, character-wide window frames.

Seriously go watch the video, this thing feels like it's got a foot in the realm of UI roads not taken like Raskin's zoomable UI, text-mode is maybe more just a way to keep their focus on thinking about the interactions without having to worry about drawing a bunch of pretty widgets.

Yeah, I see it. I just don't get it. There's an awful lot of UX work being done to preserve an illusion that you have a bunch of fixed-size consoles that are arbitrarily arranged in a 2d space. Which, I guess, is the defining metaphor of GUI interfaces, but if that's what is desired, why create a console-only (if only in appearance) GUI? Text buffers in emacs or panes in screen or tmux can be made to have arbitrary size and dimension if you want to turn off wrapping and keep a longish scrollback. You can have as many buffers as you want, as many as your screen can accomodate visible at once and easily navigate them as you like. All you have to give up is the conceit that windows have independent physical size and location and embrace one that holds that you can have an arbitrary number of text buffers available to arrange, swap, hide, show, etc. Not trying to be nasty, but this feels like a bit of a cargo cult: someone stuck in the windows GUI metaphor trying to create a version of CLI metaphor they don't fully grasp. Of course, the fact that those of us who prefer the CLI metaphor are rapidly dying off is relevant here---but seizing all of the disadvantages of an all-text environment without any of the advantages seems ill-advised. That said, no one needs my approval. If this works for you (and I'll readily admit it's kind of cool), what do you care that I don't get it.

Typing text into a terminal/buffer is easy. But remembering all the shortcuts or cammands to resize and move windows in termux et.al is hard. Resizing and dragging with a mouse is easier (or fingers on a touch screen/interface)

I agree that it feels really confused but if I can get it running one day with the ability to save my sessions, I would gladly flip between this and X+i3 for my daily driver.

What I see offered here is a way of mapping a huge, non-software project more loosely than a strict classification-based directory/file structure. Specifically I've been slowly fleshing out my own fantasy world with lore and history. I tried the live demo and I can totally see this meshing really well with the part of my brain that likes fiction because it can be a little messy.

I also think the friction of learning a new UI would be a benefit here in reducing the amount of "laptop fatigue" which keeps me from writing less technical stuff after wrestling with a bug all day.

At the end of the day, its a fun project. Plus tmux can get annoying configuring behavior to feel like something more native in terms of mouse use consistently. Either it works great scrolling up in the shell or it works great scrolling with an editor open, never both.

Wow. The organizational lines and brightly colored windows make it look like a flower.

Things like borders may be empty of content but that doesn’t mean they don’t help you see and understand other content more easily.

Agreed. But using an entire character-width for that purpose is extravagant in this example (use of background colour would be better. Right now, some of those windows are !0% border). In a larger area, you can use unicode or even the drawing characters in MS 8-bit ASCII for a single-pixel hairline plus padding for both windows' text). I guess my take is that this is sacrificing an awful lot of real-estate to simulate overlapping windows, which is a feature of dubious utility in a pure text environment. "Users expect them" is probably the most common and egregious excuse for bad UX design, but I do understand why.

Window transparency is actually a way to increase the information density; if you set the transparency just right, with a bit of practice you can essentially view the contents of several windows at once in the same space. For a long time I used a laptop with only XGA (1024x768) resolution, and writing code in a semi-transparent window with docs, IM, and several other windows underneath made the small screen far more usable than it would be otherwise.

Except in this case, it's not real, you can't read any characters below another window.

80x24 is the default terminal height. I mostly use this size on all of my projects. It has many favors: compatibility everywhere, tiny bandwidth, etc.

And, of course, ed is the default editor. :-) I exert geek dominance over introduction to C students by demoing using ed to modify a source file. After which I amuse myself for the remainder of the term: "Source Control? Syntax highlighting? Luxury! When I was young we had to hand-magnetize knitting needles and edit files one bit at a time directly on a Winchester drive!"

More seriously, I think the 80 column width is just too constraining with more modern languages that aren't remotely as terse as C–not to mention a limit that aggressively militates against in-line commenting. We also have monitors and fonts with resolutions that permit easily reading much denser use of the visual display. I mostly go with 120 chars now (in practice, that means that lines still won't wrap when I print source code files) and however many lines fit into the display pane.

Even though 120 fits comfortably on the screen, I find it leads to sloppier code than 80 or 90. The latter exerts pressure to "do one thing per line, and make it neat."

Ime this is true of modern langs like ruby or javascript or Go, as well as older langs like bash. But I know this is a religiously contentious subject, so to each his own.

I like 80 for my Go projects.

Anecdotal, but- It does feel like a good visual approximation and when I start to run close to it I usually pause and figure out if that code needs attention.

Yeah, why did we ever stop using it as default for everything. I grow weary of graphics and options with said graphics.

Looks like a modern version of twin https://github.com/cosmos72/twin

Ha, you beat me by a minute :D I agree!

I've been thinking about such text-based DE for custom Raspberry Pi nano based smartphone. Reason being, common mobile apps are not going to arrive for Linux and Nano is not powerful enough to run web browsers anyways; So why not a text-based DE or even just a console which enables basic communication features and Lynx for browsing?

It would be great if we could get some GPU juice from Pi for text rendering in such environment like how iTerm2 does on macOS.

Are you talking about a Pi Zero? That can totally run a desktop environment and browser. Especially something light like XFCE or Enlightenment.

>Pi Zero?

Correct, sorry brain fart.

>That can totally run a desktop environment and browser. Especially something light like XFCE or Enlightenment

Even regular sized Pi struggle with web browsing on a standard browser (Firefox/Chromium), I know that it largely has to do with the web pages themselves being memory hogs, but then again a similar specced Chromebook x86 doesn't hang while browsing(Same web page/Same no of Tabs); I think it largely has to do with browsers not getting optimised for ARM architecture on Linux.

I had the same issue with XFCE i.e. browsers hang after sometime, as for Enlightenment 3rd party apps didn't work last time I tried with Pi3[1] has the situation changed now?


Tip: If you want to escape from any ssh session you can press this sequence:

1. <Enter> Press Enter.

2. ~ Press Tilde.

3. . Press dot.

This disconnects from the remote host.

If you want more: `man ssh` and look for "ESCAPE CHARACTERS"

I think the sequence is "<Enter>~.". I use it often.

why not use the logout shortcurt ^d ? this abort sequence is so much move involved vs just ^c ^d -ing

This shortcut works even if the remote side isn't responding to ^c and/or ^d. It's handled by the local client. The two primary use cases I've found it useful are when I accidentally wedge the remote box by using up all of some resource or when some other event causes my network connection to hang and I don't want to wait for a timeout.

yeah, i was specifically confused about him having to use it often. it is sometimes useful, like when you're connected to the demo site and cba to figure out how to disconnect.

but such situation are so rare that i was confused about the remark how often he uses it.

I use it pretty often because I have SSH sessions that get messed up from (dis)connecting my VPN and I'm impatient.

If you do the first connection with mosh instead of ssh, it will survive vpn/wifi/4g roaming and even system hibernation. Assuming that first hop is a vps in the cloud with a stable connection, you can literally wake your pc from hibernation and once you get any Internet access, mosh will happily restore your "ssh" session for you.

mosh.org: >Mosh will log the user in via SSH, then start a connection on a UDP port between 60000 and 61000.

Needs at least a couple of ports in that range open, because old sessions tend to block ports until they are cleaned.

I use mosh for personal stuff. My work does not allow mosh.

C^D instructs the server to disconnect you. With these tilde commands you are issuing client side instructions.

Thanks. Corrected.

You can do ? instead of . and it will tell you what else it can do. Client side escape sequences. Handy to know!

It looks like DESQView for MS-DOS.

I really liked DESQView, too bad the industry had to move to GUIs :(

I just ssh-ed in, there are multiple users, its crazy!

same, but I will come back later to actually try it. Right now it's displaying a bunch of colors and strobing really hard. Not sure what's happening.

Try a different terminal. It does that for me in URxvt, but works fine in xterm.

Along with DESQView and IBM’s TopView as already mentioned, this reminded me of the first version of PC Smalltalk put out by Digitalk that was called “Smalltalk Methods”. It was a character based windowed Smalltalk.

This was quickly followed with the full bit mapped windowed Smalltalk/V. I believe all of this was when MS Windows still only had tiled windows without overlap.

I came here expecting an article about my beloved Emacs ;)

Might as well dive all the way in: https://github.com/ch11ng/exwm

Stumpwm would probably be attractive as well, because Lisp. http://stumpwm.github.io/

same here. didn't know there are other DEs besides Emacs

this is the maximalism that i come to hackernews to find.

serious question about exwm, how do you deal with a broken .emacs, and what about when you hang emacs?

I would suggest keeping around some versions :) I use git for this very reason locally when I'm futzing with settings, it's immeasurably handy for experimenters and config file junkies.

Same as any other WM (although I don't actually use exwm). Enable ssh for troubleshooting or use boot flags to boot to console.

Glad to see someone made this to save me the time! I've wondered if a TUI could replace some desktops for low end or embedded systems, or something to use on remoting into a datacenter etc.

Drawing text is the most expensive in a GUI.

That's only true for TrueType Fonts in graphical mode.

In text-mode, characters are "drawn" by simply writing their ASCII code point into VRAM and writing another byte (two 4-bit values really) in an additional "attribute" buffer to set the foreground and background colour.

Programmers can swap out the default character set to provide their own typeface and graphical characters for use as window borders, shadows, etc.

(S)VGA text-mode is as cheap as it gets in terms of computational complexity.

This sort of thing hasn't been done with the display adapter in a text mode for a decade or so, now, even on PC-compatible hardware. Even terminal emulators of this sort on Linux and the BSDs use the display adapter in graphics mode, drawing glyphs from loadable (bitmap) fonts. The sorts of systems that mysterydip was talking about might not even have hardware that provides an old-style MDA/CGA/EGA/VGA text mode, moreover.

This in addition to the fact that, as others have pointed out, the old-style text mode really doesn't lend itself well to Unicode, to the new (sic!) terminal colour systems of the 1990s, nor to proper boldface+underline+italics. (The latter is one of the reasons that commercial DOS programs from 1-2-3 to Quattro Pro were switching display adapters into graphics mode and rendering their TUIs by drawing graphics, with BGI in the case of Borland, back in the late 1980s and turn of the 1990s.)

With post-VGA blitting capabilities one can of course do things like pre-load glyph bitmaps into off-screen video RAM and blit them into the display, potentially a lot faster than having the main processor write the glyphs directly; but it is still not as simple as writing 16-bit character+attribute pairs, to do what modern users generally regard as the basics of TUIs in these modern Unicode, 24-bit colour, full ECMA-48 attribute support times.

Come on. We had long past the ASCII only era.

For people downvoting this guy, he's saying we're long past the ASCII era, and he is NOT saying we're long past the TEXT era.

It's the America-centric ASCII stuff that we're past, not plain text itself.

UTF-8 forever!

ASCII is eternal

Tell that to the French, Germans, Russians, Chinese, Japanese, Koreans, Spanish, Norwegians, etc. pp.

True in the general case - but a fixed size font drawn in a grid over the screen? There's a lot you can to do make it very cheap

Depends. If you render it yourself in a frame buffer with anti aliasing and whatnot sure, but real text mode or using bitmap fonts is dirt cheap.

I suggest running this on a server vs xfce/lxde/some other low overhead windows environment and get back with us on the overall load on the machine vs graphics. Holistically this is going to be a much smaller footprint.

Emulating stacked translucency in a terminal is pretty interesting.

notcurses takes this to its logical extreme: https://nick-black.com/dankwiki/index.php/Notcurses#Transpar...

check it out in notcurses-demo -- pretty crazy stuff

This reminds me of the DOS menuing system we used to install on clients' computers several decades ago. Cannot remember the name, may have to dig out my old 5 1/4" floppy collection binder I used to always carry with me if not remembering starts to drive me crazy...

That system remapped the function keys to launch batch files or call up sub-menus... Easiest way (at the time) to "customize" peoples' computers for them...

VDOS/Norton Commander[1] jumps to mind when I read your description, except that was more popular when everybody was migrating to 3.5" floppies.

[1] https://en.wikipedia.org/wiki/Norton_Commander

Could you be thinking of DesqView? That was a whole multitasking OS that sat on top of DOS.

Although I played with DesqView, that was not the menuing system I used to use - It had some monumental name for the day, like SuperMenu or MenuGold 2000 or some such... Internet search not getting any hits that match. Oh well.

It was very common on some of the old vt220(etc) terminals to have menus and windows and such. However I never saw anything like this :) . Can't imagine those 9600 baud terminals having fun with all of this haha

Ah, SideKick... TSR hell days...

No, went and looked through my little 5 1/4 binder, not sure I still have the menu utility...

But for those of you who were doing this back in 1991, here is a list of the utils I carried on 5 1/4":

Gibson's SpinRite

MS-DOS 6.22

pcAnywhere 5.0

PKUnzip 2.04G

Everex - The Edge Utility (BIOS settings app)

Easy Data 286 Setup for 10-12MHz

Laser Digital Phoenix Setup

Wyse Tech - Setup & Test


Utron Inc - Neat 286 Setup Disk

Misc. Novell files

QEMM 386 5.10

Brief 2.0

SuperStor V2.04


Mountain Tape (tape backup)

Norton Utils 5.0

ProComm Plus

Intel Satisfaction

MicroHouse IDE


DOS 5.0

DOS 3.3

Checkit 3.0

Scan80, Clean80, CPAV

Norton Antivirus

LapLink III

And somewhere in my office I still have the multiple boxes of 3 1/2" disks, both the 10 disks boxes, and bigger 100 Disk box, that saw a lot of wear and tear in my backpack - I skateboarded to clients around Santa Cruz, so everything had to fit into my backpack at the time.

This is amazing. Has there been anything like this before?

Oh yeah. I'm going to date myself here, but I was just going to say this reminds me a lot of Borland Turbo C++ way back in the day. They had this thing called Turbo Vision for building text UIs. It seemed super cool back then.


It definitely was super cool. The windows had types, could be resized, had titles, dropdown menus, and form controls. The editor had syntax highlighting. And most importantly (at least for me at the time), there was a language reference included with the help system which had hyperlinking, so you could click through pages about the supported syntax and various topics, gleaning a wealth of information. All on DOS!

Hypertext integrated help has been available earlier than turbo vision even. It has been available from turbo pascal 3 at least. For a young like me who ... copied it on two disks, it was awesome what you could learn.

Turbo Pascal 3 didn't have integrated help (hypertext or not), it was introduced in Turbo Pascal 4 (which itself was AFAIK in general a big rewrite of the compiler and IDE).

Though the integrated help really improved with version 6 (when Turbo Vision was also introduced) since you could move a cursor freely inside the help window as if it was an editor, select and copy text, the help text was much more detailed and more organized and every function/procedure also had a small example showing its use (version 5.5 also had examples but the overall help was much more terse).

Ah, maybe version 4. 5.5 was my favourite with objects. Later ones with turbo vision swapped on my 640k 8086.

It was super cool!!! I had so much fun emulating it drawing single and double line text borders, with shadows. Oh ASCII chart how I miss thee.

Norton Commander / FAR commander.

The latter is still in use and actively developed: https://www.farmanager.com/screenshots.php?l=en

Windows 1.0, while having a framebuffer-based layout engine, clearly evolved from a pure TUI, and retains elements (title bars, scroll bars, etc.) whose drawing algorithm emulates a TUI within the framebuffer, by just drawing DOS-like lines or grids of box-drawing characters.

In fact, it’s only window content that is arbitrarily graphical in Windows 1.0; if you only have DOS VMM windows open, you’re essentially seeing a TUI, just with extra steps.

Windows 1.0 didn't actually use box-drawing characters for any of this, of course. For example, the System menu in the top left corner of each window was three horizontal lines, just like a hamburger menu of today. Scrollbar buttons did not look like any box-drawing character.

The Maximize button in the top right did look like a box-drawing character, but that's really about the only resemblance I see.

(I developed a DOS GUI for email, Transend PC, in the early '80s that used box-drawing characters, and soon after started writing SQLWindows for Windows 1.0, so pretty familiar with both.)

Right, I'm not saying that the GUI was rendered using the DOS box-drawing characters, i.e. the monitor's built-in codepage 437 text mode; nor were they using a monospace bitmap font of codepage 437.

What I'm saying, is that I'm pretty sure that a lot of the Windows 1.0 GUI was drawn by emulating the "technique" TUIs use to draw box-drawing characters, but on a framebuffer and with a custom (monospace) bitmap font:

1. create any-and-all graphical detail you need on screen, by repurposing the "leftover" parts of the bitmap font you're using to draw control-label text to the screen, adding a set of additional, custom symbol-drawing elements, which are all 'characters' of that bitmap font, and so all stuck being the same size+shape as the label text;

2. create a graphical "monospace text" drawing primitive, that takes as input a pair of buffers representing the text itself, and its hardware-text-mode-alike per-character drawing attributes (i.e. FG + BG color);

3. implement your OS widget library almost entirely in terms of calls into that graphical "monospace text" drawing primitive, passing a static data-section buffer holding the positional+attribute data for your box-drawing character.

(For example, look at the drive icons in the File Manager. Those are just clearly just "text" composed of four drawing-element characters from the bitmap font, like this: [-=-]. So the whole drive-chooser area can be drawn with a single text-draw command, passing a string like "A[-=-] C[-=-] C: \WINDOWS".)


You might say "but look at any screenshot of Windows 1.0 — the first thing you'll notice is that the menu-item labels in each window's menu bar are offset by a half-character-width horizontally! And modal dialogs are, in their entirety, offset by a half-character horizontally and vertically! How's that possible?"

Well, the GUI "monospace text"-drawing primitive might be drawing a grid of characters to the framebuffer; but it's not drawing them to an imaginary grid on the framebuffer. It accepts an arbitrary pixel offset for where it should start to draw the block of monospace text.

So, with that in mind, the algorithm for drawing the menu bar very likely has two passes:

1. render some box-drawing characters representing the "background" of the menu (i.e. yellow with a black border)

2. render a layer of regular non-box-drawing characters on top, offset by +4px on the X axis, in "black on transparent", representing the menu-item labels.

It's pretty clear (to me, at least) how a drawing algorithm like this could be a natural evolution and outgrowth of a TUI: first, replace the TUI's backing text buffer with a framebuffer, and the character-plotting calls with draw calls to a "draw monospace text character at emulated-grid position on framebuffer" primitive; then refactoring the draw calls to use a window-local coordinate basis; and only then adding the ability to draw anything other than monospace characters—but gradually, starting only with defined grid-snapped "rich graphical content" regions within windows (sort of like how Windows today has "Direct3D drawing surface" regions); and then going back and gradually enhancing the GUI widgets with little flourishes like draw offsets.

Within the Windows 1.0 codebase, I would bet money that—at least in some previous revision in early development—there was probably a #define flag for whether the "framebuffer driver" was enabled; and that all these windowing-system and common-controls drawing algorithms were written in a "hybrid" way where, instead of one TUI-based and an entirely-distinct framebuffer-based implementation, the framebuffer-based implementation is just #ifdef'ed ornamentation on top of the base TUI implementation.

That's an interesting and creative theory. I have to admire your putting so much detailed thought into it! I mean this sincerely.

Perhaps parts of the Windows 1.0 GUI could have been implemented like that, but the truth is much simpler and more mundane.

The bundled apps (including MS-DOS Executive) and the window decorations generally used the same GDI (Graphics Device Interface) calls as third party apps:

Text was drawn with TextOut() or DrawText().

Bitmaps were copied to the framebuffer with BitBlt() or StretchBlt().

Lines were drawn with MoveTo() and LineTo().

Rectangles were drawn with Rectangle() or RoundRect().

This is not an exhaustive list but should give you the general idea.

All of these functions operated on a "device context" (DC) that you obtained with functions like GetDC() or CreateCompatibleDC(). Some, like BitBlt(), used two DCs for the source and destination.

The MS-DOS Executive drive icons were bitmaps drawn with BitBlt() with TextOut() for the drive letter. The selected drive letter and icon were inverted with InvertRect(), or possibly drawn with the DSTINVERT raster operation code.

These are the same functions that any Windows application could use. The MS-DOS Executive was just another app.

The non-client area of a window (titlebar and such) was drawn with the same GDI calls as the client area. Your app would get a WM_PAINT message to draw the client area and a WM_NCPAINT for the non-client area. Most apps passed WM_NCPAINT through to the default handler DefWindowProc().

I was programming Windows apps starting with the first release of Windows 1.0. I spent a fair amount of time reverse engineering other Windows apps and Windows itself, along with people like Matt Pietrek and Andrew Schulman.

Andrew in particular would have devoted an entire chapter of his book Undocumented Windows to the text-based system you describe. It would be a field day for him!

Also consider memory limitations and programmer time. Remember that Windows 1.0 ran (slowly) on a machine with 256KB memory and two floppy drives.

Since they had to build GDI anyway, it would take more memory to also include this text-based system. It also would have taken more developer time, and provided less testing of the public APIs.

But again I do appreciate your interesting speculation!

There are many tiling window managers for UNIXes and similar such things. There's also Plan9 which is in a sense text based.

Yep, around 1990



I had just started working at Gupta Technologies at the time, and for a short while we seriously considered developing for TopView instead of Windows.

Ashton-Tate did it with Framework in 1984.

Though my memory is that it goes back a few years earlier to Valdocs on CP/M machines, but I can’t find any pictures on the intarwebs.

Framework was pretty great! My partner and I were working on some similar ideas at the time, and we got together with the Framework team to compare notes and brainstorm.

The thing that stuck in my mind when Robert Carr took us on a tour of their office was the printer lab.

It was a full size conference room with floor-to-ceiling shelves on every wall stacked with printers.

Because back in those days, if you wanted to sell a DOS application that could print anything more than plain text, you had to write your own drivers for every printer you wanted to support. Ouch!

I've sometimes thought that the real innovation in Windows 1.0 was having systemwide printer drivers so every app didn't have to provide their own.

I love things like this. Is it not released yet? A glance at the repo from my phone looks like there is no code yet.

Does anyone remember Tandy Deskmate?

Here is a nice quick tour of Deskmate: https://www.youtube.com/watch?v=mYHtojsaRkY&t=9m47s

Reminds me of the first edition of MS Windows.

A lot of firmware systems still do their "windowing" like this.

This looks quite cool, but I don't think it's open source? I can't find any source code in the repository, there's just a single file called not_ready_yet.

It is probably not ready yet.

The source might not be there, yet, but the MIT License is in the repo.

I was at least hoping to see information about the language(s) used.

I once built something like this. There’s a Perl library[1] that lets you control windows, dialogues, etc. My grasp on concepts like asynchronous programming, callbacks, process IO, etc. was nascent at best, so naturally this UI that I built was pretty terrible. I learned a ton though!

[1]: https://metacpan.org/pod/Curses::UI

Not just Perl. Curses is what most TUIs on *nix are built in. It's a C library with a few different implementations.

I love the lines connecting all the windows to a single point. Helps with the spatial relationships.

The source code is just a file named "not ready yet". How is this open source?

Pretty sure that MIT doesn't mean that they have to put the code in a repo. Have you tried emailing them?

Edit: Presumably they plan to put the code in a repo, but it's not ready yet.

Tried to connect with Juice SSH on mobile and it looked quite ... abstract.

Also with Terminal.app from macOS...very..er..."colorful".


Looks fun like that on iOS Prompt, too.

Must be looking for ANSI instead of VT100.

Mismatched emulator modes reminds me of BBS days.

Same with PuTTY on Windows. Its certainly colorful.

It’s funny when Microsoft comes to the Linux world it feels the urge to make it windowy, rather than learning the Linux text CLI paradigm.

Just note that VTM is the main commercial TV station in Belgium, and the name is most likely trademarked there as well.

I like that, a lot. For the low bandwidth only.

> "total sent: 56 878 123 bytes"


aka one gif video on imgur

Ah, this reminds me of Turbo Pascal days :)

The demo doesn't seemt to work on putty

Worked fine for me in PuTTY.

What settings? Mines more like an abstract color art piece but not so much a desktop environment.

Same on urxvt. Probably requires true color support. I had the same issue with browsh, a text front-end to Firefox.

Oh, if only there were a way to solve this problem which was well-tested and widely-deployed!


That gained 24-bit RGB colour support in version 6.1, released in 2018. It's not quite as widely deployed as you may have thought.

* https://stackoverflow.com/a/36163656/340790

IDK, Default? I'm on PuTTY 0.73. I haven't changed anything since I installed it.

0.74 is out

Same here

Floating windows are worse than tiling imho

Until you want to work with media/creative apps.

What's the point of overlapping windows in text? Seems that tmux already fits the bill for this use case.

Its good to see experiments like this. Maybe this project won't be the next big thing, but maybe it will give someone an idea of what the next big thing should be.


Well done brother ;)

Isn't it similar to the rio windowing system from Plan 9?.

rio is a graphical interface so not really. It is more like acme itself but with floating windows and translucency.

Is this running on top of Windows and just replaces the GUI?

Nope, I guess this is a Linux or at least platform-independent command line interface program.

You are probably confused by the powershell which seems to be available for multiple platforms nowadays, see https://aka.ms/pscore6

There's also a window claiming to be Windows' CMD. As I can't figure out how to enter text in any of these windows (I'm assuming it's disabled, otherwise CHAOS) I can't tell if it's just a vestigial window of if it's a true output.

The topics on the Github repo list both Linux and Windows. The Readme calls itself "aka Monotty Desktop". That makes me think they may have written the code for the Mono runtime, so I'm expecting it's C#.

I had played around with a similar idea in C# some months back, though I was targeting only Windows because it took P-Invoking into some Win32 APIs to get most of the functionality.

Powershell. But Microsoft ported Powershell to run on UNIX/Linux, so ...

I know the difference between PowerShell and CMD. And I know Microsoft ported PowerShell to Linux. You're not paying attention. Command Prompt is also on display: https://dice.netxs.online/cloud/vtm/mde_banner.png

Yep, I'm in the same boat as you. Part of it just looked like Linux running Powershell, but CMD threw me off.

When PowerShell runs on Linux, it doesn't show a "C:/" prompt. This is clearly running on Windows with WSL or Cygwin for the Unix tools.

My first thought as well, but I didn't think you could not use the GUI in WIN10

There would be no need to kill the default desktop manager to run anything we've seen here.

I am curious, how does it render images/videos?

Yes it does have some support, though the resolution is low.

It's very cool!


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact