What really is the difference between a Console app (has a Run method that just runs through) and a Desktop app, where all that is done is Open->New Document->[perform some functions]->then quit?
Don’t assume I’m doing anythign complex, I’m not. It’s just an app meant to do some work without user-intervention then quit.
I built both, and although there’s a different runtime, it seems to work the same.
The header of the app file has a different flag.
And the OS treats them differently.
That’s internally, but on the outside, from the users perspective, is there any downside from using one or the other? Do they behave the same?
the console app can run as system service without a GUI, so without an user logged in to his desktop.
A console application has built-in functionality for obtaining command line options, you need to use declares to get the same functionality from a GUI application.
A GUI application is bigger as it needs functionality for generating and displaying GUI elements, which a console application doesn’t, so this will make a console application faster to launch and use less memory.
By default a GUI application will show in the Dock, albeit this can be turned off by modifying the plist or declares.
A console application launches and fires the run event, once that’s complete it exits. A GUI application will fire an open event, but will remain open until told to exit.
By default you can only launch one instance of a GUI application, but many instances of a console application. With the right declares you can work around this.
Lastly, it’s possible to fork a GUI application, passing in the optional parameters that will make it behave like a console application, so in theory you can do it all from a single project. This does mean that you’ll be loading the application more than once and therefore it will have to load all of the functionality each time, even if your console application only uses 1/10th of the functions.
For the interested:
system.commandLine
Contains the arguments/parameters in a Desktop Application.
http://documentation.xojo.com/api/os/system.html#system-commandline
Lol, I never thought to look into the System module for launch commands, so I wrote out the declares! ha aha ha
A console app allows you to use the stdin, stdout and stderr I/O to be run as part of a succession of processes, where one passes data to the next in the list to be executed. Often sys admins use console apps in this context as utilities. This allows them to mix and match utilities in batch files to create customised data processing jobs. So you can write apps in Xojo that fit into the rest of the Gnu world on Linux. Desktop apps are fairly useless at batch processing.
In other words, Xojo Cosole edition lets you write utility programs.
I may be wrong, but when I checked yesterday evening Xojo prices, I do not found a Console version price.
Last I knew, console was not offered stand alone (though if I mismember, once upon a time it was?)
It does get included with Pro and Pro Plus. But it does not seem as likely for anyone to want ONLY a console license, so unless it was priced cheap spending $299 for a Desktop and another $299 for Console, just spending $699 to get Pro seems like a much better bargain.
One of the things console apps are great for is “helper apps” in lieu of pre-emptive multi-thread support. Whether roadmap’s “Multicore” functionality makes it possible for a single Desktop license to automagically create and spawn console helper apps remains to be seen. Currently #4 on the Roadmap as of this writing.
Or from a macOS command line or from a Desktop app Shell class, execute:
open -na “[appname]”
You must quote (or at least escape) an app name with embedded spaces, and need to provide a path if not in /Applications or otherwise in the environment path.