[KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J.V. Bertin]

On Thursday October 15 2015 09:14:42 Christoph Cullmann wrote:

>> KDE and its Frameworks and KF5 successors EMBRACE file-sharing between
>> applications, utilities and libraries.
>Actually, I here already disagree.

Hmmm?

>At least some KDE application developers like me or the Krita team want is to have self contained installers/bundles,
>as that is the normal way to go there.

Not *the* normal way, *a* normal way, for applications where this makes sense. Bigger and more complex *suites* of applications more often than not use some kind of installer to put the various things in their respective places.
Xcode itself came that way, until Apple in their infinite loopdom decided to ship it via the App Store. The result is a humongous bundle that contains everything the dev community as a whole might ever nee (until "that time of year" when 10.n+1 rears its increasingly ugly head). Have a look at its size and also note the true size (a priori the thing is compressed with HFS+ compression).

Shipping something like the Calligra suite as a self-contained app bundle (a la OpenOffice ... which still used an installer last time I bothered) may be possible, and would most likely solve any sandboxing issues in IPC that are bound to arise when following App Store rules. It will be very complex to get right (for a probably brittle result) if none of shared locations are to be specified in relative terms so that the app bundle can be moved around freely. (BTW Ian, that is probably why QSP doesn't return locations pointing into an app bundle's resources directory!)

BTW, Ian and I come at this with the goal of being productive *using* KDE, not *on* KDE (exclusively). That's included in what I meant with pragmatism in a previous message.
In addition, I have always considered it a self-evidence that you start out a porting effort by keeping everything the same as much as possible (shared locations, in this case) and focus on what has to be changed ("native" instead of X11/xcb APIs). That would have allowed to publish KF5 applications via MacPorts and family, driving community interest, and possibly attracting experienced OS X developers to help out making things "more native" (that's how I got hooked: I rewrote the OS X Keychain "backend" for KWallet almost entirely). Progress might have been slower, but surely surer, and less disruptive for users.
As to that last bit: I'd have approached the whole KDE4->KF5 evolution as KDE4->KDE5->KF5 (i.e. port kdelibs and family to Qt5, and only then start thinking of blowing things into individual bits and pieces) but that's a topic for another thread.


>I understand that for KDE 4 it was necessary to treat Mac just like a other kind of
>BSD, but I think for frameworks we shall aim to make them usable for people wanting to

OS X *is* just another (and very weird) kind of BSD...

>http://kate-editor.org/2015/10/14/kate-on-mac-hidpi/

Quoting Ari: "Sorry, Kate"

>You need nothing to work on Kate beside XCode, Qt + CMake (and yeah, gettext).

Kate is cute and all, but as a standalone editor I don't see anything it has over, say, TextWrangler or its commercial big brother BBEdit.
Except for the fact it can work as a "kpart", providing the editor component for a.o. KDevelop. But can it, in its "nativised" KF5/Mac version? I still have seen no answer to that question.

>Nothing else above what is shipped with a normal Mac.

As opposed to a senile Mac? Please weigh your words a bit more..

>and that I need to install the icons in the right locations.

Define right?

>And yes, without any black magic

What, no more C++? Now that would be a commendable goal! O:-)

>We wanted to make them attractive for non-KDE applications & developers.
>For Windows & Mac that means for me, they must be usable with stock Qt and without any
>non-os native requirements ;=)

I've never said that couldn't be an ultimate goal, just that it shouldn't be the 1st goal to pursue on those platforms. Pursue too many goals at once, and you can just as well start rewriting something new from scrap (like Apple did with AVFoundation, abandoning manyears worth of dependent software).

Using Qt is already a non-native requirement no matter how you want to turn it. It contains iffy  mechanism like "oh, this QAction has a translated title that contains the word configure, let's make it the Preferences menu item in the Application menu" (did KStandardActions survive, btw?). Qt4 never managed completely to prevent conflicts between C++ and ObjC object management (leading to events being delivered to deleted objects, for some reason only in KDE applications) and I'm not aware anything has changed in that aspect (mechanism like ARC might even acerbate the phenomenon).
Qt is admirable at what it accomplishes (not so much on 10.11 though), but if you really want to do things natively you'll want to embrace the ObjC/Cocoa APIs and SDKs. 
So yeah, set a goal to make KDE native and I might even get involved with its development supposing I'm still using OS X by then.

R.