In case you haven't noticed yet, I've added a new directory patches/ to qt-copy. Even though it at first may look only as if I'm upset by the fact that most of these patches hang in qt-bugs@ for months, I actually see good reasons for having patches in qt-copy (also, this is not only my idea - when I mentioned creating patches dir for qt-copy, several people seemed quite happy with the idea, and I'm quite sure there won't be only my patches):

• First of all, those 'patch applied and sent to TT' commits get lost with next qt-copy update, if the patch didn't make it yet into official Qt. Keeping changes in qt-copy also as patches will make reapplying them easier.
• Keeping changes in qt-copy as patches should also make it easier to see how it differs from official Qt, and since some packagers use qt-copy for building their Qt packages, they can see what the differences are, and can pick ones they like.
• There is usually a bunch of patches landing in qt-bugs@ queue that improve some part of Qt noticeably, yet it can be months before somebody else than the patch author will be using the patch. To mention some of my patches, there are e.g. QPixmap<>QImage optimizations that make noticeably faster large images handling, there's a DND optimization that makes DND feel much faster, or there's a patch that makes the menubar applet obey Fitts' Law.
• Even though the patches should be very well tested, one can never test something too much. If TT hesitate to apply a patch, let's test it for them.
• blah blah blah
  &lt;flame&gt;
• oh, and yes, I'm upset by the fact that some of my patches hang in qt-bugs@ for months. While I can understand that TT can't fullfil my every wish even if it includes a patch, just like the same happens with bugs.kde.org etc. (hate mails requesting KHotKeys2 finally being finished are welcome), that doesn't change anything on the fact that I don't like it, and having the patches in qt-copy will also have the additional benefit of making me less upset.
  &lt;/flame&gt;

Now, the intention is not to fork Qt or anything like that. I've still kept my sanity ... hopefully ;). The patches in qt-copy/patches/ shouldn't make qt-copy incompatible with official Qt. There should be fixes, optimizations, and similar stuff.

However, I've also created directory qt-copy/patches/notsafe, which should be for patches for which the above doesn't apply, for various reasons, the most common one being TT's extreme resistance to adding even the simplest new API to a stable release. Such patches should never be applied to qt-copy, and no code in CVS should rely on it. The patch of mine that's currently there quite likely won't make it in time for Qt-3.2, and if it will be so, KWin in KDE3.2 will have a configure check and one of its best new features will be enabled only with patched Qt :(.

The status as far as KDE on Mac OS X (using X11) is basically "complete". I'd been maintaining my own tree for over a year with a lot of help from users as well as development help from the Fink and OpenDarwin communities. I'd been waiting for things to settle down to the point where I could send stuff back upstream, and we're finally reaching that point. There were patches to make KDE build on Darwin as far back as 3.0.2 or so, but I needed that time to make sure the patches weren't so ugly anymore... :)

To get involved, I'm hoping that within the next few weeks all of my patches will be in KDE CVS, and all it will take is to make fixes in CVS just like for any other platform. In the meantime, you can join the kde-darwin list at opendarwin (http://www.opendarwin.org/mailman/listinfo/kde-darwin) if you're interested in helping with Mac OS X specific issues in KDE. It's very low-volume just because I've mostly been maintaining the patches myself, but help would be welcome, so don't be scared off by the lack of posts there... :)

The other thing on the plate is Sam Magnuson's (Trolltech) work on making KDE build with Qt/Mac. I understand that he got kdelibs building last night and is starting in on kdebase, hopefully there'll be more going on there in the next few weeks. I know I'm looking forward to it; I don't have a commercial Qt/Mac license so I haven't been able to play with his patches until now, and at this point his previous patches are against a 4-month-old CVS HEAD, and won't apply cleanly.

> Also what tools are you using, what challenges are you facing? Is it
> far from done?

As far as tools, other than Darwin's freaky linker, it looks a lot like developing KDE for any other platform. Mac OS X has a very cool IDE that comes with the developer tools, but I've never really used it for doing any open-source porting -- just "./configure; make; make install" on the command-line like anywhere else.

The biggest challenge was definitely the linker issues, not being able to link against libtool modules really tripped things up. Between kdelibs and kdebase alone I have to patch nearly 200 files (mostly Makefile.am's) to make KDE 3.1.2 build on darwin. Now, with an updated libtool and libltdl, it's possible to build them out of the box. It's a big load off my back. =)

The single biggest thing that made it feasible to start working on building KDE right out of CVS is Stephan Kulow's kdeinit changes. The kdeinit_* stuff in the makefiles (which was briefly brockenboring and is now am_edit- and unsermake-based again) is based on some patches to unsermake that I sent Stephan to get around linking issues on Mac OS X. The only other thing necessary is an update to libtool and libltdl that Michael Matz is working on (libtool 1.5, or even better libtool 1.5 CVS, are required for dynamic libraries to work nicely on OSX. The current KDE admin/ directory is based on a branch of libtool 1.4.) I gave a short rundown of the problems in making KDE 3.1 work on Darwin on my blog here:

http://ranger.befunk.com/blog/archives/000002.html

...and I've foolishly started a number of threads on the linking issues in kde-devel and kde-core-devel and managed to live to tell the tale:

http://lists.kde.org/?l=kde-core-devel&m=103823892711804&w=2

Here's some of the new stuff going in. I'll try to give a good representation but I can't get it all. These are things that should be in the preview.

• Quanta has a new scripts repository for local scripts. This is for scripts you run to aid in development as opposed to what you want to upload. We are using a new XML *.info file with a Kommander dialog that generates the file. It contains information about the script such as license, contact, web site, etc...
• Templates can now have filter actions. This passes the content to a script for file and text snippets. We have a new TemplateMagic.pl script that enables you to add data fields to a template and define the widget to process them. It then creates a Kommander dialog on the fly which you fill in the content you want for those fields and when you click OK it writes the template file replacing your field holders with your content. I will be personally adding several of these templates.
• ColdFusion support should be complete or very near complete.
• We are finishing a new node based undo/redo that will add some intelligence as well as make kafka support easier.
• We have a new tag description package for designing XML Schema.
• We will also have revised documentation for adding SGML and script support.
• We just added support for visual frames editing.
• We will be adding new Kommander based quick start dialogs. I prototyped one a while back. I'm excited about these because they will allow the user to customize them as they like.
• Kommander is slated for a number of improvements including script containers, support for language neutral loading of trees and lists and more.
• KFileReplace is being converted to a kpart and some features added so that it will enable extensive abilities for multi file multi line search and replace with wildcards.
• Various other surprises and enhancements.

There are more features that will not be in the preview but are in work now.

• David Joham is working on Javascript support, which I'm very excited about. We're talking very intelligent handling of auto completion based on data types and more. We may need to make some improvements to our parser and tagxml but we expected that.
• There are numerous enhancements in the works for templates to make them very intelligent and helpful.
• Data widgets are on the way which will be using hk_classes and Marc Britton will be documenting how easy it is for developers to add widgets.
• we will be setting up live resource management right into Quanta so that you will be able to look for a script, toolbar, template or other resource without ever leaving Quanta. You will also be able to submit resources for others to use from Quanta. I'm very excited about this because I think it will finally activate community participation in fleshing out resources.

We hope to introduce a revolutionary extention to templates to make the majority of site layout and structuring point and click, and we're not just talking design but also edit. We're also researching and designing the kind of group project support that will attract large scale corporate adoption.

The configure switch to build the Kafka part is "--with-kafkapart" (of course ./configure --help gives you all that) but there are two caveats. First you need to be running KDE 3.2 (CVS HEAD) and second, it's still a little early for getting a lot done with it.