Hi NinjaCyborg and all!
Good point about MakeCX. So what would a 'CXRun' command look like that really works how you're thinking? Here's some ideas.
For GUI apps that aren't commodities, any of FKey, ToolManager or AmiDock (and probably some others) can give you a keyboard shortcut to launch them.
Good point! But CXRun would have a slightly different purpose and use case: once run using CXRun (maybe from FKey...), these non-commodity programs would appear "as" commodities, with entries in Exchange
"Show"/"Hide" would just (if possible) move their windows forward/backward and "Remove" would send them a CTRL+F and a "ICDMP_CLOSEWINDOW". (I think that nothing much else can be done? I don't think possible to really "hide" the window of a program not made for it...)
But the launching app has no way to keep some state about the app it launched - press the shortcut again and it will try to launch the app again, which may or may not do anything depending on whether the app allows more than instance of itself to run. And unless the app is itself a commodity then you don't have show/hide, pause/resume and exit commands to send to it. Even if it is a commodity, then it will likely have it's own keyboard shortcut, but a different one from the one used to launch it as the launching app doesn't know to yield the shortcut it's using!
So first of all, a smarter solution would let you assign the shortcut, and then it would upon launching the app, yield it's own hold on that shortcut combo, in anticipation of the app it launched reregistering the shortcut for itself. This actually means you can make a nice trick - it can wake up every 5 seconds say, attempt to re-register the same shortcut, and if it fails it knows the app is still running (or has crashed... I know it can't handle that scenario unfortunately), if it succeeds it knows the app has exit, and return to it's original mode.
This solves one issue for me that's always bothered me. I want the shortcuts for certain commodities to always be active, without having to load them all into memory. I have a similar issue which is that I want certain rexx ports to always be available, and the app that hosts them only run when the port is accessed lazy-loading style. Again, the service manager would need to register the port, and then yield it when addressed however in this case it would be destroyed and then reallocated, it couldn't simply be passed to the new host.
However if we're launching an app that isn't a commodity, we might only have options like sending a Ctrl-C signal or a fake Window Close IDCMP message like MakeCX does (and then we need to know process names or window names to know where to send it). Or, it might have a rexx port but then we need some way to tell our 'service manager' what commands to send, to what port, for show/hide,suspend/resume,exit etc. Actually application.library tries to do this and adds 'new document', 'open document' and other message types. But It needs the host app to support it itself (and it's OS4 only).
However, a init.d type scripting framework with shell scripts that contain the commands that need to be sent to control a given system could work. For each piece of software you want to control in this way you'd have a script with sections that say what to do - app1 is a commodity, named 'AppX', app2 has a rexxport call 'APP2HOST.1' and the command to exit is QUIT for example
Anyway these are just thoughts for fun.
For programs that have no window (and that are not commodities), e.g., AssignWedge, CXRun will again create an entry into Exchange: "Show"/"Hide" would do nothing (or be disabled entirely) and "Remove" would send them a CTRL+F.
So, any program that is not a commodity becomes "visible" as a commodity in Exchange and, as much as possible, controllable from Exchange
In a way, Exchange would become the "command center" of the Amiga, there would be no need to look at the list of processes/tasks anymore, to know what's running. It would also give greater control on these programs that have no windows/are not commodities.
What do you think?
Cheers!
