[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-13 16:55:52
Message-ID: 4D73CB94-CC9A-4609-BD4A-E4E4E7FC2746 () dazjorz ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi Mike,

There are a few points I'm trying to make that may not come through =
correctly because of all the technical details I'm mixing in to explain =
the problems.

> To reiterate my main points as I think they may be being lost:
> 1) Any patches that are in Macports and Fink should be upstreamed

Agreed, whatever the outcome of this discussion.

> 2) I think the KDE Mac developers should try and figure out better =
ways of working together (me included)

Let's continue this, because we're on the right way I think :)

> 3) I think a good long-term goal would be binary .app bundles that can =
just be dragged and dropped.


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.

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

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

> You're not the use-case here because you aren't having problems with =
your current set up and that's fine. You might well use it, longer term, =
if it autoupdated itself and it was truly just a matter of dragging the =
self-contained application to get it to install. I don't at all agree =
that nobody is interested in it, I'm interested in it and I know plenty =
of people who want e.g. a stable release on Kontact on OSX that doesn't =
rely on Macports or Fink and building everything from source.


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.

> With my installer I'd also say the user wouldn't have to mess with =
dependencies, there would only be one DMG you'd need to installer, =
similarly to how would do do this with Growl or X11. Also, you could =
even have a PKG which could only fetch the dependencies if they are =
needed. I don't like the Steam way of doing things, it isn't the normal =
way applications are installed/uninstalled on the system.


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.

> If there's anyone not doing things the normal Mac way, it's Fink and =
Macports. These tools are great for installing terminal applications but =
they suck, quite frankly, at delivering binary GUI applications in the =
way most OSX users expect. They are Linux style package managers and =
aren't friendly to end users who avoid the terminal.

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?

Thanks,
Sjors

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

["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
100813165552Z0#	*H
	1;R@ xN0	+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
crQNh<"=Ȃ],N_Ǘ]GEZ9{He X
 B|$lu's량|u2+tU{ѱm \
w	:E⌯&ǖb}1s;#$2$A0y<)}8z ^pEUPe \
d5KH~)NR+08Yv680xzfW}[ j#Um \
nڳnc+ʪYr٢



_______________________________________________
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