Hey!
We here at Qt Software are busy working on all sorts of stuff. Things are moving forward though. For example, I took the plunge and integrated the Cocoa port into the “main” branch over the weekend. It’s a massive undertaking to do a submit that touches many files and get everything working. In the end, it was only something in the UNIX print dialog that didn’t take (probably because of a bad merge from a while back).
Anyway, it’s in main now and should be part of the snapshots. Run configure -help to find out how to turn it on since its not the default.
Otherwise, I’m working on my presentations for DevDays. If you are looking for a chance to corner me and talk about the Cocoa port, you’d be hard pressed to find a better opportunity than at DevDays.
Back to the grind! 
15 Responses to “Cocoa News and Views”
Will the Cocoa implementation concern Mac 64 bit softwares only, or both 32 and 64 bit softwares? (in other words, do you give up the Carbon API all together which is limited to 32 bit?).
In the positive case, what advantages can we expect from the Cocoa implementation? Thanks for your effort, because Mac ports are more and more requested (the current Mac implementation is not as “polished” as the Windows one).
@Philippe, by default 32-bit is Carbon, but if you pass -cocoa on the configure line it will build Cocoa. Advantage-wise, in a tiny nutshell the most significant is that you can deploy 64-bit and use various Cocoa technologies much easier than you could with Carbon. Don’t take my word for it, download it and give it a shot.
Hey Trenton, thanks for your work!
Is there any documentation / overview / README already available which explains how the cocoa implementation differs from the old carbon one, i.e. what will change for the “end-developer”?
For example, I’ve had a hard time getting Sparkle (the appcast updater framework) work in my Qt application. Will the inclusion / the usage of external cocoa frameworks become easier?
Now I have no more excuses for not upgrading my Mac!
@Thomas, since I’m in the middle of writing a presentation of devdays to address that topic, I would have to say that information like that is “forthcoming.” There certainly will be better docs and examples when I have the time to do it. As for working with Sparkle, I’m not sure if it will be different as I’ve never used it. I know that its Cocoa-based, so I would expect that certain things may work better (e.g., having the App do the right thing), but anything I say now would only be a guess.
Any news on Q3Support? Is it still the case that the Cocoa version will drop Q3Support?
@Florian: The position on Qt3Support has not changed. It will not be there. However, it should be possible to pick the bits out of Qt3Support that you need and make use of them.
Do you mean e.g. copying Q3Dict to our own sources? That sounds not like a good idea, especially if we still use it on Windows/Linux from the Qt sources.
Another point it that there are many compatibility Q3Support members on e.g. QString etc.
Do you plan to remove those as well?
Yes, I mean copying the source over and it should be fairly OK with template classes. You can have qmake include or exclude sources depending on the platform.
Inline Qt3Support functions should still work, but not non-inline ones.
Basically, if you want to use the Cocoa port, you’ll have to update your code a little bit. Having done this myself, I know it’s not always trivial, but it was a question of do we release Cocoa with 4.5 and no Qt3Support, push back the entire release for a month or three for just getting Qt3Support working (and supporting it), or wait to 4.6. I think this was the best solution.
You will be able to deploy 32-bit with Carbon down to 10.3 and 64-bit to Leopard on all four Apple architectures. Something has to give to make supporting that somewhat livable.
You can still use Qt3Support with Carbon and we will continue to support the Carbon port until we can require 10.5. Considering we still support 10.3 which came out in 2003, that will probably be for some time to come.
I hope your sentiments are more along the lines of “Once more into the breech dear friends, once more”, as opposed to “back to the grind”.
I agree the the primary focus should be on getting the carbon port working as soon as possible, and many customers/developers are looking furtively in the direction of this port, as it is a race between you and a snow leopard, and the leopard looks better in spandex. Thank you for prioritizing accordingly, and not wasting precious development time on deprecated classes you people originally introduced as a stepping stone onto Qt 4.
All my best
Damnit, cocoa port.
s/carbon/cocoa
Year of the penguin!
Will you be attending the DevDays in Europe, California or both?
@QtFan, Barring any unforeseen calamity, I’ll be attending both.
Hello trenton & all,
as for the devdays in Munich ( you were referring to that, right ? ):
Can you give a tiny preview what you will cover in Terms of Qt - Cocoa ?
Will there be ample time for discussions / questions and answers afterwards ?!
The problem is we have very few time, but i am thinking of coming to Munich for your part alone but i will have to justify myself for doing so
Greetings,
Nils
I’m sure someone will release unofficial, unsupported patches to build at least the non-platform-specific parts of Qt3Support on Cocoa. Sorry, not me, I don’t have a Mac. Maybe the KDE/Mac folks? Time will tell.