Revisiting the Arcan Project
arcan-fe.com
arcan-fe.com
Another project to keep an eye out for is Simula[5]
[0] https://speakerdeck.com/letoram/arcan
[1] https://speakerdeck.com/letoram/durden-tiling-desktop-enviro...
[2] https://www.youtube.com/channel/UCGooU472l1UqbUCXR3q1SEQ
[3] https://www.youtube.com/watch?v=Js7Y1H5D8cY
[4] https://arcan-fe.com/2018/01/27/argumenting-client-side-deco...
Compare the statements:
> terminal protocols are ghastly display server protocols in disguise
vs
> > At what point do we just say why not 'install a modern GUI'?
> I have yet to see a modern GUI that didn't put pretty little animations a higher priority than being modular and configurable and having as much or as little data density as I desire
> Command lines[3], on the other hand, do it natively if not intuitively.
Which brings up few interesting observations:
* Terminal vs graphical is almost completely orthogonal and an implementation detail. There are plenty of WIMPy style[4] TUI/ncurses applications, and also various forms of commandlines/repls that are natively graphical.
* I'd argue that there are few other categories that are less often recognized, namely "keystroke-driven" and "web style" (nomenclature is mine and not fully though out).
* The characteristic attributes of "keystroke-driven" is full interactivity (in contrast to command-line) but where typically there are no (or minimal) interactive elements on-screen. Some examples off my head would be VisiData[5], tdo[6], fman[7]. These types of applications tend to have very high data densities (what the commenter above desired)
* "Web style" applications is more ambiguous (and debatable) category, but I think there is a distinction to be made between more traditional relatively rigid widget and form based UIs and the more free-form (and usually more heavily stylized) "modern" UIs that have been heavily inspired by (and/or implemented with) web design and technology.
* There is currently fairly big chasm between graphical applications and TUI applications, which I believe to be because there isn't really established libraries that would be effectively "graphical ncurses". I do believe that it is a chasm that deserves to be bridged. There is no real reason why developers wanting to create small, fast, powerful tools should be constrained to archaic character cell grid by default.
[1] https://news.ycombinator.com/item?id=17195618 [2] https://news.ycombinator.com/item?id=17196031 [3] editors note: Considering the context, I suspect inetknght meant terminal applications here when they wrote "Command lines" [4] https://en.wikipedia.org/wiki/WIMP_(computing) [5] http://visidata.org/ | Demo: https://www.youtube.com/watch?v=N1CBDTgGtOU [6] https://mstijak.github.io/tdo/ [7] https://fman.io/
in retrospect I probably should have made this a blog post instead of shoehorning it as a comment here, but oh well.
Another relevant point for thought that was provided to me as a response to the original article is the design and thoughts behind https://www.eblong.com/zarf/glk - in hindsight it is more than reasonable that the interactive-fiction crowd had been working in the problem space but not attempting to generalize it.
Vis a vis animations, those can still serve a certain point of they are set up for cognition rather than mere aesthetics. A simple example is switching workspaces. Some of the people I worked with refrained from having tag-sets, or tiling with workspace switching and kept a surprising amount of windows around yet knowing about compartmentalising into workspaces. The argument was a problem with finding 'where all the windows went' on a switch, and that feeling, anecdotally, went away when the workspace switching animation indicated a direction, left-to-right or right-to-left depending on if the workspace index went up or down. That is the mental grouping was not in 'specific windows -> workspace number or identifier' but a spatial place, even if not visible.
While I agree between the gui/tui chasm (and often try to use text-dominant or similar phrasing - though in my head there is no real distinction between graphical and text - considering rendering emoji from a font is equivalent or darn well close to blitting tiles from a tilemap), I consider it more of a gammut where you sortof have to draw a line in the sand. The glyph+attributes in cell addressing model is much less complex than 'per pixel' even when accounting for BiDi/shaping/ligatures. Just don't mix the two which is the norm now, drawing a popup with text characters when it could've been... a friggin popup is a tragedy, and not even a good one.
That said, and this touches upon the bigger idea partly hidden behind the many lines - there is a need for what could've been the 'gestalt' of the mobile "app" idea had it not drifted towards such an opportunistic, exploitative and dark-pattern filled anti-user clusterfuck, and that is the notion of a 'one thing, and well' graphical applications. I think we need both, one biased towards the graphical, one towards the textual and that they can come from the same process, just that some kind of system enforced barriers are in place so the meta-ui (window manager) doesn't degenerate into a hierarchy of nested WMs fighting to block one another's view of the system (browser to window manager to tmux to terminal to shell to virtual terminals) sortof all fight to be the same underspecified 'thing'.
I document more than I disseminate, and the article belongs more in the former category, but for what I'm sortof feeling are concerns you'd enjoy in the context of the TUI discussion are two coming articles (monitor the rss, I rarely touch the browser) "rethinking desktop configuration: my UI is a filesystem" and "leveraging the display server API to bootstrap better debugging" (titles being subject to change).