>> Home / packaging / opensuse, linux, editor, retrocomputing
∵ Julius Enriquez ∴ 2024-07-16 ∞ 8'
When I had settled on openSUSE Tumbleweed on the new laptop, I was looking for something to learn about RPM and openSUSE packaging. Ideally something that seemed simple yet interesting to have in the openSUSE repos. Well, emphasis on seemed there.
turbo
?turbo
is an experimental text editor based on Scintilla and a modernised port of the Turbo Vision 2.0 framework for building TUI (text-based user interface) apps; it is based on Borland's public domain release of the orginal framework but relicensed to MIT, added Unicode support, and made to be easy for developers to write cross-platform TUI applications with consistent rendering. The text editor itself is multiwindow and works similarly to GUI text editors, making it rather intuitive even for beginners.
As mentioned in the blog post about packaging fooyin, packaging turbo
was the first project selected for being packaged into openSUSE. The lessons from this and fooyin influenced the apckaging of each other and many of the links in that post will be relevant here too. However to prevent duplication, this blog post will focus on learnings and other pieces of knowledge that specifically came about from packaging turbo
and tvision
.
Before the text editor could be packaged, the tvision
framework itself needed to be done first. During the first attempts, there were a lot of build failures. A lot of these could've been avoided if I knew about rpm -E
for checking what macros like %cmake
and %cmake_install
contained. Next up, rpmlint
was failing with multiple errors but let's focus on this one:
[ 25s] tvision.x86_64: E: lto-no-text-in-archive (Badness: 10000) /usr/lib/libtvision.a
[ 25s] This archive does not contain a non-empty .text section. The archive was not
[ 25s] created with -ffat-lto-objects option.
Exporting the recommended flag in CFLAGS
or LDFLAGS
did not work, nor did adding -fPIC
. The working solution was to add %global _lto_cflags %nil
in the spec file, which disables LTO altogether. This is needed so that tvision.a
could be used as a system library, for later compiling turbo
. This leads into the next lesson learned:
There is a difference between static and vendored libraries.
Before packaging tvision
, I conflated the meanings of static and vendored libraries. I thought that static libraries were just libs that came with a program and that static libs were synonymous. Turns out that at least for Unix-like systems, static libraries were AR archives (.a
file extension) specifically. This confusion led into me acccidentally running into the openSUSE static library policies, upon initially submitting a request into openSUSE Factory. As per openSUSE policies, the solution for this was to rename the pacakge from tvision-devel
to tvision-devel-static
.
There is a tvision
issue for shared library support. It was pointed out by magiblot that there are some packages which do patch the framework lib to become shared, however I decided not to opt for this to remain as close as possible to upstream. There is a bit more discussion there on why Turbo Vision 2.0 won't get official shared/dynamic lib support yet and the reasons given do cause some concern for potentially breaking compatibility if I went with patching in the support.
After all that got sorted out, it was on to where the files in the packages were being stored. Initially, some of the files were being put into /lib
; this is a problem since they are architecture-dependent. On a 64-bit system, they should be in /lib64
instead. Fixing this meant patching the CMake build files to use the GNUInstallDirs module, which was later merged upstream. Making the first patch turned out to be more difficult than expected, since osc
required 0 fuzz (lines that precede and succeed changed lines) and git format-patch
doesn't have any options relating to fuzz. In the end, diffing directories of the upstream and patched source trees produced a patch that osc
would accept.
Finally, Turbo Vision was ready for acceptance into openSUSE Factory. Now for the main event.
With tvision
in openSUSE Tumbleweed, it was time to get the turbo
text editor packaged into Factory. After Turbo Vision and fooyin, this was fairly quick. There would've been less turbo
packaging lag had it not been for other life events making things busy, but still comparatively quick compared to those two prior stints.
The turbo
packaging only needed a GNUInstallDirs patch, similar to what Turbo Vision needed. Unlike the tvision
patch however, it has not yet been merged upstream as of time of writing. Without this patch, the CMake config files were being put into /lib
all the time. I thought this was fine intially, until it was pointed out that these were also architecture-dependent. Didn't expect that, but ok then.
In the end, there are four packages that are now in openSUSE Tumbleweed:
tvision-devel-static
- development files for Turbo Vision 2.0tvision-demos
- tvdemo
and tvedit
demo programs for Turbo Vision 2.0turbo
- turbo
text editor, library, and manpage documentationturbo-devel
- Development files for the turbo
text editortvdemo
demonstrates what Turbo Vision can do by having a couple small programs available to play with. It even includes the original copyright from Borland International!
tvdemo
showing a puzzle, calendar, calculator, ASCII chart, event viewer, and an about dialog with the original Borland International copyright
tvedit
is a barebones text editor that shows how a TUI app with multiple windows can be done. This might be an ok choice for anyone who just needs a very simple and intuitive text editor.
tvedit
with three KDiskMark benchmark results files open
turbo
meanwhile is a more advanced text editor, which is somewhat approching the territory of code editor. It was originally made to push the Unicode support in Turbo Vision, but it is gradually being fleshed out with more features.
turbo
with multiple files and an Open File dialog visible
As of time of writing, the following planned features are still missing:
Most of the other planned features such as initial syntax highlighting, clipboard integration, and a lot more have already been implemented. The project and the modern Turbo Vision 2.0 port largely has only a single contributor though, so these project could use a couple more folks getting involved!
There is another program that uses Turbo Vision called tvterm
. It's a TUI terminal emulator that's even more experimental than turbo
is. Development has stalled and most of its planned features haven't been implemented yet. However despite its very early state, it can at least render various CLI and TUI programs correctly and consistently. I've tried another similar project (which won't be named) which has more features, but frequently struggled with correct rendering most CLI and TUI programs at it. I am hoping that somebody will eventually pick up the development of tvterm
and get it into a better state.
Special thanks again to the openSUSE community for helping me out. However this time, I'd like to specifically thank a couple folks:
tvision
packaging into shapeosc
-compatible tvision
patch and for telling me about using quilt
for patches (which I'll look into later)tvision
The true end of this post was with the previous section. This part is more of a braindump or stream of thought that's somewhat related to Turbo Vision and TUIs.
I do wonder if it would be possible to create a desktop environment based entirely on a CLI/TUI. For fun mostly, but who knows if there could be practical uses for it? Turbo Vision provides a framework for creating GUI-like programs, from windows to mouse support and everything in-between. With the more advanced technologies available to both terminals and TTYs (32-bit colour, GPU acceleration, Direct Rendering Manager, etc.) and some older technologies becoming more widespread (e.g. Sixel for terminal graphics), in theory it would be possible to get TUIs even closer to their GUI counterparts. These ideas are partly why I am hoping that tvterm
development gets going again, since it'll prolly be instrumental to seeing this all materialise. Perhaps this hypothetical desktop environment could be called CLIDE (Command Line Interface Desktop Environment), hmm?
Anyways, that's enough yapping from me on this.