Sam Magnuson (the Trolltech dude who did the initial Qt/Mac KDE port) is dead busy and hasn't had the time he'd like to work on it. He'll be available for questions a bit, but I'm taking another whack at the port myself. I'm incredibly busy for the next month or so, so I'm looking for people willing to help out. I've already had one offer from someone who's started in on it. The goal this time is to get something basic working, and to the point where the KDE folks will accept it (at least in a branch).
I'm thinking this is a good time to revive the KDE-Darwin mailing list. If you're interested, go there and say "hello" to the list. Don't be shy, there's probably only 10 people on it. <grin>
I've gotten a decent amount of kdelibs building using Sam's previous patches as a reference (they're too old to apply cleanly, KDE CVS waits for no man). If anyone else wants to help, I'll make sure my changes get put somewhere so people can give a hand.
Happy hacking!
|
|||||
Qt/Mac KDE Call for Help9 comments to Qt/Mac KDE Call for Help |
|||||
|
Copyright © 2024 Tales of the Raccoon Fink - All Rights Reserved |
|||||
Do you guys think that this is counter-productive, I mean building whole of KDE for Mac? Do we really need another dock (kicker), or another window management system etc.
Wouldn’t it be better if all effort goes in building apps for themselves. I know that most of KDE apps needs KDE libs to build and run but I think that easier route is to rewrite some portions of those apps to run just needing QT.
As I mentioned in the macslash article, I really could care less if we have a native Kicker. But there are a number of KDE apps that would be great as native apps (kstars, kmail, koffice, etc.)
If you can get them to build, you’ve already got kicker and stuff because of the nature of how KDE’s build system works. I have no plans on replacing the finder, I just want the apps.
I think that all KDE apps can be easily adapted not to rely on KDE. See Kvirc for example. It can be integrated into KDE but it doesn’t require it for building.
I see the best candidate for this in Koffice simply because it’s separate project. Maybe a word or two on their mailing list could do the trick for them to do the hack for QT only building.
If you think that, you haven’t seen the code. =)
Many apps that come with KDE are tightly coupled with the libraries in kdelibs. The only reason, eg, Apple was able to use only khtml was that it didn’t have very much in the way of GUI widgets and such.
It’s ironic you mention kvirc, actually. It’s based on such an antiquated form of the KDE build system that it’s completely unportable to MacOSX. They do their own module-loading code which apparently only works on linux, and various other things break in mysterious ways. I spent a weekend trying to get it working and gave up after fighting with their spaghetti build system.
I think this sounds really exciting, especially porting kdelibs. IMO, it is much nicer being able to get KDE apps to run without having to remove KDE dependencies. This could give KDE apps a whole new “market.”
Didn’t Apple do a significant amount of work on the KDE libs to get the KDE Browser to become what we now know as Safari? My thought at the time was that this was a grand scheme to prove the concept and clean up the API’s without a serious threat to Microsoft so that more could come later in the form of a KOffice Word killer direct from Apple.
If this isn’t planned, shouldn’t Apple’s contributions to the K libs help with a public KOffice project?
No, apple had to do very little to integrate KDE stuff into Safari. KHTML is fairly stand-alone, and doesn’t rely on KDE-specific libraries. Apple took KHTML and ported the Qt-specific code to use standard c++ STL and such, I believe (ie, using regular c++ string handling instead of QString). KHTML is a very tiny part of the base KDE libraries.
I think this is a great project that deserves work and my help… but where can I start? how much of kde depends on X? or is that the issue at all….