[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-13 15:41:46
Message-ID: 6B911573-4E6D-428A-9F57-F4AF2FB43CC0 () mikemcquaid ! com
[Download RAW message or body]


On 13 Aug 2010, at 15:08, Sjors Gielen wrote:

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

And some patches only make sense on Windows and some only on BSD. That's why you can \
selectively use #ifdefs or CMake options or CMake IF(APPLE) to do this stuff. \
Obviously, if it only makes sense in Fink and not even in Macports, it doesn't make \
sense upstream. Otherwise, it probably does.

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

I'm not sure how they are being pushed upstream, they aren't mentioned on this list. \
If people need to commit fixes regularly they can get SVN accounts, they are very \
easy to get. Are they getting put in Bugzilla?

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

Yes, this is trickier but I think code changes are possible here. We don't \
necessarily have to use Frameworks, although that would be the nicest way of doing \
this.

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

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. The reason it \
does it that way is because it has unifed DRM for all applications.

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

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.

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

(Pedantic point: OSX is actually certified Unix whereas Linux isn't :) )

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.

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.

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
2) I think the KDE Mac developers should try and figure out better ways of working \
together (me included) 3) I think a good long-term goal would be binary .app bundles \
that can just be dragged and dropped.

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