new year's resolution: opening files "the Mac way" (TM)

[René J.V. Bertin]

Hi,

Best wishes for 2016!

As hinted in the subject, I've dusted off a resolution from last year: finding a way to support opening files "the Mac way".
Some of you probably know that OS X doesn't hand off the documents to be opened in the standard argc,argv way when an application is started through the Finder (LaunchServices in general). Rather, a specific event is sent that contains a reference to the file; this mechanism is the same whether the application is already started or not.

Qt has had an interface to the underlying mechanism since at least v4.6, but KDE never used it. I see that KF5 applications already set the NSPrincipalClass to NSApplication; that is a requirement, but not a sufficient one for the mechanism to work.

When the system receives the request to open a file, Qt will send an instance of a QFileOpenEvent to the QApplication instance, which will need to take action on it. This event contains the filename, but also a function that is capable of opening files that cannot simply be opened by name.

I think it should be possible to connect (the filename from) this event to a central mechanism that signals applications that a file should be opened. But I am not so sure if such a mechanism exists. I would assume that KDE applications have been designed for the kind of desktop shell that is used on Linux and MS Windows, in which the GUI for opening a document with a given application spawns a new instance of that application which receives the filename through the argc,argv interface.
It should be relatively easy to write a handler for QFileOpenEvents that just spawns a new copy of the running process, something like

 fork()
 execvp(argv[0], qFileOpenEvent->file())

and let the child process decide whether it should continue to exist as a separate application or hand off the argument(s) to the running KUniqueApplication instance. Drawbacks: in the first case the separate child process will open somewhere behind the parent process; in the latter case we'd be taking a detour (but there may not be a standard way in which KUniqueApplications hand off documents to be opened to the running instance?).

So what are the options here to hook into the QFileOpenEvent feature in such a way that applications need to as little modification as possible to deploy the new functionality? It's likely though that they'd require a dedicated Info.plist file.

If multiple solutions exist, I'd prefer those which are easiest to backport to KDE4 (for local patching).

Anyway, I'd be interested in beginning to work on a proof of concept implementation using Kate (hopefully in the kpart so that all applications building on the Kate editor can benefit). Or should I rather aim for KTextEditor or even KXmlGui? Anyone care to think along with me on this one?

Cheers,
René