Re:Learning from Terminals to Design the Future of User Inte...
by astrobe_ on Saturday August 04, 2018 @04:32AM
(#17685955)
Personally I use GNUScreen in addition to dwm, but mainly because I use a 15 years-old Celeron PC as a network console, which for some reason puts a one-two seconds tax on window creations.
This setup is quite flexible, but you can get lost easily, in particular if in addition you use ctrl+Z carelessly.
An alternative is Emacs, which will give you shells and windows and splits and somewhat-interactive documents (org-mode) and has some support for images. If you're ready to sacrifice an hour per day to Emacs configuration for the next twelve years, it will do your biddings eventually...
Re:Learning from Terminals to Design the Future of User Inte...
by sdx23 on Saturday August 04, 2018 @04:29AM
(#17685944)
> screws up my carefully constructed window layout.
To me this is off. With a tiling window manager I don't have to "carefully construct" a window layout. That's the window managers job!
Re:Learning from Terminals to Design the Future of User Inte...
by GlenTheMachine on Saturday August 04, 2018 @12:28PM
(#17687448)
There's nontrivial mental burden incurred every time the window manager changes where the windows are, at least for me.
Re:Learning from Terminals to Design the Future of User Inte...
by omaranto on Saturday August 04, 2018 @01:39AM
(#17685542)
How about instead of something merely like Jupyter you just use precisely Jupyter? I'm sure someone wrote a shell kernel, and if not, use ipython's shell magic.
Re:Learning from Terminals to Design the Future of User Inte...
by GlenTheMachine on Saturday August 04, 2018 @09:49AM
(#17686827)
That... could actually work. In fact there is a bash kernel for Jupyter. Not a lot of info about it on the github page, but it's there.
Then the issue becomes how well bash output takes advantage of Jupyter. Research forthcoming.
For example, right now I can issue a shell command that lists cpu utilization by process (top). I can even have that command autorefresh, showing me changes in real time. But to do that it takes over the shell. It'd be neat to think about a shell where I could issue a top command, then command displays and exits, giving me a shell prompt again. But I have the option of asking the shell to update the old output every N seconds.
Yes, I could in i3 spawn a new shell and just keep top running in it. And maybe in the long run that's the better interface. But doing that screws up my carefully constructed window layout.
I guess what I'm saying is that we have two interface paradigms: the gui, and the command line. But interfaces like Jupyter and Mathematica show that there are middle grounds between those two extremes, and that middle ground is interesting.