[KDE/Mac] Developing KDE on Mac

Tue Aug 17 10:06:21 CEST 2010

On 13 Aug 2010, at 17:55, Sjors Gielen wrote:

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

Plenty of applications are shipped with the Qt frameworks. Do you have any basis for your 1GB figure? Compiled in release mode and unnecessary parts removed we can get this a lot lower.

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

I like the idea of automatic downloading but not making it look to the user like that have installed KMail but it hasn't been downloaded yet.

Simply, I think part of the problem with Windows and Mac KDE efforts is that most users (who aren't already KDE users) won't want KDE. They will want KMail. Or Kate. Or maybe KDEPIM. I very much doubt there are any Mac users who would honestly want to have every single KDE application installed (and would use them all) considering the OS comes with replacements for a lot of them.

KDE is a desktop environment. OSX already has one. Therefore we should look at KDE as a collection of applications, in my opinion. That's why I'd like to see a e.g. Kontact bundle.

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

It's possible to write our own installer but there are companies that make their money doing this, it's really not as simple as you make out. It's really not a simple problem and our installer will have to be maintained and look and behave completely differently to how the PackageMaker or .app bundle installers would.

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

If we're relying on an external framework to manage our application installation, if/when it breaks our users will need to know about them. Also, they both duplicate huge numbers of unnecessary system dependencies, meaning the packages are bigger than they need to be. Homebrew avoids this but provides no binary distribution (neither does Macports iirc).

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

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

I'm still not happy with this and won't work on it, personally. If others are happy to do so, that's cool.

The normal way of keeping OSX applications up to date is Sparkle http://en.wikipedia.org/wiki/Sparkle_(software)

The normal way of dealing with dependencies is to ship them in the application bundle with the application or to have a PKG that installs the application. The application bundle should be moveable.

I know your way seems simpler but it also requires writing a lot more software to integrate with Fink/Macports. It also requires you to pick Fink or Macports (sounds like Fink because of binary distribution). 

I don't think we're going to agree here but I think the more maintainable solution would be to do as much as possible with CMake, as much as possible using CPack or PackageMaker and as much as possible with Sparkle.

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

No problem. I just mention that because I've shipped Qt applications with auto-updaters on OSX for both open-source and proprietary applications and I'm glad I didn't rely on Macports/Fink to do so as the update process is now maintainable and self-contained.

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