[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] Developing KDE on Mac
From:       Mike McQuaid <mike () mikemcquaid ! com>
Date:       2010-08-17 8:06:21
Message-ID: F4E9B5BF-D512-412B-8028-874F0924D5AE () mikemcquaid ! com
[Download RAW message or body]


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

_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X


[prev in list] [next in list] [prev in thread] [next in thread]