[KDE/Mac] Developing KDE on Mac

[Mike McQuaid]

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

> The basis is running `du`. Yes, we can get it down a lot, but there are still a lot of resources, sounds, and images that KDE expects to be there, even if applications don't use them.

Yep, that's my point, I think you can minimise the dependencies but we'll agree to disagree here.

> I agree that this can be confusing (especially if there are SO many applications that will be shown like that).

Cool.

>> 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.
> 
> The fact that we want them to look like a collection of seperate application, does not mean we have to install them like that. Especially if not doing it is much easier, it takes less disk space, and makes it MUCH easier to ship KDE with its daemons along. I don't see any cons to that; my only reason for the .apps was to give the whole a native look and feel.

My point is that most people will only want a few applications.

> We can have the .app have a script that's executed when uninstalling it (moving it to Trash), so we could let that pop up the uninstaller which uninstalls KDE if the user wants it and the last KDE application was uninstalled.

Good luck creating that script, I think that would be far from trivial.

> It *is* as simple as I make out, because it uses Fink and MacPorts under the hood, which already do all the work. It is also just as easy for users, since QWizard on Mac looks *exactly* like the .pkg installers and it can be an .app itself - Qt is *very* good at Mac applications. We'd just have to interface with the package manager (that might be harder than it sounds but that's the only thing); the only things it would have to do *itself* are:

No, it doesn't look exactly like the pkg installers and Qt isn't very good at Mac applications and the package managers may not have an API you can use.

> * Tell the MacPorts / Fink installer to install itself (or write our own installer, but why bother)
> * Retrieve the status from that installer while it's running
> * Tell MacPorts / Fink to install package X
> * Retrieve the status from MacPorts/Fink while it's running
> * Know what applications map to what packages in both or one of both
> * Have commandline options for preselecting applications for install or uninstall
> 
> Package this as an application that looks native and it will make it easy for everyone to use it.

As said before, I still feel this won't be as easy as you expect and doesn't bring many advantages over just getting the user to run Fink/Macports manually.

> No, they don't duplicate huge numbers of unncessary system dependencies. Fink has virtual packages for various things like X servers, it depends on them and tells you what to do if not installed. And if a package is really annoying, we can have a seperate fink-kde addition to Fink for special KDE-dist packages if we want changes that Fink doesn't want. Anything is possible; reinventing the wheel is the wrong solution. (CC'd Fink developers to see what they think.)

They duplicate system libraries. This even has an FAQ entry.
http://trac.macports.org/wiki/FAQ#ownlibs

> This still works. "To have a PKG that installs the application", now it's a .app that behaves exactly like a PKG. It installs KDE in a non-movable location (Fink or MacPorts install dirs), and all application bundles in /Applications or /Applications/KDE are perfectly movable since they only link to that location.
> 
> I think it's 100% possible to do this transparant and give everybody a complete Mac look-and-feel.

I don't think it will be transparent, we'll agree to disagree though, and it still relies on Macports and Fink and all their patches and that they package everything correctly. The .app won't behave exactly the same as a .pkg unless you use PackageMaker.

> The other viable solution comes down to writing a dependency resolver yourself. I think if we start with our ideas at this very moment, right now, that I will be done a lot earlier and easier, and I will have the complete KDE building and installing perfectly right from the start. :) (It will also be more maintainable, but it will also have to be maintained more, because relying on an external component has the risk of it being changed.)

Or just using the dependencies already calculated by CMake and the CMake scripts for getting compile-time prerequisites (GetPrerequisites).

> I don't intend to say that interfacing with Mac and FinkPorts is the best way to go for every goal. I really like self-contained .apps, I love the bundle idea Mac has. In this case, however, its cons overweigh the pros for me. You have more experience in this than me, but I'm quite sure that this is the right way to go at this. :)

Your call. 

As an example of my method, here's how to make a Qt application that finds and installs all it's own dependencies in CMake:
http://gitorious.org/charm/charm/blobs/master/Charm/CMakeLists.txt#line228

This lets "make package" build a droppable .app installer of this Qt application on OSX. I could change one line and make it create .pkg installers instead. The .dmg is 6.4MB and the installed .app is 20MB. This somewhat destroys your claim that "bundling a Qt framework inside the .app makes the .app grow by a few hundred MB".

Patches/bugs are currently in the CMake bug tracker which, when fixed, should make this almost a one-liner.

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