I've been thinking about such text-based DE for custom Raspberry Pi nano based smartphone. Reason being, common mobile apps are not going to arrive for Linux and Nano is not powerful enough to run web browsers anyways; So why not a text-based DE or even just a console which enables basic communication features and Lynx for browsing? It would be great if we could get some GPU juice from Pi for text rendering in such e…
Are you talking about a Pi Zero? That can totally run a desktop environment and browser. Especially something light like XFCE or Enlightenment.
What's the point of overlapping windows in text? Seems that tmux already fits the bill for this use case.
Its good to see experiments like this. Maybe this project won't be the next big thing, but maybe it will give someone an idea of what the next big thing should be.
Tip: If you want to escape from any ssh session you can press this sequence: 1. Press Enter. 2. ~ Press Tilde. 3. . Press dot. This disconnects from the remote host. If you want more: `man ssh` and look for "ESCAPE CHARACTERS"
You can do ? instead of . and it will tell you what else it can do. Client side escape sequences. Handy to know!
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 t…
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…
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.
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 t…
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.
This looks quite cool, but I don't think it's open source? I can't find any source code in the repository, there's just a single file called not_ready_yet.
I was at least hoping to see information about the language(s) used.