Technicalities

Primarily Golang with limited C interfacing glue, secondarily C++17, mostly for when the former cannot be reasonably used because of dependencies.

https://github.com/zevv/bucklespring is a good example of a rather simplified project that makes do with a single Makefile, even for cross-compilation on Windows. Let us avoid CMake and the likes of it.

It seems that Go can link dynamically, therefore I could build libhaven.so (https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ and https://stackoverflow.com/questions/1757090/shared-library-in-go) and have the rest of the package as rather small binaries linking to it. The "cannot implicitly include runtime/cgo in a shared library" error is solved by "go install", which again requires "-pkgdir" because of privileges. libstd.so is a beautiful 30 megabytes (compared to libc.a: 4.9M).

Probably build on top of X11/Xlib or xgb. Wayland can wait until it stabilizes—​it should not be a major issue switching the backends. Vector graphics can be handled by draw2d.

The c2 wiki unsurprisingly has a lot of material around the design and realisation of GUIs, which might be useful.

It seems like an aligning/constraint-based "layout manager" will be one of the first harder problems here. However I certainly don’t want to use fixed coordinates as they would introduce problems with different fonts and i18n.

We could use BDF fonts from the X11 distribution, but draw2d has native support for FreeType fonts and it’s more of a choice between vectors and bitmaps.

The looks will be heavily inspired by Haiku and Windows 2000 and the user will have no say in this, for simplicity.

For i18n https://github.com/leonelquinteros/gotext could be used, however I’ll probably give up on this issue as I’m fine enough with English.

Go also has x/text packages for this purpose, which might be better than GNU, but they’re essentially still in development.

Versions are for end users. We can use a zero-based, strictly increasing number, be it a simple sequence or date-based numbers such as 1807. If we do this at all, we will eventually also need to release patch versions.

Since dates don’t seem to convey important information, let us settle on 0, 1, 1.1, 2, 3, 3.1, 3.2, …​ In practice releases are going to be scarce, unless we find a person to take care of it. Note that there is no major/minor pair—​ a new project will be created when radical philosophical or architectural changes are to be made. See Goal.

All will be released into the public domain. The preferred way of doing so is the 0BSD license.

Other people’s libraries may be used or even imported if it makes sense, so long as they’re not licensed under something either viral like the GPL, or annoying such as the original 4-clause BSD license.