The Youtube video embedded on their Github is titled "Tiling Window Manager with Drag&Drop" and from watching it, that appears to be exactly what this is. I don't know if or why it artificially constrains itself to only opening terminals.
It's scary to do something more complex than a terminal emulator until the architecture is unstable. In case of small changes we will have to rewrite a lot. You can play with a couple of built-in demo apps 'vtm --run text', 'vtm --run calc', 'vtm --run test', 'vtm --run truecolor'. You can also run it directly inside the vtm desktop by typing vtm.desktop.Run({ type='calc' }) in the command line of 'Log Monitor'.
Ah I see what you mean. I mean it’s all pixels in the end right? and pixels are primitives for guis. So then the root primitive is in actuality the gui.
I tried to use desqview but it was too slow on my 386 33mhz machine… not sure how much RAM it had back then but I recall it was the bottleneck and swapping to disk caused everything to lag.
DESQview did not do any memory management of its own, and it did not use graphics. It was entirely local and had no networking. It was famously fast. It was a DOS multitasker so it managed DOS tasks, meaning multiple slots of 640kB. On a 386 with 4MB of RAM you could have 6 full-size DOS VMs with a bit left over.
If you were a power user you could still have say a big 1-2-3 spreadsheet in EMS plus a few DOS VMs.
DESQview delegated memory management to QEMM386, and QEMM386 did not do swapping. It didn't need to.
DESQview/X was a totally different product, with a full GUI, so much bigger and slower -- and it added an optional extension that added full virtual memory with swapping to disk.
I am wondering if you are mixing up DESQview (small, fast, local) with DV/x (big, complicated, networked, had optional VM)?
Or indeed DV/x with something else altogether? OS/2 maybe?
Because if it was swapping, it wasn't DESQview, not in any normal sane config anyway. It might be possible to add DV/x VM to plain old DESQview but I never heard of anyone doing that.
I also remember the first version of Smalltalk from Digitalk that was character based and windowed. It was called Methods. I can’t seem to find any reference to it on the web now.
"Methods, our character-based Smalltalk, is now available for $79- It has all of the features of Smalltalk/V except graphics, rules, source-level debugger, and object-swapping. However, it supports color, includes the communication package, and does not require a mouse."
It was a great framework, it was my path into OOP, after learning it previously in TP 5.5 (TV was released alongside TP 6, and Borland C++ 3.0), and its design was quite pragmatic.
Sure, it was awesome, it was also my first exposure to OOP but I think for a beginner it was slightly too deep and I ended up doing things without knowing what I was doing... although they worked.
Yeah. Am I missing the point that this leans so far into being as capable as a GUI as it can, that we lose something from starting in the terminal in the first place?
I was exploring why Linux terminal environment is so powerful compared to Windows terminal. Windows is built at the kernel level to support graphics and GUI, while *nix systems are built with terminal at the core. Thus Windows historically has had way more powerful GUIs. They are two different domains of power. Each of them also trying to do what the other does better.
Interesting perspective. I've poked at the medley interlisp revival project, as well as glamorous toolkit, and cuis, but hadn't heard about most of the things you mention here. Will be investigating.
I always wondered if it was possible to have a TUI-style window manager inside the terminal. This is a fantastic project, whoever made it did a great job.
However, from my perspective, the extensive need to drag windows around and resize them is a habit of windows environment. So, perhaps, this is for the mouse what tmux and Neovim are for the keyboard.
In tmux, the window layouts I need are fixed sets of 2x2 panes, with some predefined ways of resizing them and toggling full-screen. With effective tools like telescope and nvim, the need to line all windows up disapears, because the switching is so efficient and I have more of a mental picture than a visual one of what's available. For example, no need for the file tree commonly to the left in most IDEs.
I thought like you in the past. Today, for some reason, I value defaults and reducing my cognitive load so that I can think more and do less. Even Eclipse would work for me nowadays :P
I remember Eclipse! That was something like 20 years ago I used it last time. Thanks for bringing back some memories.
Setting up an efficient terminal environment is overwhelming. I do it as a hobby and enjoy the tinkering. Thanks to GPT the process is quicker. But I spent a lot of time just setting up a basic environment.
There was something similar a few years ago which ran over an ssh connection and had a zoomable ui of sorts. I can't find the link -- does this ring a bell anywhere?
I don't completely understand what is meant by "zooming", but kitty[^1] does that: you open ssh connection with `kitten ssh user@host` and pressing <C-Enter> will open another ssh pane in the same tab, you can than IIRC <C-F> to "zoom" and make tab take full window
It really is tragedy that there aren't more ZUIs in the wild. I'd love a compositor (X11 or Wayland; it's probably not just a wm) that made all windows arbitrarily zoomable, but I lack the skill to make it myself.
When I said "zooming" I was thinking of the white tethers attached to each window which would pull them back into a centre bundle. You can see what I mean here: https://changelog.com/news/a-textbased-desktop-environment-i... at the bottom left, the lines going off to a single point.
actually, by zooming out, I can still see the tethers on the windows. The ssh version was quite mind-blowing back when...
This is the same thing as the public demo back then via 'ssh vtm@netxs.online'. There are no public demo servers running now, but you can still ssh to your running vtm instance with any number of connections. In case of using MS Windows you can even get the output in a standalone GUI window via 'vtm ssh user@unixserver vtm'.
There were demo apps in the menu, they are still there: 'vtm --run text', 'vtm --run calc', 'vtm --run test', 'vtm --run truecolor'... You can play with it by running them directly inside the vtm desktop, by typing (or right click to paste) commands like vtm.desktop.Run({ type='calc' }) in the 'Log Monitor' command line.
Now vtm is the same as it was running on demo servers. In the modern version, the fading effects and window shadows are disabled by default in the settings. Perhaps the fading effects were removed as unnecessary.
Potentially relevant for using this vs GUI for remote access: AV1 can compress 4k+ screen casts in real time to under 500kbps while keeping text legible.
People who were looking for a TTRPG in the modern setting and ended up being deeply confused and converting their entire computer environment into a powerful runic device that requires complex incantations - though maybe those folks would have been better off looking for Mage the Ascension.
Building with gcc requires ~4Gb of RAM; clang requires ~8Gb. Due to memory requirements, building vtm for a 32-bit target is only possible using cross-compilation. In addition, cmake downloads Lua sources during the build process.
Been using Zellij for awhile and it is delightful! I am only a moderate terminal user, but I really like having some basic multiplexing features if I need them. My brain just could not hold onto the necessary tmux key combos with only intermittent use. Instead I find the Zellij commands to be more intuitive (and more discoverable thanks to the handy prompts...)
A big thread five years ago https://news.ycombinator.com/item?id=24243521
The main link in the thread appears to have been taken over by a malicious entity.
dang replaced it with an archive link and pinned a comment at the top telling the story. What a G.
I've never seen a forum moderator of a place as full of anxious nerds as Hacker News steward a ship this well. May we all aspire to Dang's heights.
I know I’m missing the obvious here, but is this a terminal multiplexer (like tmux)? Or a tiling terminal emulator (like iTerm, et al)?
Neither, it's its own thing. Most similar to tmux, but you interact with it more like you'd interact with a graphical window manager.
So tmux with floating panes and drag-n-drop.
The Youtube video embedded on their Github is titled "Tiling Window Manager with Drag&Drop" and from watching it, that appears to be exactly what this is. I don't know if or why it artificially constrains itself to only opening terminals.
It's scary to do something more complex than a terminal emulator until the architecture is unstable. In case of small changes we will have to rewrite a lot. You can play with a couple of built-in demo apps 'vtm --run text', 'vtm --run calc', 'vtm --run test', 'vtm --run truecolor'. You can also run it directly inside the vtm desktop by typing vtm.desktop.Run({ type='calc' }) in the command line of 'Log Monitor'.
The whole thing runs inside of a terminal, it would be hard to open anything else
Reminds me a lot of the Apollo workstation.
That makes two of us.
With tiling, I think.
We've come full circle. We invented a GUI to replace the TUI, then reimplemented the GUI in the TUI. Long live the terminal!
We've done it twice. Many terminals run under electron or equivalent browser interfaces. So we've implemented TUI in the GUI as well!
That sounds like the worst thing ever. So many good native terminals to choose from why ruin it with electron.
That’s also applies to literally every terminal emulator written since xterm.
Most of the modern terms these days have GPU acceleration too.
No. This isn’t true. Most terminals are native. They don’t run under a browser engine.
A browser engine isn’t a prerequisite for something using a graphical framework nor running on a desktop environment
Ah I see what you mean. I mean it’s all pixels in the end right? and pixels are primitives for guis. So then the root primitive is in actuality the gui.
Revenge of DESQview
It’s funny - I think of DESQView/X, their fully compliant X11 server complete with both Motif and OpenLook. The exact opposite of vanilla DESQview.
I used DESQview for a number of years, and always think about it when see new TUI systems
https://en.m.wikipedia.org/wiki/DESQview
I tried to use desqview but it was too slow on my 386 33mhz machine… not sure how much RAM it had back then but I recall it was the bottleneck and swapping to disk caused everything to lag.
I think you are confusing old memories here.
DESQview did not do any memory management of its own, and it did not use graphics. It was entirely local and had no networking. It was famously fast. It was a DOS multitasker so it managed DOS tasks, meaning multiple slots of 640kB. On a 386 with 4MB of RAM you could have 6 full-size DOS VMs with a bit left over.
If you were a power user you could still have say a big 1-2-3 spreadsheet in EMS plus a few DOS VMs.
DESQview delegated memory management to QEMM386, and QEMM386 did not do swapping. It didn't need to.
DESQview/X was a totally different product, with a full GUI, so much bigger and slower -- and it added an optional extension that added full virtual memory with swapping to disk.
I am wondering if you are mixing up DESQview (small, fast, local) with DV/x (big, complicated, networked, had optional VM)?
Or indeed DV/x with something else altogether? OS/2 maybe?
Because if it was swapping, it wasn't DESQview, not in any normal sane config anyway. It might be possible to add DV/x VM to plain old DESQview but I never heard of anyone doing that.
I also remember the first version of Smalltalk from Digitalk that was character based and windowed. It was called Methods. I can’t seem to find any reference to it on the web now.
"Methods, our character-based Smalltalk, is now available for $79- It has all of the features of Smalltalk/V except graphics, rules, source-level debugger, and object-swapping. However, it supports color, includes the communication package, and does not require a mouse."
magazine page 97
https://archive.org/details/byte-magazine-1986-10/page/n108/...
It is downloadable on WinWorld.
Just like whenever I see someone praising Ratatui, what comes to my mind is Turbo Vision, Clipper and curses.
The demo video has a lot of Borland's Turbo Vision vibes.
It was a great framework, it was my path into OOP, after learning it previously in TP 5.5 (TV was released alongside TP 6, and Borland C++ 3.0), and its design was quite pragmatic.
Sure, it was awesome, it was also my first exposure to OOP but I think for a beginner it was slightly too deep and I ended up doing things without knowing what I was doing... although they worked.
run it through aalib for good measure
Totes.
Yeah. Am I missing the point that this leans so far into being as capable as a GUI as it can, that we lose something from starting in the terminal in the first place?
I was exploring why Linux terminal environment is so powerful compared to Windows terminal. Windows is built at the kernel level to support graphics and GUI, while *nix systems are built with terminal at the core. Thus Windows historically has had way more powerful GUIs. They are two different domains of power. Each of them also trying to do what the other does better.
Every desktop OS has been like that, UNIX is the exception, as it was originally designed for a timesharing headless system.
And with exception of command.com, most have had good CLI shells, without having to pretend being a teletype, like UNIX ones.
Amiga DOS with REXX was great, Oberon REPL, Smalltalk Transcript, Interlisp-D REPL, Xerox Star Mesa XDE,....
Interesting perspective. I've poked at the medley interlisp revival project, as well as glamorous toolkit, and cuis, but hadn't heard about most of the things you mention here. Will be investigating.
I use terminal specifically to not need a mouse. I use a great many TUI tools, but this one is never going to be one of them.
If it had i3/sway tiling behaviour/bindings, that would be great.
I always wondered if it was possible to have a TUI-style window manager inside the terminal. This is a fantastic project, whoever made it did a great job.
My TUI desktop environment, complete with a tiling window manager, is called Emacs %) I suppose Vim can offer a comparable experience.
To paraphrase the old vim joke, emacs will be great once they add a text editor. ;)
The demo looks great but I'm twice shy from having been bitten a few times.
It can't just be pretty.
Something like dvtm?
https://www.brain-dump.org/projects/dvtm/
A little bit actually, yeah. This looks great, thanks.
Looks very smooth!
However, from my perspective, the extensive need to drag windows around and resize them is a habit of windows environment. So, perhaps, this is for the mouse what tmux and Neovim are for the keyboard.
In tmux, the window layouts I need are fixed sets of 2x2 panes, with some predefined ways of resizing them and toggling full-screen. With effective tools like telescope and nvim, the need to line all windows up disapears, because the switching is so efficient and I have more of a mental picture than a visual one of what's available. For example, no need for the file tree commonly to the left in most IDEs.
I thought like you in the past. Today, for some reason, I value defaults and reducing my cognitive load so that I can think more and do less. Even Eclipse would work for me nowadays :P
I remember Eclipse! That was something like 20 years ago I used it last time. Thanks for bringing back some memories.
Setting up an efficient terminal environment is overwhelming. I do it as a hobby and enjoy the tinkering. Thanks to GPT the process is quicker. But I spent a lot of time just setting up a basic environment.
There was something similar a few years ago which ran over an ssh connection and had a zoomable ui of sorts. I can't find the link -- does this ring a bell anywhere?
I don't completely understand what is meant by "zooming", but kitty[^1] does that: you open ssh connection with `kitten ssh user@host` and pressing <C-Enter> will open another ssh pane in the same tab, you can than IIRC <C-F> to "zoom" and make tab take full window
[1]: <https://sw.kovidgoyal.net/kitty/>
not the same zooming. imagine a text mode ZUI -- https://en.wikipedia.org/wiki/Zooming_user_interface
It really is tragedy that there aren't more ZUIs in the wild. I'd love a compositor (X11 or Wayland; it's probably not just a wm) that made all windows arbitrarily zoomable, but I lack the skill to make it myself.
Zooming all windows at once exists as a Gnome shell extension.
https://extensions.gnome.org/extension/7263/better-desktop-z...
Probably it would be possible to zoom one window at once as a shell extension.
It was this very tool. It could be sshed into with
ssh vtm@netxs.online
That domain is dead now
Hooray, thank you!
When I said "zooming" I was thinking of the white tethers attached to each window which would pull them back into a centre bundle. You can see what I mean here: https://changelog.com/news/a-textbased-desktop-environment-i... at the bottom left, the lines going off to a single point.
actually, by zooming out, I can still see the tethers on the windows. The ssh version was quite mind-blowing back when...
This is the same thing as the public demo back then via 'ssh vtm@netxs.online'. There are no public demo servers running now, but you can still ssh to your running vtm instance with any number of connections. In case of using MS Windows you can even get the output in a standalone GUI window via 'vtm ssh user@unixserver vtm'.
am I imagining it, or were there more features in the original public demo?
There were demo apps in the menu, they are still there: 'vtm --run text', 'vtm --run calc', 'vtm --run test', 'vtm --run truecolor'... You can play with it by running them directly inside the vtm desktop, by typing (or right click to paste) commands like vtm.desktop.Run({ type='calc' }) in the 'Log Monitor' command line.
Now vtm is the same as it was running on demo servers. In the modern version, the fading effects and window shadows are disabled by default in the settings. Perhaps the fading effects were removed as unnecessary.
I wish some web apps would adopt this pure text design language
http://www.coboloncogs.org/INDEX.HTM
The text heavy emphasis in the UI is one of the things that I used to love in the Windows Phone
Trying to understand it... if by comparison I'm using tmux then switching to something like this adds mouse based window (panel) management?
Potentially relevant for using this vs GUI for remote access: AV1 can compress 4k+ screen casts in real time to under 500kbps while keeping text legible.
I'd love to see some of these ideas folded into Zellij.
honest question, since i really like the idea but don't understand the implementation:
what use is a text-based desktop environment, if it requires a graphical interface and cannot run in a tty?
Not all platorm-specific tty's are supported by vtm. See the list of supported terminals.
This looks unbelievably bad ass.
I cant wait to try it.
Who is the target user for this?
Assuming this works over SSH, then presumably people who are literate with a terminal but prefer GUIs.
It does (work over ssh). Pretty neat: reconnect to the host and you see all the terminals you left open.
Damn, that would be quite cool.
People who were looking for a TTRPG in the modern setting and ended up being deeply confused and converting their entire computer environment into a powerful runic device that requires complex incantations - though maybe those folks would have been better off looking for Mage the Ascension.
> and converting their entire computer environment into a powerful runic device that requires complex incantation
I already have a Linux machine, but yes this looks like a nice addition;)
Crazy text fanatics, lynx browser users, console minimalists, desktop ricers, AI fearing cult members: the usual suspects.
People who think it is cool, I guess.
When I first read this, I thought this was an open source project by DirectTV
has anyone tried building it from source?
Building with gcc requires ~4Gb of RAM; clang requires ~8Gb. Due to memory requirements, building vtm for a 32-bit target is only possible using cross-compilation. In addition, cmake downloads Lua sources during the build process.
machine is big enough, i'm getting syntax errors in tile.hpp
Most likely you need to update the compiler you are using.
I just built it on macos 15.3.1 without issues, if that helps.
Now that we have high resolution, millions of colors, and unicode in our terminals, this is the logical conclusion.
Still doesn't make a lot of sense, but I like it. :-D
[dead]
[dead]
[flagged]
https://github.com/zellij-org/zellij
Been using Zellij for awhile and it is delightful! I am only a moderate terminal user, but I really like having some basic multiplexing features if I need them. My brain just could not hold onto the necessary tmux key combos with only intermittent use. Instead I find the Zellij commands to be more intuitive (and more discoverable thanks to the handy prompts...)
Open man page for tmux. Search for split window. Launch tmux and split window. Open man page for tmux in 2nd window.
Its not hard.
[flagged]
Thanks, ChatGPT
I feel like an LLM agent could grok and interact with something like this pretty well...