aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPřemysl Eric Janouch <p@janouch.name>2020-08-15 06:09:51 +0200
committerPřemysl Eric Janouch <p@janouch.name>2020-08-15 06:10:05 +0200
commitd0ce3e3e661852880fd2313ae3f9523ee6333253 (patch)
tree004150e1a957f8d53b49a71b0bfa3ba20f53f55f
parent3a5cc216bb6d497b28103d19b8471b5a89498cf9 (diff)
downloadhaven-d0ce3e3e661852880fd2313ae3f9523ee6333253.tar.gz
haven-d0ce3e3e661852880fd2313ae3f9523ee6333253.tar.xz
haven-d0ce3e3e661852880fd2313ae3f9523ee6333253.zip
Update README.adoc
-rw-r--r--README.adoc105
1 files changed, 5 insertions, 100 deletions
diff --git a/README.adoc b/README.adoc
index 0c0fa23..982c287 100644
--- a/README.adoc
+++ b/README.adoc
@@ -3,6 +3,11 @@ Project haven
haven is an umbrella project for a range of mostly desktop applications.
+This README is being converted into a wiki on the wiki branch, also publicly
+available at https://p.janouch.name/haven/Haven.html[]. We should only document
+here that which has been created, as the extent of the rationale and plans is
+gigantic and seems to have a life of its own.
+
Goal
----
The greater goal is to create a fresh computing environment for daily work and
@@ -47,106 +52,6 @@ See Projects for more information about the individual projects.
Some taken names in Debian: hd (important), hte, hy.
-Identity
---------
-The name merely hints at motivations and otherwise isn't of any practical
-significance other than that we need an identifier. This time I resisted using
-something offensive for personal amusement.
-
-A logo covering the entire project is not needed and it seems hard to figure out
-anything meaninful anyway, though we might pick a specific font to use for the
-project name <1>.
-
-The only mascot I can think of would be a black and white or generally grayscale
-My Little Pony OC but I don't really want to bring my own kinks into the project
-and I'd also need to learn how to draw one so that I don't infringe on someone
-else's copyright, or find someone else to do it. Anyway, in lack of a proper
-logo, she could have a simple "h" or "hvn" for a cutie mark <2>.
-
- __
- <2> _/ /_ <1> | _ _ _ _
- \ _ \ |/ \ / \| \ / /_\ |/ \
- / / / / | | | | \ / | | |
- /_/ /_/ | | \_/| \/ \_/ | |
-
-An anime-style character would also make me happy but that's ever harder to draw
-for me.
-
-I'm not sure where I took this "h" letter styling from, it seems too familiar.
-The above illustrations also show how awful it looks when a logo is just
-a stylized version of the first letter of a name when you put the two next to
-each other. Distinctly redundant. Facebook and Twitter are doing fine, though,
-perhaps because they do not use them together like that.
-
-Technicalities
---------------
-
-Languages
-~~~~~~~~~
-Primarily Golang with limited C interfacing glue, secondarily C++17, mostly for
-when the former cannot be reasonably used because of dependencies.
-
-Build system
-~~~~~~~~~~~~
-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).
-
-GUI
-~~~
-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.
-
- - https://rosettacode.org/wiki/Window_creation/X11#Go
- - https://github.com/llgcode/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.
-
-.Resources:
- - https://github.com/golang/exp/tree/master/shiny is a GUI library
- - https://github.com/as/shiny is a fork of it
- - http://man.cat-v.org/plan_9/1/rio has a particular, unusual model
-
-Internationalisation
-~~~~~~~~~~~~~~~~~~~~
-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.
-
-Versioning
-~~~~~~~~~~
-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.
-
Projects
--------
These are sorted in the order in which they should be created in order to gain