
Revisiting the Arcan Project - crazyloglad
https://arcan-fe.com/2018/05/31/revisiting-the-arcan-project/
======
bhattisatish
Very interesting project. The presentation[0][1] (though from 2015) gives an
interesting overview of the two projects. The youtube channel[2] has some
exciting [3] videos. And I really like his argument for Server Side
Decorations[4]

Another project to keep an eye out for is Simula[5]

[0]
[https://speakerdeck.com/letoram/arcan](https://speakerdeck.com/letoram/arcan)

[1] [https://speakerdeck.com/letoram/durden-tiling-desktop-
enviro...](https://speakerdeck.com/letoram/durden-tiling-desktop-environment-
for-arcan)

[2]
[https://www.youtube.com/channel/UCGooU472l1UqbUCXR3q1SEQ](https://www.youtube.com/channel/UCGooU472l1UqbUCXR3q1SEQ)

[3]
[https://www.youtube.com/watch?v=Js7Y1H5D8cY](https://www.youtube.com/watch?v=Js7Y1H5D8cY)

[4] [https://arcan-fe.com/2018/01/27/argumenting-client-side-
deco...](https://arcan-fe.com/2018/01/27/argumenting-client-side-decorations/)

[5] [https://github.com/SimulaVR/Simula](https://github.com/SimulaVR/Simula)

------
zokier
The section "TUI : Text-based User Interfaces" resonates with me strongly, and
is somewhat relevant to the WTF thread[1] from yesterday, in particular this
subthread[2] about GUI vs TUI.

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](https://news.ycombinator.com/item?id=17195618)
[2]
[https://news.ycombinator.com/item?id=17196031](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)](https://en.wikipedia.org/wiki/WIMP_\(computing\))
[5] [http://visidata.org/](http://visidata.org/) | Demo:
[https://www.youtube.com/watch?v=N1CBDTgGtOU](https://www.youtube.com/watch?v=N1CBDTgGtOU)
[6] [https://mstijak.github.io/tdo/](https://mstijak.github.io/tdo/) [7]
[https://fman.io/](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.

~~~
crazyloglad
Author here - do write it up as a blog post, the discussion should be had and
a bit more systematically if you don't mind me saying so, and I have quite a
lot of things more to chime in with.

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](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).

