After languishing for nearly half a decade, I recently dusted off the code for VWM. Although the original release worked well, it never quite satisfied my technical idealism. There were lots of things I wanted to implement, fix, or clean-up, but none of them were trivial. But let me digress for a bit…
What is VWM? Viper Window Manger (VWM) is a lightweight window manager for the console. You heard right! VWM is a window manager for the console. It’s built on top of libviper which is a convenience layer on top of ncurses and a GTK-like framework for rapidly creating console programs.
Now back to the main point… When I slowed the development of VWM back in 2011, there were lots of improvements I foresaw:
- Building the stack was difficult because it all relied on handwritten Makefiles. It needed a better build system.
- Glib was scattered throughout the code because of some of its convenience features. It needed to be removed, but doing so would mean writing equivalents using libc and POSIX standards.
- The libviper framework was not only dependent on Glib, but it also relied on the FORM and MENU libraries which are unique to ncurses. It would never be possible to port VWM to other curses implementations (such as pdcurses).
- Much of the code in libviper ended up being redundant. The code-base was heavily bent toward an object-oriented language, but it was written in C. Rewriting the code in OOP C provide long-term benefits but lots of effort.
- Both libviper and VWM never used multi-threading, but primitives were in place just in-case. It simply didn’t make sense. On top of that, VWM was using a crude task queue system. It worked, but it lacked the granularity and elegance that protothreads or co-routines offered. A protothread implementation made sense, but once again, it was a big undertaking.
- The integrated terminal was using libvterm (formerly libRote) but compatibility was poor. Most of what you want to do in a console window manager requires a good terminal emulator. The emulator need a lot more work if it was going to be even modestly useful.
So how long would it take to make all of these changes? It turns out the answer is about 4 months. After taking a renewed interest in improving libvterm, little by little I chipped away at all of these components and am happy to announce some shiny new code! Here’s the highlights from the release:
- All code uses the CMake build system. This includes libvterm, libviper, libprotothread, and vwm.
- All vestiges of Glib have been removed. The linked-lists have been replaced by the implementation used in the Linux kernel. Glib timers have been replaced with POSIX timers driven by the kernel. The list goes on here…
- There is no more dependency on the FORM or MENU libraries. Equivalent functionality is provided by native code. There are still obstacles for porting to pdcurses but the barrier is much lower.
- The libviper framework has been written in OOP C with GTK-like interfaces.
- All of the threading primitives have been removed and multitasking is implemented with Larry Ruane’s protothread library.
- Although VWM does not support multiple desktops, much of the underpinnings have been implemented.
- VWM now uses libconfig to read configuration files.
- The libvterm emulator has received lots of enhancements and is compatible with 99% of the programs cataloged here on Console Craze.
- The VWM configuration file enables users to add programs to the menu in several different modes including fullscreen.
There’s definitely more to do and I’d be happy to have the help. If you want to get invovled, let me know and I’ll be glad to add you to the official repositories.