[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-18 15:30:51
Message-ID: F6D5BED1-9795-4BB4-93CF-4EAF42CD6604 () mikemcquaid ! com
[Download RAW message or body]


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

_______________________________________________
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]