[KDE/Mac] Developing KDE on Mac

[Sjors Gielen]

Op 13 aug 2010, om 14:46 heeft Mike McQuaid het volgende geschreven:

> When doesn't it make sense to share patches upstream? If Fink and Macports are sharing them and you don't recommend people install from source these patches should all be upstream.

Because some patches only make sense on Mac. Yes, you can #ifdef stuff, but there are patches that simply don't make sense upstream, like fixes for the build system that would break the build system on other operating systems.

> I agree with Fink/Macports being better for most developers. Most people don't install all their dependencies from scratch on Linux either but people do install Qt and KDE and, currently, this isn't possible on OSX without patches which are in Fink or Macports. This is a bad situation. I don't think the solution is sharing patches, I think it is for Fink/Macports to try and be a bit more responsible open-source citizens: actually push patches back upstream. Yes, it takes effort but that's kind of the point of open-source.
> 
> I'm trying hard to push the launchd patches upstream to D-Bus but it's a huge pain and it's taking time. However, though, it will be worth it as it means we get closer to the situation of sensible binary distribution. More on that later.

I think it also often happens that patches *are* pushed upstream, but simply not merged. This is, I think, also the case with the 10.6 crash that has long been fixed, but not merged upstream (if I remember correctly). I've CC'd the KDE maintainer in Fink. Benjamin, do you know more details about this?

>> One thing that has been crossing my mind since aKademy is a KDE on Mac installer. The Windows dudes have done this and it's been working out great - but they don't have a package manager and we do. I've been thinking about creating an installer that, after some basic system checks and asking the user what he wants, installs Fink or MacPorts, configures that, then proceeds to tell the package manager to install KDE. It could become a KDE-oriented "front-end" to Fink and MacPorts, also alerting the user of updates now and then.
> 
> This is exactly what I'm trying to avoid. On Windows their "installer" is a package manager that they wrote from scratch. If we want KDE on Mac (or indeed KDE on Windows, quite frankly) to ever catch on with non-technical and non-Linux users who have to use Mac/Windows on occasion, then we need to start bundling our software the way people expect it to be distributed.
> 
> Fink/Macports/Homebrew are great tools. However, no non-developers I know that use a Mac use them. Hell, most developers on OSX who aren't doing open-source development don't even use them.
> 
> What our end-goal should be is a nice DMG with a PKG or droppable .app file with autoupdate support and all the trimmings people expect. On Windows, in my opinion, it should be a MSI or NSIS installer that doesn't force the user to worry about dependencies.
> 
> I think a reasonable intermediate step would be to have a DMG which installed the basic dependencies for KDE applications (e.g. D-Bus, Qt, KDELibs, KDESupport) and then .app bundles for individual applications.
> 
> I did a talk on using CPack to do this at Akademy the year before last. I really think this is something that we should seek to do a) as a group/team and b) properly rather than just the easiest way possible.

This is exactly what I've been thinking about, but think about this: (this information might not be 100% correct, please correct me if I'm wrong somewhere.)

1. Large libraries like Qt are often shipped in Frameworks, 'bundles' of the shared library files, resources, metadata et cetera. You build an application against a specific version of a Framework and from that moment on, that version of the Framework (and the path to it) is hardcoded in the binary, so you need to keep that version available. If you update the Framework to a newer version, the old version is kept around for those already-compiled applications.
Shipping KDE in a Framework is very hard at the moment. Most important problem: KDE has several daemons running at the same time, like kinit, kwallet and knotify. These binaries, as far as I know, can't be shipped along with a Framework, and therefore have to be installed seperately. Then, all various installed versions of KDE, which might range from KDE 4.0 to 4.5, must work with the installed binaries, or you would have to run some at the some time which will almost surely lead to conflicts.

2. This KDE-on-Mac-installer would not have to make the user mess with dependencies. It would install Fink or MacPorts, automatically install the required dependencies for the application the user wants to install, and it would create an /Applications/KWhatever.app which just runs the app installed in Fink or MacPorts. Something similar to what Steam on Mac does: it installs itself in a seperate 'away from public view' location, along with the required libraries, engines, resources, and other required files; then it just creates an .app for each application with simply a shell script to run the application inside Steam directories itself. Just like what the package managers do: they have the KDE libraries and lots of KDE applications in their own directories, hidden away; it would take a simple script to create an /Applications/KDE/KMess.app which runs KMess. (Whether KMess is installed as an .app inside the Fink directories, or installed as a 'generic' UNIX application binary, is then also not important anymore.)

3. Frankly: If there is a KDE-on-Mac installer which installs KDE seperately from Fink, I would not use it, simply because it ignores my package manager and I already have KDE in my package manager. Considering that everyone interested in KDE on Mac at this moment *already* has it installed in Fink or MacPorts, they would probably stick to that system too. This makes for an installer that is not really used by anybody interested in it. In my opinion, the only way to ever create an installer like this, is to make it adher/stick to the systems currently in use, and simply make it way easier for people to install KDE and KDE applications, instead of inventing a completely new way to do it next to the ways that already exist. We should create something that *we* are sure to use ourselves, for others to come and use it too.

There's a popular saying in #fink that goes: "OS X is not Unix". It's often said when people try to make Fink or Mac OS X look as much like regular Unices as they can, just so other applications and UNIX users like the situation better - but at the same time, it alienates existing Mac users and the Mac way of doing things. I think you need at least a year hands-on experience with developing open-source applications with Fink and/or MacPorts on Mac, before you can completely understand the unique sides of Mac. Not that they are blocking us from reaching our goal! I am very glad we are having this discussion, and I hope we will find out a way to make KDE on Mac installations integrate better into the OS X users are used to, and more importantly: muuuch easier to install. :)

Sjors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2525 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-mac/attachments/20100813/eb5a9cf8/attachment.p7s