May be a silly question, but why cannot a console program bring up a window, and then continue when the window is closed? I have checked, for example, GTK, and it is required to run main() through the GTK startup.
What you are are asking to do, can be done.
First of all, there is no real distinction between a GUI and a console program.
All programs start out as console programs.
A GUI program is one that attaches to the Photon kernel and then processes messages photon messages.
If you really want to try, take a look at the source abmain.c that PhAB creates.
Having said that, I can’t think of any reason do this. You can get the same effect by
starting your “console” program, spawning the GUI program and waiting for it to exit,
and then continuing.
Thanks for the info. Spawn is an expensive way to bring up a window, and the address space of the spawned program is lost when the spawned program completes. I guess the GUI systems are easier to design with the “big brother” approach – everything in the process happens through the event/response mechanism that underpins the GUI system architecture. I have no experience in designing GUI systems, but I would think it would be natural to encapsulate it to the extent that it would be callable/creatable from a user-controlled main() function. I suspect there is a trade-off, there, that I am not aware of.
Expensive in what terms? Are you starting and stopping windows multiple times a second? Are you concerned about wear and tear on your hard drive? While your statement is true, it seems like a very strange way to look at a GUI program.
Nothing in Photon prevents you from starting a program that creates a window, removes it, and then starts another window, over and over again. This may not be obvious if you’ve only created a program using PhAB, although PhAB doesn’t prevent you from doing this either.
I don’t think it’s a matter of “easier to design”. GUI programs are by their nature event driven. The main events they are waiting on are user interaction. It’s rather easy in QNX to get around this. Whenever you want something done in a Photon program, you can just send it a message. You can also do things periodically with a timer. If that isn’t good enough, you can start a thread at initialization time that does not wait on Photon events.
Are you talking about a GUI system or a GUI program? What you just stated does describe a QNX Photon program. If you want to see the main(), look in the source for abmain.c. It’s hidden there out of convenience, not malice. If you are willing to live without the convenience of PhAB, you can write a Photon program where you are in complete control of the main() and the event drive mechanism, it just takes a little more work.
You are right about the windowing. My mistake for overlooking this.
Thank you for pointing it out!
QNX seems to recommend to keep the GUI separate from the “main program”, and exchange data using their publish/subscribe service (PPS). The reasoning behind this probably is that you could use e.g. Qt to create your GUI and do this on Windows using QtCreator, and even run the GUI on Windows, and then compile it for QNX. Not sure how good that works in practice, though.