[KDE/Mac] towards further integration on OS X; accepting arguments through LaunchServices

[Mario Fux]

Am Donnerstag, 04. September 2014, 10.33:42 schrieb René J.V. Bertin:
> 'Morning!

Morning René

I just keep this answer on kde-mac for the moment.

> Sit back for what's become a long message, with a rather bold and shameless
> plug for what's not even 100% my own software at the end :)
> 
> I'm sure I'm not the only one who keeps forgetting that the current way KDE
> (and Qt?) applications are bundled (sic) on OS X makes that you can pass
> them arguments via the commandline, but not open documents with/in them
> through the Finder. Or, set them (=kmail) as the default email reader.
> 
> This is because of 2 things. First, LaunchServices needs an Info.plist
> inside the app bundle that tells it what kind of documents an application
> can handle (it's possible to put a wildcard in there, at least to some
> extent). Second, the application needs modifications: a handler for things
> like telling the OS that it can do "URIs", and above all, code to extract
> the document file names to be opened.
> 
> On modern OS X (and probably all previous versions though I seem to recall
> differently) the only *argv[] argument passed on to the main function is
> something like a session identifier (unless you use `open -a appName
> --args <arglist>` from a shell). The documents to handle that the user
> dropped on the app icon (or any of the other supported methods) are passed
> in the event loop, via messages to the main document class
> 
> Nice and elegant, but cumbersome to convert to a standard *argv[] list to
> be passed to main. I've already done some tweaking on an application
> that's native on Mac and MSWindows and one has to come up with an ObjC
> module that collects all those "arguments", and then relaunches the
> application (or calls main recursively). I think I've come across
> something like that in Qt's internals but cannot recall if that was in Qt4
> or Qt5 ... and clearly it isn't exploited in current KDE applications.
> 
> The alternative is to use a wrapper, which is less cumbersome as it sounds
> given how the actual binary executable is hidden away inside an appbundle
> anyway. For launching from a commandline, it makes little difference
> whether you type (say) .../kate.app/Contents/MacOS/kate or
> .../kate.app/Contents/Resources/kate . Long story short, I've recently
> started extending an old utility some of you may remember: DropScript. Its
> initial mission was to provide a drag-and-drop conversion for shell
> scripts into application bundles, using a rather nifty self-replication
> approach. I've modified this to handle binary executables, Finder aliases
> and app bundles as well (allowing to work around an annoying OS X 10.9
> "feature" that causes any number of my various disk images containing
> little used applications to be mounted at random logins). I've spent some
> time very early this morning to confirm that this same utility (at least
> its own binary, the wrapper) can be used to create KDE appbundles that
> integrate better with the OS X desktop. Dragging the KDE executable (say,
> kate.app/Contents/MacOS/kate) onto DropScript.app creates another kate.app
> bundle (currently without the icon of course) that will launch kate as
> expected, but open documents dropped onto it in kate. Same for `open -a
> kate.app foo` but also if you pass those documents directly to that new
> app bundle's kate.app/Content/MacOS/kate (in other words, no need to
> target the executable in Contents/Resources). It seems you can even do
> `open -a kate.app "http://www.kde.org"` and get the site's html code in a
> kate window. Or, if you create a similar kmail.app wrapper bundle, `open
> -a kmail.app "mailto:kde-mac at kde.org"` will give you a new message window
> (when kmail is already running, but it's already a big step from the
> current situation).

Sounds really great. Thx! Is this based on Kate based on KF5? I think this is 
a bigger change (a very positive one) and should be used on the KF5 based Kate 
as it's just cumbersome to first integrate it in the old Kate (based on 
kdelibs4) and in some months to port it over.

I understand it that there are and should be fixes for kdelibs4 and kdelisb4 
based KDE applications but never forget to port them _always_ to the new KF5 
and KF5 based apps otherwise they will be forgotten and great work and effort 
is lost.

> This is the lil thingy: https://github.com/RJVB/DropScript
> 
> I had already thought of creating and submitting a MacPorts port for
> DropScript but there might be interest from the KDE community to
> incorporate a (modified) version into the build system. The only issue
> here would be about the licensing legalese lalala ... Neither of the 3
> authors preceding (and including...) me saw any need to add such blurbs
> (or it got lost in the process) and I don't think we can just put one in
> without contacting them ... which might be a challenge. Or maybe a generic
> BSD license which seems appropriate if you look at the comments and
> Apple's own ecosystem but maybe that would clash with KDE requirements?

IANAL but if the code doesn't have a license yet then it's proprietary (that's 
a big weakness of github => not to enforce a license) and useless for KDE (or 
other free software projects). But you can "relicense" it and ask all the 
involved people for agreement. BSD would work for KDE IIRC but as soon as you 
plan to "relicense" it we can find some people that know license stuff better 
than me.

> Anyway, enjoy! :)
> 
> R.

Thanks for your work
Mario