[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 14:08:21
Message-ID: C1134833-5D58-4A85-B186-BC0108A1DACC () dazjorz ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Op 13 aug 2010, om 14:46 heeft Mike McQuaid het volgende geschreven:

> When doesn't it make sense to share patches upstream? If Fink and Macports are \
> sharing them and you don't recommend people install from source these patches \
> should all be upstream.

Because some patches only make sense on Mac. Yes, you can #ifdef stuff, but there are \
patches that simply don't make sense upstream, like fixes for the build system that \
would break the build system on other operating systems.

> I agree with Fink/Macports being better for most developers. Most people don't \
> install all their dependencies from scratch on Linux either but people do install \
> Qt and KDE and, currently, this isn't possible on OSX without patches which are in \
> Fink or Macports. This is a bad situation. I don't think the solution is sharing \
> patches, I think it is for Fink/Macports to try and be a bit more responsible \
> open-source citizens: actually push patches back upstream. Yes, it takes effort but \
> that's kind of the point of open-source. 
> I'm trying hard to push the launchd patches upstream to D-Bus but it's a huge pain \
> and it's taking time. However, though, it will be worth it as it means we get \
> closer to the situation of sensible binary distribution. More on that later.

I think it also often happens that patches *are* pushed upstream, but simply not \
merged. This is, I think, also the case with the 10.6 crash that has long been fixed, \
but not merged upstream (if I remember correctly). I've CC'd the KDE maintainer in \
Fink. Benjamin, do you know more details about this?

> > One thing that has been crossing my mind since aKademy is a KDE on Mac installer. \
> > The Windows dudes have done this and it's been working out great - but they don't \
> > have a package manager and we do. I've been thinking about creating an installer \
> > that, after some basic system checks and asking the user what he wants, installs \
> > Fink or MacPorts, configures that, then proceeds to tell the package manager to \
> > install KDE. It could become a KDE-oriented "front-end" to Fink and MacPorts, \
> > also alerting the user of updates now and then.
> 
> This is exactly what I'm trying to avoid. On Windows their "installer" is a package \
> manager that they wrote from scratch. If we want KDE on Mac (or indeed KDE on \
> Windows, quite frankly) to ever catch on with non-technical and non-Linux users who \
> have to use Mac/Windows on occasion, then we need to start bundling our software \
> the way people expect it to be distributed. 
> Fink/Macports/Homebrew are great tools. However, no non-developers I know that use \
> a Mac use them. Hell, most developers on OSX who aren't doing open-source \
> development don't even use them. 
> What our end-goal should be is a nice DMG with a PKG or droppable .app file with \
> autoupdate support and all the trimmings people expect. On Windows, in my opinion, \
> it should be a MSI or NSIS installer that doesn't force the user to worry about \
> dependencies. 
> I think a reasonable intermediate step would be to have a DMG which installed the \
> basic dependencies for KDE applications (e.g. D-Bus, Qt, KDELibs, KDESupport) and \
> then .app bundles for individual applications. 
> I did a talk on using CPack to do this at Akademy the year before last. I really \
> think this is something that we should seek to do a) as a group/team and b) \
> properly rather than just the easiest way possible.

This is exactly what I've been thinking about, but think about this: (this \
information might not be 100% correct, please correct me if I'm wrong somewhere.)

1. Large libraries like Qt are often shipped in Frameworks, 'bundles' of the shared \
library files, resources, metadata et cetera. You build an application against a \
specific version of a Framework and from that moment on, that version of the \
Framework (and the path to it) is hardcoded in the binary, so you need to keep that \
version available. If you update the Framework to a newer version, the old version is \
kept around for those already-compiled applications. Shipping KDE in a Framework is \
very hard at the moment. Most important problem: KDE has several daemons running at \
the same time, like kinit, kwallet and knotify. These binaries, as far as I know, \
can't be shipped along with a Framework, and therefore have to be installed \
seperately. Then, all various installed versions of KDE, which might range from KDE \
4.0 to 4.5, must work with the installed binaries, or you would have to run some at \
the some time which will almost surely lead to conflicts.

2. This KDE-on-Mac-installer would not have to make the user mess with dependencies. \
It would install Fink or MacPorts, automatically install the required dependencies \
for the application the user wants to install, and it would create an \
/Applications/KWhatever.app which just runs the app installed in Fink or MacPorts. \
Something similar to what Steam on Mac does: it installs itself in a seperate 'away \
from public view' location, along with the required libraries, engines, resources, \
and other required files; then it just creates an .app for each application with \
simply a shell script to run the application inside Steam directories itself. Just \
like what the package managers do: they have the KDE libraries and lots of KDE \
applications in their own directories, hidden away; it would take a simple script to \
create an /Applications/KDE/KMess.app which runs KMess. (Whether KMess is installed \
as an .app inside the Fink directories, or installed as a 'generic' UNIX application \
binary, is then also not important anymore.)

3. Frankly: If there is a KDE-on-Mac installer which installs KDE seperately from \
Fink, I would not use it, simply because it ignores my package manager and I already \
have KDE in my package manager. Considering that everyone interested in KDE on Mac at \
this moment *already* has it installed in Fink or MacPorts, they would probably stick \
to that system too. This makes for an installer that is not really used by anybody \
interested in it. In my opinion, the only way to ever create an installer like this, \
is to make it adher/stick to the systems currently in use, and simply make it way \
easier for people to install KDE and KDE applications, instead of inventing a \
completely new way to do it next to the ways that already exist. We should create \
something that *we* are sure to use ourselves, for others to come and use it too.

There's a popular saying in #fink that goes: "OS X is not Unix". It's often said when \
people try to make Fink or Mac OS X look as much like regular Unices as they can, \
just so other applications and UNIX users like the situation better - but at the same \
time, it alienates existing Mac users and the Mac way of doing things. I think you \
need at least a year hands-on experience with developing open-source applications \
with Fink and/or MacPorts on Mac, before you can completely understand the unique \
sides of Mac. Not that they are blocking us from reaching our goal! I am very glad we \
are having this discussion, and I hope we will find out a way to make KDE on Mac \
installations integrate better into the OS X users are used to, and more importantly: \
muuuch easier to install. :)

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
100813140832Z0#	*H
	14-b8MM۪_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
!F/
E K@0j%G38V <
+:C@:Z68/(zLB40|Yn iaWҿE
I)M9x\NTɤ!m12jUlKz~"!6=6l2s3F
" J28l
9Kpg~~&@vkr
N)UA> :. Rj1a z'W}A(\bĒ



_______________________________________________
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