GUI apps in the CLI Database?

[vevy]

[Moderator note: this thread was split from the CLI Database Discussions thread.]

---

Is scrcpy really a CLI tool?

In a sense, it obviously is. You launch and control it through the terminal.

But one the other hand, it is really about visual/graphical interaction with your Android device. The CLI aspect is (almost entirely) merely a way to determine the parameters of this interaction (choose screen size, port, on-top or not, etc). But then, so many GUI apps provide some form of parameters/switches/arguments to set similar options/running conditions. For example, Chrome or Firefox (window size, profile, disable extensions, etc). I think nobody would suggest adding these to the CLI database (compared with Inkscape which allows you to perform functions like conversion though CLI commands without launching the main Window).

To determine which app it is (GUI with just parameters or GUI with CLI mode), a couple of general rules of thumb (and their variations) may help:

• Does it use standard output? i.e. does it produce text (e.g. file hash) in the console window to respond to your command. It can be silent but it won't use other methods.
• Does it have a tangible "product" in response to CLI commands? For example, conversion output file.
• Does it send the CLI commands to a GUI to be processed?
• Is it automatable? Can you put the command in a script and depend on it for the rest of the script. This is usually a test of the last three points.

I think there are grey areas:

• For example, gplay.exe is such a simple console player that it has no options or output or window or anything. It just plays the audio file you throw at it. But so does pretty much any other GUI media player if you do app.exe file.mp3. Does the lack of a GUI window alone make this a CLI tool in the sense above? It fails the other three points.
• If you say yes, automation is just one facet of CLI tools or that it does have a tangible product (the audio), then how about ffplay? I added it to the database because it comes with FFmpeg and is controllable from command line and outputs stats to the console (not exactly to stdout, but that is a tangent). When does the tool stop being a GUI with parameters and becomes a CLI? What is the difference between mpc-hc64.exe /volume N and ffplay.exe -volume N? Do we consider MPC-HC a CLI tool? ffplay also outputs a (GUI-controllable) window for both audio and video. Should we remove ffplay from the database? How about mplayer or mpv?

[SYSTEM]

I think there are grey areas:

• For example, gplay.exe is such a simple console player that it has no options or output or window or anything. It just plays the audio file you throw at it. But so does pretty much any other GUI media player if you do app.exe file.mp3. Does the lack of a GUI window alone make this a CLI tool in the sense above? It fails the other three points.
• If you say yes, automation is just one facet of CLI tools or that it does have a tangible product (the audio), then how about ffplay? I added it to the database because it comes with FFmpeg and is controllable from command line and outputs stats to the console (not exactly to stdout, but that is a tangent). When does the tool stop being a GUI with parameters and becomes a CLI? What is the difference between mpc-hc64.exe /volume N and ffplay.exe -volume N? Do we consider MPC-HC a CLI tool? ffplay also outputs a (GUI-controllable) window for both audio and video. Should we remove ffplay from the database? How about mplayer or mpv?

Myself I define "CLI" as anything that doesn't really count as a GUI program. This includes most programs you mentioned above, even ffplay (but not MPC-HC).

