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

List:       kde-devel
Subject:    Re: Running KDE apps on Apple OS X
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2014-03-14 6:22:06
Message-ID: 14F0C83B-F21D-47B0-BF64-58584833AF2F () gmail ! com
[Download RAW message or body]

Hi John,

It's good to see you around again … :-)

On 13/03/2014, at 5:44 AM, John Layt wrote:
> Some random/long thoughts on KDE on Mac, seeing as I'm a sometimes Qt
> Mac developer and a KDE-on-Mac user, subscribed to the KDE Mac list,
> was the guy who got the outdated website taken down as it was
> confusing people, and got a bit burnt-out repeatedly trying to get Mac
> people to engage with KDE and each other.

I cloned some of that page just before it disappeared, tweaked it a little
and that has been the basis of my development environment on Apple
MacBook Pro, with Macports, for 2 to 3 years.  I only work on KDE
Games, but have done some major enhancements to KSudoku,
KJumpingCube and Palapeli (jigsaws), as well as mentoring two
GSoC students in 2012.  So thanks for the head start … :-)

> What frustrates me most is having to rebuild Macports all
> the time, it takes forever and is not a good way to win over normal
> users.  It can also screw with my Qt test builds.

Macports is updating its list of software all the time and its own internal
software from time to time, so you need to do a "sudo port selfupdate"
maybe every few weeks, to get the latest list of versions and new items
and find out which packages you have installed are "outdated".  It only
takes a few minutes to do and you are not obliged to upgrade.

For delivery of actual "ports", it has been moving over to delivering binary
packages by default and I think this practice is now almost total.  So,
using Macports to install software is, I think, quite like Debian's apt-get.
Also, if you want to download and compile source, you can specify a
-s option.  Another good thing they did was to avoid running as "root"
as much as possible.  There is now a "macports" user.

One thing I like in Macports is that previous versions are not automatically
thrown away, just "deactivated".  If you get a dud version of anything, you can
activate the previous version.

> We need a "normal" install method on Mac for normal end-users and
> neither Macports or Homebrew or Fink provide this.

> They're hacker tools still, even after all these years, not end-user tools.

I started to write a GUI front-end for Macports in Objective C and Cocoa.
But it met with no support from the Macports group and no responses to
my requests for review … :-(  The guys there really like the command-line.
So do I, but not for every little thing … :-)

> Other projects like LibreOffice
> have standalone Mac binary installers that they produce themselves (as
> does Marble already) as Macports/etc are not a viable distribution
> option for them. 

Those things tend to come as .dmg files which are pretty easy to install.
I have received quite a lot of free software that way, including LibreOffice,
Firefox and VLC: stuff that I use for "serious" end-user work (in my case
researching and presenting a science course for lay people).  I use
KMyMoney4 for my finances, but would like to be using things like
Digikam, KStars, Kalzium and Kdenlive more …

> Taking on building our code on Mac for
> ourselves can only improve the situation, even if just by freeing the
> Macports/Homebrew/Fink guys up a little to work on integration and
> binary distribution.

> Macports: they try hard to keep up with releases,

They do pretty well … they have KDE 4.12.2 currently.

> and its the only
> reliable semi-easy way to install KDE on Mac,

I heartily agree --- and a lot of other useful things too.  For me,
mysql and inkscape, at least.  I used Macports' inkscape to fix up
the graphics in KSudoku.

> but we keep breaking
> things for them, and I'm not sure I've seen many efforts to push
> patches upstream.  They were not connected in to the KDE community at
> all, in spite of my trying to encourage them in the distant past to
> join the kde-mac list to coordinate things and ask us questions when
> we break stuff, and for us to ask questions when we need to add Mac
> support.  Which is why it's so good to see Ian pushing for this, we
> need people who know both communities to build that link.

I only know both communities, a little, but not all the software in each
community's releases.  And I don't carry much weight in either
community, except that I am probably the oldest member in both … :-)

