Testing ground for GUI
Go to file
Přemysl Eric Janouch 084a0a94b0
hswg: avoid self-referential links
2020-08-18 06:35:32 +02:00
hid Name change 2020-08-01 14:01:58 +02:00
hnc Name change 2020-08-01 14:01:58 +02:00
hpcu hpcu: eliminate infinite looping 2019-02-04 09:27:10 +01:00
hswg hswg: avoid self-referential links 2020-08-18 06:35:32 +02:00
ht ht: add generated wcwidth tables and algorithm 2018-10-07 18:09:09 +02:00
nexgb Name change 2020-08-01 14:01:58 +02:00
prototypes Name change 2020-08-01 14:01:58 +02:00
.gitignore Update .gitignore 2020-08-06 19:04:11 +02:00
LICENSE Name change 2020-08-01 14:01:58 +02:00
README.adoc Update README.adoc 2020-08-15 06:10:05 +02:00
go.mod hswg: bump libasciidoc to a dev version 2020-08-17 04:40:20 +02:00
go.sum hswg: bump libasciidoc to a dev version 2020-08-17 04:40:20 +02:00

README.adoc

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 play—easily controllable, reasonably complex, both visually and internally unified and last but not least responsive. One should be able to use it comfortably with a 60% keyboard and no pointing device.

haven serves as a testing ground, leaning on the side of compromises. It aims to use todays Linux desktop as a support, relying on X11/Wayland, existing window managers and web browsers.

The focus is therefore on going breadth-first, not depth-first. Applications only need to be good enough to be able to replace their older siblings at all. I.e. for me personally.

Scope

Subproject names aim to have the minimum viable, reasonably identifiable name. To group them together, a common prefix of "h" is used. The second column is what should be used as the name in .desktop files, just like the GNOME project figured out it would make sense:

  • hbe - bitmap editor

  • hbfe - bitmap font editor

  • he - text editor

  • hfm - file manager

  • hib - IRC bouncer

  • hic - IRC client

  • hid - IRC daemon

  • hiv - image viewer

  • hm - mail client

  • hmpc - MPD client

  • hnc - netcat-alike

  • ho - all-powerful organizer

  • hsm - system monitor

  • hss - spreadsheets

  • htd - translation dictionary

  • ht - terminal emulator

  • htk - GUI toolkit library

See Projects for more information about the individual projects.

Some taken names in Debian: hd (important), hte, hy.

Projects

These are sorted in the order in which they should be created in order to gain the best possible momentum. The htk GUI toolkit is implied as a side product permeating the entire list.

Some information is omitted from these descriptions and lies either in my head or in my other notes.

hidIRC daemon

This project is unimportant by itself, its sole purpose is to gain experience with Go on something that I have already done and understand well. Nothing beyond achieving feature parity is in the initial scope.

One possibility of complicating would be adding simple WebSocket listeners but thats already been done for me https://github.com/kiwiirc/webircgateway and its even in Go, I just need to set up kiwiirc.

Later, when we have a pleasant IRC client, implement either the P10 or the TS6 server-linking protocol and make atheme work with a generic module. Alternatively add support for plugins. The goal is to allow creating integrated bridges to various public forums.

hncnetcat-alike

The result of testing hid with telnet, OpenSSL s_client, OpenBSD nc, GNU nc and Ncat is that neither of them can properly shutdown the connection. We need a good implementation with TLS support.

hpcuPRIMARY-CLIPBOARD unifier

An improved replacement for autocutsel in selection synchronization "mode":

  • using only one OS process;

  • not polling selections twice a second unnecessarily;

  • calling SetSelectionOwner on change even when it already owns the selection, so that XFIXES SelectionNotify events are delivered;

  • not using cut buffers for anything.

Only UTF8_STRING-convertible selections are synchronized.

hswgstatic website generator

Wraps libasciidoc to make it understand more syntax, namely two-line/underlined titles, and can be run either as an AsciiDoc processor for my Gitea, or as a trivial wiki-like site generator.

htterminal emulator

Similar scope to st(1). Clever display of internal padding for better looks.

hib and hicIRC bouncer and client

An IRC client is a good starting application for building a GUI toolkit, as the UI can afford to be truly minimalistic and most of it is text.

To resolve an issue I have with my current IRC client, the client is going to be split into two parts: a bouncer that manages all connections and state, and a separate GUI that communicates with the backend over TLS/WebSocket. Perhaps only the per-buffer input line is going to be desynchronized.

The higher-level client-server API could be made rather generic to allow for smooth integration with non-IRC "backends" such as Slack or Mattermost.

hetext editor

VIM controls, no scripting, no syntax highlight, single-file, made for variable-width/proportional fonts. Initially done primarily to produce a text editing widget, which is going to be an interesting challenge, arguably better solved by whole program composition. Scintilla may provide some inspiration.

In the second stage, support for the Language Server Protocol will be added so that the project can be edited using its own tools. Some scripting, perhaps a tiny subset of VimL, might be desirable. Or other means of configuration.

Visual block mode or the color column may still be implemented.

The real model for the editor is Qt Creator with FakeVIM, though this is not to be a clone of it, e.g. the various "Output" lists could be just special buffers, which may be have names starting on "// ".

hoall-powerful organizer

Zettelkasten with fulltext search, arbitrary reciprocal links, arbitrary tags. Flat storage. Should be able to use translation dictionaries for search hints.

Indexing and search may be based on a common database, no need to get all fancy:

htdtranslation dictionary

This specific kind of application doesnt need a lot of user interface either, just a tab bar, text entry and two columns of text with simple formatting.

For simplicity we will establish a custom dictionary format based on either simple compress/gzip with separate files in StarDict style or, since we dont really strive for random access and memory-efficiency (those 120M that sdtui takes with my 10 dictionaries isnt particularly bad), pack everything with archive/zip.

Instead of ICU we may use x/text/collate and thats about everything we need. Since we have our own format, we may expect the index to be ordered by the locales rules, assuming they dont change between versions.

hmpcMPD client

Here the focus will be on the GUI toolkit. I dont expect this application to get big, since its predecessor nncmpp isnt either. The daemon takes care of all complex stuff. It would be nice to add lyrics and search later, though.

hivimage viewer

JPG, PNG, first frame of GIF. Zoom. Going through adjacent files in directory using cursor keys. Possibly a dialog with image metadata.

hfmfile manager

All we need to achieve here is replace Midnight Commander, which besides the most basic features includes a VFS for archives. The editing widget in read-only mode could be used for F3. The shell is going to work very simply, creating a PTY device and running things under TERM=dumb while decoding SGR, or one could decide to run a new terminal emulator with a different shortcut. ht could probably also be integrated.

Eventually the number of panels should be arbitrary with proper shortcuts for working with them. We might also integrate a special view for picture previews, which might or might not deserve its own program.

hssspreadsheets

The first version doesnt need to be able to reference other cells, and can more or less be a CSV editor.

We can take inspiration from Excel:

The rest

Currently there are no significant, specific plans about the other applications.