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.