Further reduce scope
The idea of hic now lives as xP within the xK project, and the idea of hib has been implemented within xC.
This commit is contained in:
parent
1528ed2db0
commit
18e8e11ad4
17
README.adoc
17
README.adoc
|
@ -34,8 +34,6 @@ figured out it would make sense:
|
|||
- hbfe - bitmap font editor
|
||||
- he - text editor
|
||||
- hfm - file manager
|
||||
- hib - IRC bouncer
|
||||
- hic - IRC client
|
||||
- hid - IRC daemon
|
||||
- hm - mail client
|
||||
- hnc - netcat-alike
|
||||
|
@ -100,21 +98,6 @@ ht -- terminal emulator
|
|||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Similar scope to st(1). Clever display of internal padding for better looks.
|
||||
|
||||
hib and hic -- IRC 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.
|
||||
|
||||
https://godoc.org/github.com/gorilla/websocket
|
||||
|
||||
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.
|
||||
|
||||
he -- text editor
|
||||
~~~~~~~~~~~~~~~~~
|
||||
VIM controls, no scripting, no syntax highlight, single-file, made for
|
||||
|
|
Loading…
Reference in New Issue