I've always wondered why every application doesn't just have a shell console hanging off the bottom of the window, the way browsers do.
We've already had a half-assed version for decades, part of nearly every GUI ever (though they're falling out of fashion these days): "status bars." And most OSes also already have a "scripting" mechanism that requires applications to expose a specific "scriptable API" (WSScript requiring ActiveX components on Windows, Automator requiring Apple Events on macOS.)
So just combine the two! The OS could have a "status-bar control" that you'd stick onto your main window of your app, which would start as a regular status bar, but have a little disclosure arrow—that would turn it into a full historical log of every previous "status", plus a REPL for entering script (probably with a dropdown to select which of the OS's available "scriptable languages" you're writing in.)
If you don't want to muck up your GUI, you could simply detect whether your GUI app has been launched from an interactive terminal (i.e. whether stdin is a PTY) and then provide a regular REPL-like interface on the terminal. A lot of GUI apps already log to stdout in the expectation that developers will be running them from the terminal; why not just add some more interactivity the same way?
---
I should also mention a third, much less obvious route: Plan9's Acme editor, which isn't so much a "GUI editor" in the normal sense as it is a text buffer with a configurable space of API commands hanging off of it.
In Acme, the menu system (and its associated keyboard accelerators) are effectively just another text file that you can tab into and edit. Each thing you write into the menu is just a literal API call. Hitting that menu item will then call that API, passing the selection or the current buffer as necessary. [It's actually even more universal—in Acme, left-click selects and middle-click activates. You can write a command anywhere and then middle-click it. The menu just provides a convenient holding place for middle-click-able text.]
Acme has its own internal commands—sort of like Windows PowerShell—but it also allows you to just write regular shell commands into the menu as well. Activating a `wc -l` menu-command will literally just dump the output of `wc -l` into the status bar. Activating `tr A-Z a-z` will literally just tr(1) your selection/buffer into lowercase. Etc.
And I fudged a bit: the commands that are "internal" to Acme are just shell commands too. Since we're talking about Plan9, every process has its own environment, so Acme has a set of internal binaries that end up in its own /bin. These little "command" programs just use RPC to send commands to the current Acme instance. So the "scripting environment" here is literally the shell itself! (And you can "script" Acme from outside it, too, by mounting its command-binaries from wherever it keeps them, into your process's /bin dir.)
We've already had a half-assed version for decades, part of nearly every GUI ever (though they're falling out of fashion these days): "status bars." And most OSes also already have a "scripting" mechanism that requires applications to expose a specific "scriptable API" (WSScript requiring ActiveX components on Windows, Automator requiring Apple Events on macOS.)
So just combine the two! The OS could have a "status-bar control" that you'd stick onto your main window of your app, which would start as a regular status bar, but have a little disclosure arrow—that would turn it into a full historical log of every previous "status", plus a REPL for entering script (probably with a dropdown to select which of the OS's available "scriptable languages" you're writing in.)
If you don't want to muck up your GUI, you could simply detect whether your GUI app has been launched from an interactive terminal (i.e. whether stdin is a PTY) and then provide a regular REPL-like interface on the terminal. A lot of GUI apps already log to stdout in the expectation that developers will be running them from the terminal; why not just add some more interactivity the same way?
---
I should also mention a third, much less obvious route: Plan9's Acme editor, which isn't so much a "GUI editor" in the normal sense as it is a text buffer with a configurable space of API commands hanging off of it.
In Acme, the menu system (and its associated keyboard accelerators) are effectively just another text file that you can tab into and edit. Each thing you write into the menu is just a literal API call. Hitting that menu item will then call that API, passing the selection or the current buffer as necessary. [It's actually even more universal—in Acme, left-click selects and middle-click activates. You can write a command anywhere and then middle-click it. The menu just provides a convenient holding place for middle-click-able text.]
Acme has its own internal commands—sort of like Windows PowerShell—but it also allows you to just write regular shell commands into the menu as well. Activating a `wc -l` menu-command will literally just dump the output of `wc -l` into the status bar. Activating `tr A-Z a-z` will literally just tr(1) your selection/buffer into lowercase. Etc.
And I fudged a bit: the commands that are "internal" to Acme are just shell commands too. Since we're talking about Plan9, every process has its own environment, so Acme has a set of internal binaries that end up in its own /bin. These little "command" programs just use RPC to send commands to the current Acme instance. So the "scripting environment" here is literally the shell itself! (And you can "script" Acme from outside it, too, by mounting its command-binaries from wherever it keeps them, into your process's /bin dir.)