I generally agree but it depends on the application and the computer purpose / input you will most use.
Like… it doesn’t make much sense to have a CLI/TUI for an image editor… if you start using things like sixel you are essentially building a GUI that runs in a terminal, not a TUI. The same happens with videogames, video players and related entertainment applications.
But like I said, I do generally agree. I’d even argue that when possible, GUIs should just be frontends that ultimately just call the corresponding CLI programs with the appropriate parameters, avoiding duplication.
GUIs just being front-ends for a CLI tool is a horrible idea. This is why most git GUIs fail so terribly. I have seen too many of those where all the buttons were just replacements for CLI calls. If it is just a front-end for a CLI, then why the heck not just use the CLI?
A good git GUI has not been designed to just wrap the CLI. Instead, it works with the structure of git (commits, branches, tags, etc), and builds around those from the ground up. Only once the functionality has been designed should the question arise: What CLI commands do we need to implement this?
I generally agree but it depends on the application and the computer purpose / input you will most use.
Like… it doesn’t make much sense to have a CLI/TUI for an image editor… if you start using things like sixel you are essentially building a GUI that runs in a terminal, not a TUI. The same happens with videogames, video players and related entertainment applications.
But like I said, I do generally agree. I’d even argue that when possible, GUIs should just be frontends that ultimately just call the corresponding CLI programs with the appropriate parameters, avoiding duplication.
GUIs just being front-ends for a CLI tool is a horrible idea. This is why most git GUIs fail so terribly. I have seen too many of those where all the buttons were just replacements for CLI calls. If it is just a front-end for a CLI, then why the heck not just use the CLI?
A good git GUI has not been designed to just wrap the CLI. Instead, it works with the structure of git (commits, branches, tags, etc), and builds around those from the ground up. Only once the functionality has been designed should the question arise: What CLI commands do we need to implement this?