[KDE/Mac] new year's resolution: opening files "the Mac way" (TM)

[Christoph Cullmann]

Hi,

> 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?
I can tell you that this needs to be done at the application level, not at kpart level.

E.g. in Kate, you would need to handle QFileOpenEvent just like a dbus request to open
a new file (atm I guess only the variant that has some url is feasible, the other variant
won't work with the current interfaces to the editor part we have).

Same for e.g. KWrite, just open a new windows with the file, like file open.

Greetings
Christoph

-- 
----------------------------- Dr.-Ing. Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234