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!