The standard input and output have no use on most GUI applications.
I have found, however, an application that makes use of the standard input for the user to type commands: gnubg, GNU's backgammon game.

Here's a sample video. On the video, I first type "new game" to start a new game, then "roll" to roll the dice, "help" to get a dialog window listing known commands, and "move" to move the tokens. Then, I type ^D (Control+D) to send EOF and close the game.

Here's the video.

This command-based interface is not available when the user opens gnubg(1) from the application menu/start menu, only when the stdin is connected to a terminal.

However, the commands are fundamental to the game operations: menu entries and the icons on the toolbar are bound to commands (clicking in one of them has the same effect as entering a command on stdin). You can also run a game from a script either by pipeing it to the stdin; or by running gnubg(1) with the -c option; or from the menu bar on File/Open Commands.

I found that interface really interesting, because it can be extended and composed with other applications. The user can run gnubg(1) from a script and call dmenu to run commands from it and/or get a list of commands within dmenu (mimicking HUD on the Unity DE from Ubuntu).

MacOS' global menu bar can also be mimicked. We can have a global menu bar in which clicking on a option on the menu bar sends commands to the stdin of the process of the active window.

This kind of interface: a regular user interface that also interprets command is nothing new on TUI (aka roguelike interfaces): Vim and emacs have a command-line interpreter at the bottom of their windows. Ranger, lf and other file managers can also interpret commands while also being controlled by usual keybindings.

With this kind of interface we can bind commands to menu entries, icons, and hotkeys with separate programs like dmenu and sxhkd.

Something like a command-line interface is being implemented in QT5 applications for KDE. The user can enter commands in a dmenu-like prompt, those commands are interpreted by the toolkit, which will run the corresponding action for the application.

That kind of GUI interface, so unexplored, influenced me in projecting two different, but related applications: control and xfiles. Xfiles will be a GUI file manager that reads commands from the stdin. Control will have server and client processes. The server is a macOS-like bar with global menu that changes its menus based on the current active window. The client is a wrapper; calling "control xfiles" will open xfiles with its stdin bound to control, allowing the user to control xfiles (ie., send commands to its stdin) from the global menu bar. Control will know which process stdin corresponds to which window by means of startup notification.

Control and xfiles are still in my mind, and will be there for a long time, as I do not have time to work on them (my uni is returning next semester).

What do you think of a command-line interface (CLI) for GUI applications?
And what do you think in implementing CLI in GUI by means of the standard interface (as gnubg does)?
Are CLI and GUI unrelated or can they be used together?
What do you think of KDE way of implementing CLI in GUI by means of the QT toolkit?
What solution is better: including CLI in GUI via stdin or via toolkit?

I think that implementing CLI in GUI, while not caring about implementing menu bars, toolbars and keybindings in the application, is the UNIXy way of GUI interfaces: let the actual interface to be done by other programs (dmenu, sxhkd, macos-like global menu, etc), concentrate only on interpreting a little language and separate the interface from the engine.

That's a nice idea, it reminds me of applications that know when they're started in a pipeline and change their interface accordingly.

The CLI for GUI, as in taking stdin for user-interaction, is a much simpler way to create a client/server architecture. I'm not sure how it'd be implemented in practice, I would guess there's a thread running that keeps the stdin fd open and triggers the gui/main thread to take action.
When you think of it like that it shouldn't be hard to replace any sort of client protocol of choice with stdin, making this the client's choice.

I can't help (because it's fresh in my mind) to make the link with gstreamer's plugins. You can choose from a gigantic array of different sources and sinks (input/output) and link them together, including the pipeline. For videos, I've also discovered constatus.

(24-06-2021, 08:12 PM)phillbush Wrote: What solution is better: including CLI in GUI via stdin or via toolkit?

That would partly solve it if we would have a standard wrapper around different protocols that would convert them to stdin or file descriptors in general. The issue would be with GUI's that are opaque and can only be controlled through graphical interactions.
The classic "adding glue" à la Unix.

You could even add in the pipeline, these interactive selectors you've been talking about lately.

(24-06-2021, 08:12 PM)phillbush Wrote: I think that implementing CLI in GUI, while not caring about implementing menu bars, toolbars and keybindings in the application

I like the menubar part, that would allow adding global search in the application menu like macOS does, which is a feature I'd love to have. It would also make introspection/discoverability much easier, basically adding a method to list the standard operation an application allows, at least in its menu.

I think it's a great idea, at least out-of-the-box thinking. Meanwhile, I'm looking to check if it's something plan9 already does, because it sounds like it should have!

In my opinion, a GUI should never be more than a number of knobs to control the underlying CLI application - or library, of course. Not only would that allow severe upgrades of the underlying code without having to release a new GUI all the time, it also makes no sense to restrict the CLI to what a GUI can do (most notably, piping).

(24-06-2021, 08:12 PM)phillbush Wrote: The standard input and output have no use on most GUI applications.
What do you think of a command-line interface (CLI) for GUI applications?
Are CLI and GUI unrelated or can they be used together?

Reminds me of the commandline on the old AutoCAD, circa 2000. There was an input field at the bottom that would take commands that complemented manipulations in the drawing canvas.

And then there's the console context switching, like in Quake (and probably a long list of other games) that took commands and parameters.

Adding a CLI is one approach to stuff in extra functionality that is hard to showcase, or somehow gets in the way in the graphical view.

[ interface rant / wishlist ]
A well executed interface ought to provide:

• a framework to orient the user
  
• discoverability
  
• reliable and consistent view
  
• relevant context for current task
  
• user feedback on actions (and application state)
  

(30-06-2021, 06:21 AM)dionys Wrote: And then there's the console context switching, like in Quake (and probably a long list of other games) that took commands and parameters.

GIMP somehow fits that description too, allowing command-line scripting. But from my personal experience with it, the internal documentation (Help > Procedure Browser) is often out-of-date and running it as a standalone command line tool requires overriding some environment variables to start "fresh" in the current directory.
But at least that yet another interface to integrate with command line tools if necessary.