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

List:       kde-mac
Subject:    Re: [KDE/Mac] Developing KDE on Mac
From:       Sjors Gielen <mailinglist () dazjorz ! com>
Date:       2010-08-18 14:13:00
Message-ID: 7FAE3461-D36D-4C3F-8C35-94042AEA45F2 () dazjorz ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Op 17 aug 2010, om 10:06 heeft Mike McQuaid het volgende geschreven:

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

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.

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

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

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

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.

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

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:

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

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

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

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

I think I will start on it sometime, after some more public brainstorming. I'll be \
e-mailing on this list too.

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

Oh, I didn't know this, but I recognise the dialog. Thanks! Will keep that in mind.

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

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


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

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

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

Sjors


["smime.p7s" (smime.p7s)]

0	*H
 010	+0	*H
 l0h0P 0
	*H
0y10U
Root CA10Uhttp://www.cacert.org1"0 UCA Cert Signing \
Authority1!0	*H 	support@cacert.org0
100705230101Z
120704230101Z010USjors Gielen1$0"	*H
	sjorsgielen@gmail.com1"0 	*H
	dazjorz@dazjorz.com1&0$	*H
	mailinglist@dazjorz.com1 0	*H
	dazjorz@kmess.org1,0*	*H
	dazjorz@users.sourceforge.net10	*H
	sjors@kmess.org0"0
	*H
0
ףڨ :1irATu=_nao" \
'@8]o-:i@vw(	E{TZgK1"n \
a%#M܇\MȲ!ÆgcEp=2Rn2(`3u벽I]vKKr\2<뼃 \
cM|tPQ!^Ԗx4~ \
r߇WmC􅚲"@;2g@9u@5!DFYuЫh׃}v0r0U00V	`HB
 IGTo get your own certificate for FREE head over to \
http://www.CAcert.org0@U%907++ +7

+7
	`HB02+&0$0"+0http://ocsp.cacert.org0U0sjors \
gielen@gmail.comdazjorz@dazjorz.commailinglist@dazjorz.comdazjorz@kmess.orgdazjorz@users.sourceforge.netsjors@kmess.org0
 	*H
REXp}
;/,u^W92J4eIGLY(k4%Y< %$
%q9,ܛQeAfyruOExl2t_pп;Rmܻ(pEҍʛ#P'$Ѝd$?}P.^_"HDόüNי	x	ĺQ6ؓ \
W wZ; ZUpz\$"{aƃ}Ri \
Qs8	;x-t=;`lĒEp$$vhgGKEk \
(r<3KI/cT:NNQGur 7K)tOVE5B|(kA; \
"tS(V+M3%62D6`;8~CN	WȊOCvږ^'xC:F/"RP?$n#!ټw!! \
2aOǓ^7@צ.wn130/00y10U Root \
CA10Uhttp://www.cacert.org1"0 UCA Cert Signing Authority1!0	*H \
	support@cacert.org0	+ 0	*H 	1	*H
0	*H
	1
100818141301Z0#	*H
	124K!-ZX=&0	+7100y10U
Root CA10Uhttp://www.cacert.org1"0 UCA Cert Signing \
Authority1!0	*H 	support@cacert.org0*H
	1 0y10U
Root CA10Uhttp://www.cacert.org1"0 UCA Cert Signing \
Authority1!0	*H 	support@cacert.org0
	*H
b7LsKkSxLA+|{(
 Sڔ:Yn?V2A2 vSjP9;gIY(-6O?p<v
$)ŭ:X>KfsTSXT2=S\] n21 ŶfJEԥ \
L{*`^)(t R0EM܀("~5
˳ Ub{m״
kvSD%.&ˣID}[J|"su@zU9HGa



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

Configure | About | News | Add a list | Sponsored by KoreLogic