Hacker News Reader

Comment by ajarmst | Hacker News Reader

The width of the display used in the screenshot appears to be less than 150 characters. Why would you add the clutter and distraction of transparent windows with frame decorations in such a limited environment? 30% of the real estate is consumed by elements that don't present any information to the user.

On a modern display, this could far more productively be replaced with (1) any number of tiling WMs with console terminals in the panes (I use stumpwm for this), or---and you don't even need a GUI/WM for these---tmux or screen, or even emacs -nw, which give you a much more configurable and robust text-only environment. My normal working environment is a pretty heavily customized tmux (including powerline and full 256-color/unicode support) running on a machine that doesn't even have a GUI installed. (I do cheat a bit by using kmscon---or fbcon in the past---to get colour and font support on linux vttys.).

View on HN

The demo video (https://www.youtube.com/watch?v=fLumnSctakY&feature=youtu.be) reveals that this is not just a traditional window manager for a static screen, it's got a much larger virtual canvas that the display can scroll around in. So there's a LOT more space to make an aesthetic decision for big, character-wide window frames.

Seriously go watch the video, this thing feels like it's got a foot in the realm of UI roads not taken like Raskin's zoomable UI, text-mode is maybe more just a way to keep their focus on thinking about the interactions without having to worry about drawing a bunch of pretty widgets.

Yeah, I see it. I just don't get it. There's an awful lot of UX work being done to preserve an illusion that you have a bunch of fixed-size consoles that are arbitrarily arranged in a 2d space. Which, I guess, is the defining metaphor of GUI interfaces, but if that's what is desired, why create a console-only (if only in appearance) GUI? Text buffers in emacs or panes in screen or tmux can be made to have arbitrary size and dimension if you want to turn off wrapping and keep a longish scrollback. You can have as many buffers as you want, as many as your screen can accomodate visible at once and easily navigate them as you like. All you have to give up is the conceit that windows have independent physical size and location and embrace one that holds that you can have an arbitrary number of text buffers available to arrange, swap, hide, show, etc. Not trying to be nasty, but this feels like a bit of a cargo cult: someone stuck in the windows GUI metaphor trying to create a version of CLI metaphor they don't fully grasp. Of course, the fact that those of us who prefer the CLI metaphor are rapidly dying off is relevant here---but seizing all of the disadvantages of an all-text environment without any of the advantages seems ill-advised. That said, no one needs my approval. If this works for you (and I'll readily admit it's kind of cool), what do you care that I don't get it.

Typing text into a terminal/buffer is easy. But remembering all the shortcuts or cammands to resize and move windows in termux et.al is hard. Resizing and dragging with a mouse is easier (or fingers on a touch screen/interface)

I agree that it feels really confused but if I can get it running one day with the ability to save my sessions, I would gladly flip between this and X+i3 for my daily driver.

What I see offered here is a way of mapping a huge, non-software project more loosely than a strict classification-based directory/file structure. Specifically I've been slowly fleshing out my own fantasy world with lore and history. I tried the live demo and I can totally see this meshing really well with the part of my brain that likes fiction because it can be a little messy.

I also think the friction of learning a new UI would be a benefit here in reducing the amount of "laptop fatigue" which keeps me from writing less technical stuff after wrestling with a bug all day.

At the end of the day, its a fun project. Plus tmux can get annoying configuring behavior to feel like something more native in terms of mouse use consistently. Either it works great scrolling up in the shell or it works great scrolling with an editor open, never both.

Wow. The organizational lines and brightly colored windows make it look like a flower.

Things like borders may be empty of content but that doesn’t mean they don’t help you see and understand other content more easily.

Agreed. But using an entire character-width for that purpose is extravagant in this example (use of background colour would be better. Right now, some of those windows are !0% border). In a larger area, you can use unicode or even the drawing characters in MS 8-bit ASCII for a single-pixel hairline plus padding for both windows' text). I guess my take is that this is sacrificing an awful lot of real-estate to simulate overlapping windows, which is a feature of dubious utility in a pure text environment. "Users expect them" is probably the most common and egregious excuse for bad UX design, but I do understand why.

Window transparency is actually a way to increase the information density; if you set the transparency just right, with a bit of practice you can essentially view the contents of several windows at once in the same space. For a long time I used a laptop with only XGA (1024x768) resolution, and writing code in a semi-transparent window with docs, IM, and several other windows underneath made the small screen far more usable than it would be otherwise.

Except in this case, it's not real, you can't read any characters below another window.

80x24 is the default terminal height. I mostly use this size on all of my projects. It has many favors: compatibility everywhere, tiny bandwidth, etc.

And, of course, ed is the default editor. :-) I exert geek dominance over introduction to C students by demoing using ed to modify a source file. After which I amuse myself for the remainder of the term: "Source Control? Syntax highlighting? Luxury! When I was young we had to hand-magnetize knitting needles and edit files one bit at a time directly on a Winchester drive!"

More seriously, I think the 80 column width is just too constraining with more modern languages that aren't remotely as terse as C–not to mention a limit that aggressively militates against in-line commenting. We also have monitors and fonts with resolutions that permit easily reading much denser use of the visual display. I mostly go with 120 chars now (in practice, that means that lines still won't wrap when I print source code files) and however many lines fit into the display pane.

Even though 120 fits comfortably on the screen, I find it leads to sloppier code than 80 or 90. The latter exerts pressure to "do one thing per line, and make it neat."

Ime this is true of modern langs like ruby or javascript or Go, as well as older langs like bash. But I know this is a religiously contentious subject, so to each his own.

I like 80 for my Go projects.

Anecdotal, but- It does feel like a good visual approximation and when I start to run close to it I usually pause and figure out if that code needs attention.

Yeah, why did we ever stop using it as default for everything. I grow weary of graphics and options with said graphics.

Reply on news.ycombinator.com