[KDE/Mac] Developing KDE on Mac

[Sjors Gielen]

Hi Mike,

There are a few points I'm trying to make that may not come through correctly because of all the technical details I'm mixing in to explain the problems.

> 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

Agreed, whatever the outcome of this discussion.

> 2) I think the KDE Mac developers should try and figure out better ways of working together (me included)

Let's continue this, because we're on the right way I think :)

> 3) I think a good long-term goal would be binary .app bundles that can just be dragged and dropped.


A self-contained KDE .app is very hard to make. Not only bundling a Qt framework inside the .app makes the .app grow by a few hundred MB, and bundling KDE would make the .app grow by a few hundred MB more (this means 500-1000 MB for KMail and another 500-1000 MB for Kontact); there's also all the technical difficulties of bundling KDE and relocating the KDE daemon binaries and running them without conflicts.

Therefore if we do this, I'd opt to install KDE by a .pkg, not inside an .app; then we could make .apps with just "the rest" that can be dragged and dropped, or those apps are included in the .pkg and the .app is just a shortcut. (I just had a vision of double-clicking KMail.app, the installer popping up and saying "Hey, you do have KDE but you don't have KMail yet. Wanna download and install it?" and a minute later, you're using KMail.)

[0] It's possible to write our own installer with an interface just like that, by using QWizard. Then the KDE.dmg would ship with a KDE.app inside of it. What KDE.app does next, is still under discussion. ;-)

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


What's the problem with relying on MacPorts or Fink? They've solved *all* the problems with installing the KDE dependencies and KDE itself, on Mac, and they have a build system and all packages readily available. Why re-invent the wheel when we can re-use the existing ongoing work of the MacPorts and Fink volunteers? I know that at least with Fink, binary distributions are way easy to create and add and keep up-to-date (uses Debian's apt standard for that); you then also get versioning and a dependency handler for free. You have stable releases, development releases, whatever you want, no extra work required. This is most probably true for MacPorts too (I don't know anything about Homebrew).

And of course, users don't need to *know* the installer uses Fink or MacPorts below the hood, because they likely won't care, and the installer can check if either of both is already installed so there won't be any conflicts.

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


This is exactly what I'm referring to above. :) With Fink or MacPorts, users wouldn't have to mess with dependencies, there would be only one DMG/PKG, and the package manager itself takes care to only fetch the dependencies that are needed and not installed yet.

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

I agree that Fink and MacPorts also aren't the real normal way applications are installed on the system, but that's because the normal way has features missing over Fink and MacPorts. I of course mean dependency resolving and updating. The fact that the normal way is the normal way, does not mean we have to use it - nor is the fact that Fink and MacPorts aren't the normal way, a reason not to use them. Writing a complex KDE installer that does dependency management and keeps everything up-to-date, would be just another Fink/MacPorts. There are only two things that keep Fink (the one I have experience with) from being more friendly to normal Mac users: a normal graphical interface, and installing in normal reachable Mac places. The second is on purpose; Fink explicitly keeps its hands off from anything other than /sw. The first is just because of a lack of manpower and interest.

By creating this KDE installer I have in mind personally, we solve both problems at the same time. Fink and MacPorts (and Homebrew, possibly) get a graphical frontend for installing KDE parts of it, and after installing it creates entries in /Applications or /Applications/KDE, and from the user point of view everything is Mac-ish again. I still agree that the way it works under the hood is not really Mac-ish, but then again: is there a way to ship KDE and all its dependencies in another way that makes everybody happy: "ignorant"[1] users, Mac purists, Fink users, MacPorts users, you, me, people trying out (KDE on) Mac for a day, core KDE developers, et cetera et cetera?

[1] Ignorance here meant as in: don't know and don't *want* to know what's happening under the hood. Not stupid people, but people who want to get their own work done.

Therefore I think that if we create a KDE-on-Mac installer as a KDE-on-Mac team, we should make it use Fink and/or MacPorts (and/or Homebrew and/or whatever), and still make it easy to use and not confusing for people who don't know what a package manager is or what role kdelibs plays in the KDE application they want to install. We should give the thing a Mac look-and-feel, too.

What do you think? Suggestions/ideas/critics from others?

Thanks,
Sjors

Offtopic:

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

There were a few things you said that made me draw the conclusion, back then, that you probably didn't develop on Mac yourself. Especially because you were talking about deployable .apps for KDE applications, while that's way easier said than done. I've researched it and found many problems with the approach. I drew the wrong conclusion, sorry for that.
-------------- 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/40c90a4f/attachment-0001.p7s