[KDE/Mac] Developing KDE on Mac

[Mike McQuaid]

On 13 Aug 2010, at 15:08, Sjors Gielen wrote:

> 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.

And some patches only make sense on Windows and some only on BSD. That's why you can selectively use #ifdefs or CMake options or CMake IF(APPLE) to do this stuff. Obviously, if it only makes sense in Fink and not even in Macports, it doesn't make sense upstream. Otherwise, it probably does.

> 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?

I'm not sure how they are being pushed upstream, they aren't mentioned on this list. If people need to commit fixes regularly they can get SVN accounts, they are very easy to get. Are they getting put in Bugzilla?

> 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.

Yes, this is trickier but I think code changes are possible here. We don't necessarily have to use Frameworks, although that would be the nicest way of doing this.

> 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.)

With my installer I'd also say the user wouldn't have to mess with dependencies, there would only be one DMG you'd need to installer, similarly to how would do do this with Growl or X11. Also, you could even have a PKG which could only fetch the dependencies if they are needed. I don't like the Steam way of doing things, it isn't the normal way applications are installed/uninstalled on the system. The reason it does it that way is because it has unifed DRM for all applications.

> 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.

You're not the use-case here because you aren't having problems with your current set up and that's fine. You might well use it, longer term, if it autoupdated itself and it was truly just a matter of dragging the self-contained application to get it to install. I don't at all agree that nobody is interested in it, I'm interested in it and I know plenty of people who want e.g. a stable release on Kontact on OSX that doesn't rely on Macports or Fink and building everything from source.

> 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. :)

(Pedantic point: OSX is actually certified Unix whereas Linux isn't :) )

I'm not sure if you're referring to me here but I'm a Homebrew maintainer and hack on various other open-source packages on Mac. I also deliver proprietary products on Mac and have done across several companies.

If there's anyone not doing things the normal Mac way, it's Fink and Macports. These tools are great for installing terminal applications but they suck, quite frankly, at delivering binary GUI applications in the way most OSX users expect. They are Linux style package managers and aren't friendly to end users who avoid the terminal.

To reiterate my main points as I think they may be being lost:
1) Any patches that are in Macports and Fink should be upstreamed
2) I think the KDE Mac developers should try and figure out better ways of working together (me included)
3) I think a good long-term goal would be binary .app bundles that can just be dragged and dropped.

--
Cheers,
Mike McQuaid
http://mikemcquaid.com