> Homebrew looked promising when I looked for alternatives to Macports,
> especially with prominent ex-KDE people running it, but the problem
> there was no official support, you can't install KDE from the main
> repo.  Last time I tried I couldn't figure out how to use any of the
> forks that did.  Good news here is that there is now an effort to
> unite all the forks and make an official repo (see
> https://github.com/adymo/homebrew-kde/issues/11), with well-know KDE
> peeps adymo and haraldf involved and currently pushing patches
> upstream to fix Mac build issues.  But nary a peep on the kde-mac
> list, so others may not know what's going on.
> 
> Fink:  No idea on the current status, last time I tried years back
> they were well out-of-date so I stuck with Macports.
> 
> And there's the problem with KDE on Mac in a nutshell: three different
> build technologies, designed for hackers, with little coordination
> between them or us.  So I beg you all: SUBSCRIBE TO THE KDE-MAC LIST
> AND CO-ORDINATE THERE!  COMMUNICATE!  I want our Mac group to revive,
> and if we work together to solve problems and maintain the upstream
> KDE build in KDE with CI to keep them building then it's a lot less
> work downstream!  We need to build the same relationship with the Mac
> builders as we have with the Linux disto packagers, we build and
> maintain the code, they package and distribute.
> 
> What to do at the KDE end?
> 
> We have a wiki at http://community.kde.org/Mac that we need to keep
> updated as things change, as that is where mac.kde.org redirects.  We
> also have the forum at http://forum.kde.org/viewforum.php?f=60, but
> for devs please use the list at
> https://mail.kde.org/mailman/listinfo/kde-mac.  I can't emphasise
> enough: if everyone who's doing stuff with KDE-on-Mac were to talk to
> each other there, there would be a lot less work needed!
> 
> Qt5/KF5 may improve things, but we still need to build infrastructure
> to support Mac.
> 
> We need CI Mac builds to test KF5 stuff and prevent Linuxisms and
> build breakers from creeping in over time, e.g. to ensure the creation
> of Mac Frameworks (a special type of library) works as you need to
> follow strict include rules that Linux or Windows don't need.  It's
> part of our "KF5 everywhere Qt is" strategy.  Advanced Mac platform
> integration will also need CI builds to check they don't get broken by
> Linux-focussed devs :-)
> 
> We need remote gui or shell access to Macs to allow selected devs to
> do test builds of their apps, or at least some way to trigger feature
> branch builds in the CI from a dashboard.  Failing CI after you've
> done a blind untested Mac commit is just asking for trouble.
> 
> You can run Mac in VM's on Mac, recent OSX versions grant a license to
> do this without paying extra, so a single machine can support multiple
> build VM's.  I can dig up the details.  I run Mac in a VM on my Linux
> desktop, it is possible, but breaks the license and so is not an
> option for KDE CI (I do have an old slow Macbook, so I paid for it and
> feel semi-legal).

I was thinking that an organisation like KDE or KDE ev might be able to
get a special licence from Apple.  It would not hurt to ask.  It is not as
if KDE is a bunch of hackers in garages (where Steve & Steve started :-) )
is it?  Apple ought not to be afraid of KDE causing them a support headache.

> We need to buy Mac hardware to run as part of the CI system (or hire
> it if a data centre offers it), and perhaps also provide remote
> access.  Intevation did offer time on their build hardware at one
> point but we failed to take them up on it.  I have suggested a number
> of times we run a crowd-funding for 2-4 Mac Mini's (EURO 800 each for i7
> w/ 4GB) which are perfect for the job and widely used for this
> purpose.  Homebrew was very successful doing a fundraiser to set up
> their build farm, talk to Mike McQuiad about it.  We can do it as
> well, we don't ask our users for money often enough, they're more than
> willing to pay a little for specific targets like this.
> 
> Kolab and other companies may be interested in assisting and could be
> approached (i.e. will the Munich contract require Kontact on Mac?).
> KDAB/Till has a lot of expertise in this area but little time now.  I
> think KDAB had dmg packages for Kontact for easy install, but I don't
> know what the status there is.
> 
> Qt is having maintenance issues on Mac themselves, Digia has limited
> resources, and there seems few community-led contributions, but they
> do have CI and may be able to offer advice.
> 
> I really want us on Mac, when you see how rubbish or locked-down their
> apps are you realise we could make a decent splash there.  Now I
> regularly code for and build Qt over there I feel a lot more
> comfortable as a conduit if needed.  I'm willing to be a guinea pig in
> trying to get kdesrc-build working on Mac for our devs and CI to use,
> heck I'm willing to switch to Mac for all my KF5 dev work if needed!
> I just need someone who knows what they're doing to point me in the
> right direction and answer my confused cries for help :-)
> 
> But what we need most right now is a Mac experienced sysadmin to take
> on setting up and maintaining the Mac infrastructure, then a
> fundraiser to get the hardware.  And for people to start talking to
> each other on kde-mac.

I'm right with you on the above.  It would make sense for KDE to build
and test its own Apple versions, if only to enhance its reach and
reputation.  The libraries and apps KDE produces are world-class.
They deserve a wider audience.

I think it will take a while for the grand plan to come about, so I will
just continue looking for low-hanging fruit to pick in the meantime.

All the best, Ian W.


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]