QtSingleApplication on OS X + Windows?

[René J.V. Bertin]

On Thursday January 21 2016 00:27:48 Kevin Funk wrote:

> Right, indeed, it's not "either or". For OS X it still might sense to make use 
> of an existing DBus session. I just wouldn't like KDevelop to start a dbus-
> daemon on its own, like it currently does on Windows.
> 
> I'm sure that's possible.

Should be...

> If we have a DBus session available on OS X, then you can still use parts of 
> your patch to implement the desired behavior, no? QtSingleApplication 
> basically gives you a fileName which was requested; you could then still 
> decide whether to open in a new or existing session.

QtSingleApplication as used in Qt Creator takes the filename from a QFileOpenEvent and puts it into a Qt signal. It seems a bit of a detour to feed that signal into a DBus call then, but yeah, it should be possible.

> From what I read about QFileOpenEvent I think no new process is launched 
> either. It's just that the existing process gets an event.

That wouldn't be in the QFileOpenEvent documentation, because it's a separate problem that's already been sorted out once that Qt event is created. 
Document-centric OS X applications can be very simple to code: they define an NSDocument class in their Info.plist that corresponds to the document they can edit, and that class will have the equivalent of a ctor that initialises a new instance from a file. As long as you set the principal class to NSApplication, there is a priori nothing you need to bother with concerning the traditional handling of arguments, filenames etc. from the commandline. 
Applications that use another approach, for instance that want to build a list of all documents that should be opened at launch can provide an application delegate which responds to the application:openFile: message. It is undoubtedly what Qt does to create and send the QFileOpenEvents

But in no way does this say anything about who gets the application:openFile: message when multiple instances are running. That is under user control (or software control, supposing Qt ever gets an interface to LaunchServices) to a certain extent, but the application itself isn't supposed to be concerned with it.

> I've tested QtCreator on Windows; there only the first launched QtC session 
> handles file open requests (which is, as you noted, cumbersome...).

And Qt Creator doesn't even have such an elaborate session picker.
I'm surprised though: the QFileOpenEvent documentation claims it is supported on OS X only (or OS X and Symbian for Qt 4.8).
Either way, files to be opened at startup are passed through the regular argv[] on MS Windows, no?

> > If true, that means the application must always be ready to
> > hand off a FileOpen request to another running session -- can that be done
> > without DBus?
> 
> Probably not easily.

I've already tried to replace part of the functionality provided by kwalletd via a Qt shared memory class; not trivial at all. But I presume other IPC classes must exist in Qt that would fit the bill.
Alternatively someone could hire me to make KDevelop AppleScript'able =)

> Note: I currently still favor porting towards QtSingleApplication.

The one doesn't exclude the other I presume.
Is QtSingleApplication to be included in 5.6?

R.