Traditional coding is simple, you write the code, and execute it. To execute the file, a command shell is provided for that, and it is done.
For GUI, the simple concept is that a person write a piece of code, and execute it. What makes it complex is the callback/signal-slot/non-sequential coding methodology, which requires advanced C++ programming to conquer the UI solution.
However, it is not the end of the story. When the OS is to be interacting with the APP, things are a little bit more complex. And most out of it, “different OS” act differently.
For the windows, double click of a file indicating executing the binary in a different process, which means that you’ll get the second/third/fourth window. When the file is executed, (as long as I know from at least windows XP) the filename is sent to the process directly, which is simple.
For the mac, double click acts totally different. When the double click is activated, the request is sent directly to the “already opened” process, unless the app is executed from the command line with “open -na” option. Besides, the filename that you choose will be sent to the app by using the event. To access the filename, you need to create event reception personally to accomplish that.
Therefore, modifying the application for different OS requires multiple instantiation and different redirection approach.
To achieve single application for multiple filename sending request, the first priority is the ability to open many window for one application, and the second would be sending the filename from different process to the single process. For MAC, opening multiple window is enough for the single application request.
UI style is always a battle, and neither will win the war ~~ Unless another killer concept is proposed, and the traditional need is also taken into consideration.