Might be more useful to discuss which applications really benefit from a GUI, besides a browser. I find a GUI DB client to be indispensable for doing basically anything with a database, for example.
I’ve been using jetbrains DataGrip for years and it’s been great. My day to day stuff is in vim and I don’t really use anything else from jetbrains but datagrip has been really good.
Need to chime in here, been using Data Grip (previously know as 0xDBE) since the early alpha around 2013/14 and it’s been a game changer for me, no other DB-IDE comes close in my opinion. However pg-cli is great for quick queries.
Someone tell this guy about Emacs’ -nw option, at least he’ll get a uniform interface when trying to do this.
Sometimes i think about doing this too, just to avoid distractions, but personally I just use too many PDFs that I don’t want to print out all the time, with too much mathematical notation to properly extract the text.
w3m supports inline images (via installing the w3m-img package)—seriously, a web browser with image support, inside the terminal. The future is now.
So was he just using terminal emulators under X, or a “proper” tty? Because the screenshots look like terminal emulators.
I use some rss to email program to read my feeds the same way I read my emails. I can’t remember what it’s called off the top of my head but it shouldn’t be hard to find. Have you ever tried doing something like that?
I wouldn’t want to. I like the visual style of graphics, especially the web. You need diversity in your visuals, I think doing everything in a terminal including web browsing eventally becomes stressful.
I think doing everything in a terminal including web browsing eventally becomes stressful
I disagree. I find the consistent interface (visual and input) to be less stressful than being subject to the different whims of every different UI toolkit/application. Some UIs support vim-like bindings, some don’t. Some have massive toolbars, some have none, and some hide stuff under a single button. Some use spacebar to scroll, some use it to submit/play content. Etc, etc.
Sure, it may be hard, but it is possible to give up graphical interfaces
entirely—even in 2019.
Graphical browsers have the benefit of presenting a readable layout.
Most webpages are difficult to navigate in w3m, unless they are
extremely barebones. Looks like w3m is not fully pledged, either.
I live in the terminal for most non-browser things and being able to SSH
from my wimpy laptop/desktop to a beast of a server is my killer feature.
Editing images, audio and video from the commandline is something I
rarely do but I have seen people do it.
Editing images, audio and video from the commandline is something I rarely do but I have seen people do it.
I’m not sure command line tools are capable of editting images and video in any useful or meaningful sense. Adjusting color, touching up areas, checking focus, etc. are innately visual thing to do, and by their nature don’t lend themselves to bulk processing and automation in most situations.
Depends on the edit, doesn’t it? If you have two images and you just want to place one next to the other, that’s easy. If you have an audio file and you want to splice out the section from 1:30 to 1:45 and cut the volume on everything after 3:00 to 50%, you don’t need anything visual for that.
I didn’t mention audio, and it does seem more amenable to command line processing than images and video because it doesn’t really have a visual component.
For images and video it does depend somewhat on what the task is. Certainly specific edits lend themselves to command line tools, but it’s such a small subset of possible edits I don’t think it’s very useful.
The image editting I’m most familiar with is photo touch up and RAW conversion, and even the most basic adjustments like white balance or exposure would be incredibly tedious and error prone with command line tools.
In a sense the whole concept of image editting is pointless without a way to view the results anyway.
I agree with you, for an image here or there, when you aren’t quite sure exactly what you want done, a GUI image editor is generally easier.
When you need to edit more than 10 images… or automate your editing(as part of some application/website) then a CLI interface to do these things is beautiful.
If you know exactly what you want done, regardless of file count, then a CLI might be easier. Like @technomancy said, or stripping JPEG metadata or something.
So I think it has a lot more to do with what you are doing and why, as to the CLI being better or not for editing of images, movies, etc.
When you need to edit more than 10 images… or automate your editing (as part of some application/website) then a CLI interface to do these things is beautiful.
Interesting. Do you have any suggestions for a tool to do these things that is more amenable to the task of on-the-fly image editing than, say, GIMP or Photoshop?
I use python’s pil/pillow[0] for automation stuff, and for CLI imagemagick[1].
Both are great ways to mess around with images. There is ffmpeg[2] and vlc[3] for video, etc.
As I mentioned before none of these CLI tools are particularly great for on-the-fly, not sure what you want done sort of tasks. But they are great tools to have in your toolbelt for automation or repetition.
One thing I’ve been experimenting with – very preliminarily, just for personal use, and not entirely in the terminal, to add some caveats – is moving some of my browser usage out of the browser. I don’t really like any of the textmode browsers, but when there is some kind of alternative API, you can interface with things in non-browser ways. For example, two websites I use very frequently are Wikipedia and OpenStreetMap, and they both have APIs.
For various reasons most of the experimentation with alternative interfaces seems to be on mobile. Wikipedia has an official app (which loads faster and has a nicer UI than the browser version), and there are various OSM apps. I don’t necessarily want to write full-fledged native apps on the desktop, but it’s nice that I have the option to bypass the browser layer if I want to look up a Wikipedia article by name and then display the text somewhere.
I have been doing the same, but on the terminal. There’s dict for dictionary lookups, translate-shell for Google Translate (and a few other translation services), I wrote my own scripts to get DuckDuckGo and Google search results, Wikipedia summaries, and I use rtv pretty often.
I still have a browser open most of the time, but just having them be an option is pretty nice - it cuts down on unnecessary searches, I have not needed to write translate.google.com in years, and it makes even very underpowered machines usable.
I don’t necessarily want to write full-fledged native apps on the desktop, but it’s nice that I have the option to bypass the browser layer if I want to look up a Wikipedia article by name and then display the text somewhere.
You could throw Tcl/Tk at the problem. Put a search bar at the top, add an htmllib widget, and bask in the HTML 2.0, browserless goodness.
It’s odd to me that Emacs wasn’t mentioned at all. I use it for most of my computing (email, music, file management, etc.) and it works well enough in the terminal if the Meta-key works properly, as opposed to needing to use Escape.
Luckily, people were emailing each other from UNIX/Linux machines long before modern graphical email clients (or webmail) even existed.
I suppose this is technically true, due to the use of ’‘modern’’ here, but I find it important to note that graphical interfaces for things such as email have existed for decades. Using terminals shouldn’t be an ideal.
I find the native terminal emulation provided by the Linux kernel and OpenBSD to be lacking. There’s not much of a good reason to query terminfo or termcap when every terminal you’re reasonably going to use supports a superset of ECMA-48. However, I’ve found that even basic sequences such as SCROLL UP and SCROLL DOWN aren’t supported in the native terminals. So, you get the choice between your program not working in those, making it inefficient and jittery for every terminal, or building a querying infrastructure; the first option is what I’ve chosen. If I’m wrong or anyone has any advice for this, I’d be interested in it.
I wouldn’t be writing a terminal program in this age if the GUI facilities of modern systems were decent and I could build up my own abstraction for that, but the terminal, with all of its added faults, is at least the simpler option. It would be nice to have facilities GUIs enjoy that let me express simple concepts such as ’‘The interface must be at least this large.’’, though.
I find it depressing that hackers are still focusing on text-only interfaces rather than getting to a place where graphical interfaces are easy and pleasant to hack on.
A graphical interface is a superset of text interfaces. There is literally nothing that can be worse (e.g. just boot up xterm), but so many things can be better.
In principle I’m interested in that (as a user, not much of a developer). But somehow the kind of GUI stuff that appeals to me for similar reasons that terminal-mode stuff does ends up with much shorter half lives. Once you leave both the KDE/Gnome style of GUIs and the browser-as-a-frontend style of GUIs, almost everything else seems to be unmaintained or quickly on the way there. There’s old X11 stuff that’s interesting but rarely looks like it’s been touched in 10 years, and may or may not even compile anymore; likewise for some of the experiments built using imlib/imlib2 back when Enlightenment was more active. There are also some one-offs that get basic maintenance but don’t seem really active as a community; for example the unix port of plan9’s sam does compile and work.
The main exception afaict is window managers, where there is still quite a bit of active experimentation with alternative GUI paradigms. Though that’s kind of a weird “meta” level of GUI experimentation, the shell rather than the apps that go inside of it.
With great power comes great responsibility. The superior technical capabilities of a graphical interface allow you to make something better than in a textual interface for sure, but also much worse - and it’s always easier to make something worse.
The constraints imposed by a TUI limit how awful an interface can be.
This doesn’t make much sense, the console is just a GUI with significant limitations. I don’t see any benefit.
In fact I think that making ncurses style GUIs inside terminals is an abuse of the tool and we should stop doing that. They should be lower tech and only handle a sequence of lines. If we did this then scrolling wouldn’t break randomly in terminals.
Reading this I’m kinda amazed how we didn’t get a plethora of technically-terminal applications that behave like DOS games of the 90s :) Maybe because technically they’re using stuff that’s not only terminal, just a different kind of graphical mode. Framebuffer?
But all the curses-like stuff is kinda rigid and TUIs are not so “creative” in their ways, they all kinda look samey and this might also limit what can be achieved.
Might be more useful to discuss which applications really benefit from a GUI, besides a browser. I find a GUI DB client to be indispensable for doing basically anything with a database, for example.
I’ve never used a GUI DB client. Any recommendations?
I’ve been using jetbrains DataGrip for years and it’s been great. My day to day stuff is in vim and I don’t really use anything else from jetbrains but datagrip has been really good.
Need to chime in here, been using Data Grip (previously know as 0xDBE) since the early alpha around 2013/14 and it’s been a game changer for me, no other DB-IDE comes close in my opinion. However pg-cli is great for quick queries.
I use https://dbeaver.io/
For OS X, TablePlus is my current favorite.
Someone tell this guy about Emacs’
-nwoption, at least he’ll get a uniform interface when trying to do this.Sometimes i think about doing this too, just to avoid distractions, but personally I just use too many PDFs that I don’t want to print out all the time, with too much mathematical notation to properly extract the text.
So was he just using terminal emulators under X, or a “proper” tty? Because the screenshots look like terminal emulators.
I believe w3m supports images in the linux framebuffer, without X11. There are also some hardware terminals with escape sequences for drawing graphics
I do most stuff in the terminal. File management, email, IM, music, word processing (plaintext vim for simple notes, vim with latex for nice stuff).
We’re probably all on the same page here so I’m curious as to what people don’t do.
convertcommand to use.Photo editing and photo organization/tagging are two things that I definitely can’t do in the terminal.
I use some rss to email program to read my feeds the same way I read my emails. I can’t remember what it’s called off the top of my head but it shouldn’t be hard to find. Have you ever tried doing something like that?
Is that something you self-host, or a third-party service?
The one that I use I run on a cron job locally, and it just adds a folder into my main maildir.
I wouldn’t want to. I like the visual style of graphics, especially the web. You need diversity in your visuals, I think doing everything in a terminal including web browsing eventally becomes stressful.
I disagree. I find the consistent interface (visual and input) to be less stressful than being subject to the different whims of every different UI toolkit/application. Some UIs support vim-like bindings, some don’t. Some have massive toolbars, some have none, and some hide stuff under a single button. Some use spacebar to scroll, some use it to submit/play content. Etc, etc.
is it stressful to read books?
books aren’t an illusory, all encompassing, two-dimensional plane without depth.
is it just that you like the look of GUIs? or you aren’t used to terminal applications so they’re more stressful to use?
Graphical browsers have the benefit of presenting a readable layout. Most webpages are difficult to navigate in w3m, unless they are extremely barebones. Looks like w3m is not fully pledged, either.
I live in the terminal for most non-browser things and being able to SSH from my wimpy laptop/desktop to a beast of a server is my killer feature.
Editing images, audio and video from the commandline is something I rarely do but I have seen people do it.
I’m not sure command line tools are capable of editting images and video in any useful or meaningful sense. Adjusting color, touching up areas, checking focus, etc. are innately visual thing to do, and by their nature don’t lend themselves to bulk processing and automation in most situations.
Depends on the edit, doesn’t it? If you have two images and you just want to place one next to the other, that’s easy. If you have an audio file and you want to splice out the section from 1:30 to 1:45 and cut the volume on everything after 3:00 to 50%, you don’t need anything visual for that.
I didn’t mention audio, and it does seem more amenable to command line processing than images and video because it doesn’t really have a visual component.
For images and video it does depend somewhat on what the task is. Certainly specific edits lend themselves to command line tools, but it’s such a small subset of possible edits I don’t think it’s very useful.
The image editting I’m most familiar with is photo touch up and RAW conversion, and even the most basic adjustments like white balance or exposure would be incredibly tedious and error prone with command line tools.
In a sense the whole concept of image editting is pointless without a way to view the results anyway.
I agree with you, for an image here or there, when you aren’t quite sure exactly what you want done, a GUI image editor is generally easier.
When you need to edit more than 10 images… or automate your editing(as part of some application/website) then a CLI interface to do these things is beautiful.
If you know exactly what you want done, regardless of file count, then a CLI might be easier. Like @technomancy said, or stripping JPEG metadata or something.
So I think it has a lot more to do with what you are doing and why, as to the CLI being better or not for editing of images, movies, etc.
Interesting. Do you have any suggestions for a tool to do these things that is more amenable to the task of on-the-fly image editing than, say, GIMP or Photoshop?
I use python’s pil/pillow[0] for automation stuff, and for CLI imagemagick[1].
Both are great ways to mess around with images. There is ffmpeg[2] and vlc[3] for video, etc.
As I mentioned before none of these CLI tools are particularly great for on-the-fly, not sure what you want done sort of tasks. But they are great tools to have in your toolbelt for automation or repetition.
0: https://pillow.readthedocs.io/
1: https://imagemagick.org/script/command-line-tools.php
2: https://ffmpeg.org/
3: https://www.videolan.org/
I feel like the ideal here is a gui tool with an internal shell without its own language just with several new shell builtins to handle the work.
One thing I’ve been experimenting with – very preliminarily, just for personal use, and not entirely in the terminal, to add some caveats – is moving some of my browser usage out of the browser. I don’t really like any of the textmode browsers, but when there is some kind of alternative API, you can interface with things in non-browser ways. For example, two websites I use very frequently are Wikipedia and OpenStreetMap, and they both have APIs.
For various reasons most of the experimentation with alternative interfaces seems to be on mobile. Wikipedia has an official app (which loads faster and has a nicer UI than the browser version), and there are various OSM apps. I don’t necessarily want to write full-fledged native apps on the desktop, but it’s nice that I have the option to bypass the browser layer if I want to look up a Wikipedia article by name and then display the text somewhere.
I have been doing the same, but on the terminal. There’s
dictfor dictionary lookups,translate-shellfor Google Translate (and a few other translation services), I wrote my own scripts to get DuckDuckGo and Google search results, Wikipedia summaries, and I use rtv pretty often.I still have a browser open most of the time, but just having them be an option is pretty nice - it cuts down on unnecessary searches, I have not needed to write
translate.google.comin years, and it makes even very underpowered machines usable.You could throw Tcl/Tk at the problem. Put a search bar at the top, add an htmllib widget, and bask in the HTML 2.0, browserless goodness.
are there fully pledged graphical browsers?
It’s odd to me that Emacs wasn’t mentioned at all. I use it for most of my computing (email, music, file management, etc.) and it works well enough in the terminal if the Meta-key works properly, as opposed to needing to use Escape.
I suppose this is technically true, due to the use of ’‘modern’’ here, but I find it important to note that graphical interfaces for things such as email have existed for decades. Using terminals shouldn’t be an ideal.
I find the native terminal emulation provided by the Linux kernel and OpenBSD to be lacking. There’s not much of a good reason to query terminfo or termcap when every terminal you’re reasonably going to use supports a superset of ECMA-48. However, I’ve found that even basic sequences such as SCROLL UP and SCROLL DOWN aren’t supported in the native terminals. So, you get the choice between your program not working in those, making it inefficient and jittery for every terminal, or building a querying infrastructure; the first option is what I’ve chosen. If I’m wrong or anyone has any advice for this, I’d be interested in it.
I wouldn’t be writing a terminal program in this age if the GUI facilities of modern systems were decent and I could build up my own abstraction for that, but the terminal, with all of its added faults, is at least the simpler option. It would be nice to have facilities GUIs enjoy that let me express simple concepts such as ’‘The interface must be at least this large.’’, though.
I find it depressing that hackers are still focusing on text-only interfaces rather than getting to a place where graphical interfaces are easy and pleasant to hack on.
A graphical interface is a superset of text interfaces. There is literally nothing that can be worse (e.g. just boot up xterm), but so many things can be better.
In principle I’m interested in that (as a user, not much of a developer). But somehow the kind of GUI stuff that appeals to me for similar reasons that terminal-mode stuff does ends up with much shorter half lives. Once you leave both the KDE/Gnome style of GUIs and the browser-as-a-frontend style of GUIs, almost everything else seems to be unmaintained or quickly on the way there. There’s old X11 stuff that’s interesting but rarely looks like it’s been touched in 10 years, and may or may not even compile anymore; likewise for some of the experiments built using imlib/imlib2 back when Enlightenment was more active. There are also some one-offs that get basic maintenance but don’t seem really active as a community; for example the unix port of plan9’s sam does compile and work.
The main exception afaict is window managers, where there is still quite a bit of active experimentation with alternative GUI paradigms. Though that’s kind of a weird “meta” level of GUI experimentation, the shell rather than the apps that go inside of it.
With great power comes great responsibility. The superior technical capabilities of a graphical interface allow you to make something better than in a textual interface for sure, but also much worse - and it’s always easier to make something worse. The constraints imposed by a TUI limit how awful an interface can be.
it’s just too difficult to do
This doesn’t make much sense, the console is just a GUI with significant limitations. I don’t see any benefit.
In fact I think that making ncurses style GUIs inside terminals is an abuse of the tool and we should stop doing that. They should be lower tech and only handle a sequence of lines. If we did this then scrolling wouldn’t break randomly in terminals.
Reading this I’m kinda amazed how we didn’t get a plethora of technically-terminal applications that behave like DOS games of the 90s :) Maybe because technically they’re using stuff that’s not only terminal, just a different kind of graphical mode. Framebuffer? But all the curses-like stuff is kinda rigid and TUIs are not so “creative” in their ways, they all kinda look samey and this might also limit what can be achieved.