[wx-dev] mixing wxMac/wxCocoa (was: auto-completion for the text
controls and combo boxes)
Stefan Csomor
csomor at advancedconcepts.ch
Mon Nov 5 07:41:30 PST 2007
H
i
> Ah, I didn't even know that it was officially supported now. So what
> does
> it mean for us and for the future of wxMac/wxCocoa? AFAIU Apple has
> also
> finally made official that in the long term only Cocoa will be left
> (as I
> believe they announced that there will be no 64-bit version of Carbon,
> didn't they?) so what would be the least painful solution for us to
> merge
> wxMac code into/with wxCocoa? If such hybrid port can only work on
> 10.5+,
> what are we going to do? Require 10.5 for the future versions? This
> risks
> cutting us off from many more users than dropping support for GTK+
> 2.2 :-(
> But is there any alternative? Surely we must start merging these
> ports if
> this needs to be done anyhow and if it can be done progressively?
>
> Sorry for all these questions and I realize that if Apple is indeed
> going
> to drop Carbon in the future it's probably rather sad news for you
> but I
> hope there is still a way to reuse the existing wxMac code in the
> future
> instead of switching over to wxCocoa and having to redo everything
> there.
I will continue the path I've detailed, moving things to Core...
wherever possible and start mixing in Cocoa piece by piece, we've
already been using Cocoa in wxMac, but the place where we haven't been
officially supported mixing things was on the individual NSView /
HIView level. I have committed a wxCursor implementation based on
NSCursor, in a sandbox I have a wxMenu implementation using NSMenu but
of course the biggest step will be using NSViews ... many other parts
of Carbon are not removed, but the HIToolbox has been 'Steved' (worked
in previous builds of Leopard)
Best,
Stefan
More information about the wx-dev
mailing list