> Does the commit for bug #170550 help with this issue ?
I haven't tested this with a "native" build configured as osxapp (for packaging) since packaging is likely to change (for quartz-based builds anyway). The normal builds (not packaged as osxapp) behave like on linux. I expect the same for the bundled app (works like on linux).
The change in trunk maybe helps those who had been complaining in the past about Inkscape acting differently than native apps on OS X, but it does not (nor aim to) implement real OS X-native behavior (based on native toolkits/frameworks, and controlled by system or application-specific preferences settings): In the past, native applications which keep running after closing the last document window do not automatically open a new empty default document: they simply are kept alive, and can be accessed again by various ways (dock, app changer, etc). Whether or not they open a new document when regaining focus can often be set in the applications' preferences.
Current trunk might act closer to what native OS X apps used to do (<= Mac OS X 10.6), but won't adapt automagically to newer OS X releases: AFAICT Apple is changing the behavior with each newer version of OS X moving closer to the look&feel of iOS (iPad, iPhone). With the release of OS X 10.7 Lion they introduced for example 'Automatic Termination' as known from iOS to the desktop: Applications (e.g. Preview, TextEdit) initially may stay running after closing the last open document, but - if staying idle for an (undefined) period of time - quit silently, without further user interaction. Future versions of OS X may introduce more changes to the default behavior.
(Random) related links:
Apple developer documentation:
«Automatic and Sudden Termination of Apps Improve the User Experience
In OS X v10.7 and later, the use of the Quit command to terminate an app is diminished in favor of more user-centric techniques. Specifically, Cocoa supports two techniques that make the termination of an app transparent and fast:
° _Automatic termination_ eliminates the need for users to quit an app. Instead, the system manages app termination transparently behind the scenes, terminating apps that are not in use to reclaim needed resources such as memory.
° _Sudden termination_ allows the system to kill an app’s process immediately without waiting for it to perform any final actions. The system uses this technique to improve the speed of operations such as logging out of, restarting, or shutting down the computer.
Automatic termination and sudden termination are independent techniques, although both are designed to improve the user experience of app termination. Although Apple recommends that apps support both, an app can support one technique and not the other. Apps that support both techniques can be terminated by the system without the app being involved at all. On the other hand, if an app supports sudden termination but not automatic termination, then it must be sent a Quit event, which it needs to process without displaying any user interface dialogs.
Automatic termination transfers the job of managing processes from the user to the system, which is better equipped to handle the job. Users do not need to manage processes manually anyway. All they really need is to run apps and have those apps available when they need them. Automatic termination makes that possible while ensuring that system performance is not adversely affected.
Apps must opt in to both automatic termination and sudden termination and implement appropriate support for them. In both cases, the app must ensure that any user data is saved well before termination can happen. And because the user does not quit an autoterminable app, such an app should also save the state of its user interface using the built-in Cocoa support. Saving and restoring the interface state provides the user with a sense of continuity between app launches.»