The difference for me is how the program is intended to be operated. With a CLI program you launch it, pass it command-line parameters, then it runs and eventually exits. (Okay, ffplay doesn't auto-exit, but its window is keyboard-controlled and hard to use without reading the manual first.) Whereas you launch a GUI program usually without any parameters, use the GUI to choose file to open if applicable, and eventually close it explicitly. They're very different modes of operation, and even ffplay unconditionally opening a window doesn't really bring it into the territory of GUI programs.

Quick question:

So apologies if I missed this in the discussion, but one of the CLI database entries (Git for Windows) https://cli.portablefreeware.com/index.php?id=4 is not portable by the standards of www.portablefreeware.com, as it writes to the userprofile directory. This is according to the entry, I haven't tested this. Are we listing non-portable CLI tools?

As this is actually the first example of a non-portable CLI tool that I've come across (excluding WSL which requires an install), I just wanted to check and see if everyone's on the same page about that.

I'd be fine with listing non-portable CLI tools. I myself created the Git for Windows entry.

GfW has an official "portable" version, but in practice it stores most settings in the user profile directory. I was using it heavily in my previous job (but not the current one because my current employer uses Subversion instead of Git).

[vevy]

Some good questions raised there around CLI vs. GUI and you're right that there's some overlap. For the site's purposes, some people are always going to be reluctant to touch anything that requires a command prompt. scrcpy is definitely right at the edge of the dilema.

Some people are always going to be reluctant to touch anything that requires a command prompt.

My thoughts, precisely.

I agree, but I am not necessarily suggesting we add it to the main database instead. Let's pretend that it doesn't exist for a second.

I am mainly concerned with: Should we add it (and the other examples) to CLI database or not?

[vevy]

Myself I define "CLI" as anything that doesn't really count as a GUI program. This includes most programs you mentioned above, even ffplay (but not MPC-HC).

The difference for me is how the program is intended to be operated. With a CLI program you launch it, pass it command-line parameters, then it runs and eventually exits. (Okay, ffplay doesn't auto-exit, but its window is keyboard-controlled and hard to use without reading the manual first.) Whereas you launch a GUI program usually without any parameters, use the GUI to choose file to open if applicable, and eventually close it explicitly. They're very different modes of operation, and even ffplay unconditionally opening a window doesn't really bring it into the territory of GUI programs.

Interesting. What I take from this is:

• CLI by exclusion.
• The mode of usage: GUI/commands.

What about the following?:

• GUI with CLI mode, like Inkscape. It can have all the features of a GUI program while having a CLI mode in addition.
• mpv opens a window with OSD controls.
• MPC-HC can be made (even just with parameters) to behave similarly to mpv: minimal window, close on finishing, etc. Why not include it? It 's primarily a GUI app but see point 1.

Some thoughts:

• It is true that media playback is a bit of a special case due to its nature (you can't satisfy the program function with just text or file output).
• Similarly, something like a simple GUI image viewer wouldn't be really different from a simple CLI one.
• The mode of operation/usage thing does help though.
• Is there escaping making a subjective decision when deciding which to add to the CLI database? Can we do it in a consistent way?

... because my current employer uses Subversion...

Why can't people just be honest? smh

[SYSTEM]

Interesting. What I take from this is:

• CLI by exclusion.
• The mode of usage: GUI/commands.

Yeah, that's pretty much how I'd define it.

• GUI with CLI mode, like Inkscape. It can have all the features of a GUI program while having a CLI mode in addition.
• MPC-HC can be made (even just with parameters) to behave similarly to mpv: minimal window, close on finishing, etc. Why not include it? It 's primarily a GUI app but see point 1.

They still have a GUI and are primarily designed to be used with it, so I don't count them as CLI programs.

mpv opens a window with OSD controls.

It still auto-exits unless you pass --idle=yes and isn't really be intended to be used with the OSD controls alone.

... because my current employer uses Subversion...

Why can't people just be honest? smh

I have no idea what you're talking about here.

For the record, SVN is still popular in game development because games contain gigabytes worth of binary assets (the repo of the game I'm working on is 3,3 GB and it's still missing ~1,6 GB worth of assets I'll need to upload in the future), and distributed version control systems such as Git are terrible dealing with them: you end up essentially storing a copy of every version of every asset which has ever existed on the computer of every developer. Centralized VCSs such as SVN and Perforce are better options for gamedev.

[vevy]

They still have a GUI and are primarily designed to be used with it, so I don't count them as CLI programs.

True. But remember that we are discussing this more for the purposes of inclusion in the CLI database. See here and following posts. They can be fully used as CLI tools. If I am trying to find a tool to convert an SVG file to raster, I want to know that Inkscape is a fully-valid, scriptable option for me so I may not need to find another tool.

... because my current employer uses Subversion...

Why can't people just be honest? smh

I have no idea what you're talking about here.

For the record, SVN is still popular in game development because games contain gigabytes worth of binary assets (the repo of the game I'm working on is 3,3 GB and it's still missing ~1,6 GB worth of assets I'll need to upload in the future), and distributed version control systems such as Git are terrible dealing with them: you end up essentially storing a copy of every version of every asset which has ever existed on the computer of every developer. Centralized VCSs such as SVN and Perforce are better options for gamedev.

It was meant as a joke!
But thanks for the insight!

[SYSTEM]

It was meant as a joke!
But thanks for the insight!

Ah, sorry. I'm a non-native English speaker and the other meaning of the word didn't even come to my mind.

[vevy]

That's alright. I was just being silly!

So, for the purposes of inclusion of media playback tools, at least satisfy one of these:

• It doesn't have a GUI. Example: gplay.
• It can't be fully launched and used using only GUI (i.e. still needs CLI commands) even if if has convenience GUI playback controls. Example: mplayer, ffplay.
• It has CLI commands that are more than just parameters for playback (e.g. conversion). Example, VLC.

MPC-HC doesn't satisfy #1 (has a GUI), #2 (can be used fully though GUI) or #3 (command line switches have no independent/scriptable function; only parameters).

ffplay has a lot of keyboard controls, but you can't drag-and-drop another file on the window or go to a specific time through the "GUI", so it satisfies #2.

Does this seem right to you?


-------------------

Also, any suggestions for a word to describe one-tool packages, people?

[SYSTEM]

Does this seem right to you?

Ultimately it's up to you. I wouldn't include VLC in the CLI database, but I'm not stopping you if you want to add it.

[vevy]

Does this seem right to you?

Ultimately it's up to you. I wouldn't include VLC in the CLI database, but I'm not stopping you if you want to add it.

Even though it can convert files from the command line and thus can be used as a replacement for ffmpeg for example?

I understand that a lot of things are subjective, but I try to discuss, and maybe I can learn something or show something so that more people can reach more reasonable and agreeable decisions. For example, the last few posts!

[SYSTEM]

Ultimately it's up to you. I wouldn't include VLC in the CLI database, but I'm not stopping you if you want to add it.

Even though it can convert files from the command line and thus can be used as a replacement for ffmpeg for example?

Yes, because it, uh, is a GUI program. "CLI by exclusion" as you put it.

[vevy]

Ultimately it's up to you. I wouldn't include VLC in the CLI database, but I'm not stopping you if you want to add it.

Even though it can convert files from the command line and thus can be used as a replacement for ffmpeg for example?

Yes, because it, uh, is a GUI program. "CLI by exclusion" as you put it.

But by that logic, you'd exclude many very useful tools like HandBrake, IfanView, Inkscape, SubtitleEdit, etc, that provide very useful, superior or even unique functions through their CLI mode.

They would clearly be marked as dual GUI+CLI tools. Again, this is not from a strict classification standpoint, but from a CLI user's perspective.

If you are browsing/searching the CLI database for a tool for your script, wouldn't you want to know all the tools can fulfill the job, especially the mature/popular ones?

Like, what would the harm of adding them be, if they are clearly marked?

[vevy]

Think of it as listing the CLI mode of the app rather than the app itself.

[SYSTEM]

But by that logic, you'd exclude many very useful tools like HandBrake, IfanView, Inkscape, SubtitleEdit, etc, that provide very useful, superior or even unique functions through their CLI mode.

They would clearly be marked as dual GUI+CLI tools. Again, this is not from a strict classification standpoint, but from a CLI user's perspective.

If you are browsing/searching the CLI database for a tool for your script, wouldn't you want to know all the tools can fulfill the job, especially the mature/popular ones?

Like, what would the harm of adding them be, if they are clearly marked?

I think programs like HandBrake and Inkscape would look quite out-of-place in a CLI program database. I see your point, though.

At this point I'd like to hear opinions from other people...

[vevy]

Forgot to ask you. What would you make of scrcpy?

----------------------------------
Chocolatey calls them packages. I think I am going to go with "Win package" or so, reserve "Collection" for the likes of GnuWin.