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.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
