QtSingleApplication on OS X + Windows?

René J.V. Bertin rjvbertin at gmail.com
Wed Jan 20 22:22:56 UTC 2016


On Wednesday January 20 2016 22:06:14 Kevin Funk wrote:

> * Make KDevelopApplication inherit from QtSingleApplication on OS X + Win

Why not do this everywhere, and just make the DBus code optional? That should be possible, and it wouldn't oblige us to give up features requiring DBus on OS X (and MS Windows?) platforms where a DBus daemon is running anyway (MacPorts, Fink, ...).
Not requiring DBus is probably a boon for standalone app bundle builds, but the opposite for more traditional, "distribution" builds.

> * Get file-open event handling for free on both OS X + Windows

I'm not sure where you get that impression from: QtSingleApplication contains an alternative to the approach I use. It overrides QApplication::event(), but still catches QFileOpen events. The rest of the processing is different and simpler (though probably much more complex elsewhere ^^). OTOH, the patch I wrote for KDevelop is only as complex as it is because I want it to let files be opened through the Finder the same way that is done from the commandline: in a new or the single currently running session, or otherwise in the session picked from a list of open sessions. I don't think Qt Creator or Krita have that feature -- and I hope you're planning to preserve it?

NB: I am not sure exactly if a new (KDevelop) process is always created when you open a document in an application through the Finder, even without an explicit Info.plist indication that only 1 instance should be active at any time. I've had no reason to investigate this, but the behaviour I've observed suggests that no new process is launched. I don't think there is any guarantee which instance is activated when multiple instances of an application are running (but it does appear to be the first launched most of the time).
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?

R.


More information about the KDevelop-devel mailing list