[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 19:27:42
Message-ID: E88A60C2-8858-49B3-9878-188270DA32DE () mikemcquaid ! com
[Download RAW message or body]


On 18 Aug 2010, at 20:14, Sjors Gielen wrote:

> The situation with Qt is *completely* different from the situation with KDE. Qt is \
> merely a library. A bunch of frameworks and you're done. KDE consists of much more \
> than that, one of which is the daemons. I indeed checked the size of the Qt library \
> including all headers and with full debugging, no stripping. Still, you have to \
> agree that having the complete KDE application environment (usually not just \
> kdelibs), installed as many times as you have applications, instead of just once, \
> isn't good for the disk space, right?

You made the initial comparison, not me. The daemons aren't a hard problem. I don't \
have to agree about the disk space, I don't think it's that big a deal as I don't \
think users mind having more disk space used if it makes applications easier to run \
and deploy and update.

This isn't Linux, people on OSX generally care more about things just working than \
being as small and efficient as possible. I have multiple OSX Qt apps installed, none \
of them tries to share libraries with the others.

> If you work on improving building of self-sufficient KDE applications, that's \
> wonderful work. It is probably possible, and maybe easier than I expect it to be. \
> In the meantime, I will be brainstorming this KDE installer. Maybe only to fill a \
> gap until you guys have figured out how to do it the most beautiful way, while \
> circumventing the problem of the daemons and everything. 
> Yes, a self-sufficient .app is beautiful. But in this case: why bother, it's not \
> like the user will notice. Yes, interfacing with Fink may be hard. I find it to be \
> a better investment of my time.

Fine, that's your call. The user will notice when Fink updates their package and it \
breaks your installer. The Fink KDE maintainer thinks this is a bad idea, you might \
consider listening to him but I'm not going to stop you.

> These are all just trivial problems. The installer will use the existing Fink \
> installation if it exists. It will use /sw like normal Fink packages. It will use a \
> binary distribution with packages in Fink itself (I don't think 'my' packages will \
> divert from Benjamin's packages, can't think of any patches that wouldn't make \
> sense in Fink itself, or upstream). It will not divert from normal Fink procedures \
> such as the -shlibs packages, so there will be no binary compatibility problems.

Again, you're telling the Fink maintainer that his problems are trivial. I somewhat \
doubt that.

> I'll think this through before I'll really start working on it. This brainstorm has \
> been hugely helpful, but we're just repeating arguments here. I would love it if \
> you continue work on CPack and kdelibs improvements to one day get "real" Mac KDE \
> applications; in the meantime, I will try to work on an installer that works with \
> Fink in symbiosis. We'll tackle the same problem from two sides and maybe we'll \
> meet again in the middle.

No-one is stopping you from making a Fink installer, we're just telling you why we \
think it's a bit of a waste of effort. It's ok to just ignore us and make your \
installer, if it works as well and as transparently as you claim then you can say "I \
told you so".

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