Hi Ivan, Am 02.06.2012 19:13, schrieb Ivan Vučica: > Hi, > > Opal and AppKit both contain mutually incompatible NSFont > implementations. This means that my attempts to make use of Opal in an > AppKit app are failing miserably (and only at runtime). > > It may be wise if someone more experienced with both AppKit and Opal > would patch this. My current idea boils down to adding the few new ivars > into AppKit, and to move any added methods into a category that'd ship > as part of Opal. > > This would have a bad side effect of making Opal dependent on AppKit or > another library that implements NSFont.
Actually, the reverse would be better: In the long run, we want to use Opal for drawing in AppKit (and UIKit), so the implementation of the font system belongs there. > Since UIKit doesn't contain NSFont, Apple's implementation obviously doesn't > depend on NSFont. Judging from the APIs, I'd say that UIFont is actually a slimmed down version of NSFont. If I rememeber this correctly, the original plan (or was it just my plan?) was to have Opal implement NSFont as a class that has both the UIKit and the AppKit personalities. That class would then be declared as @compatibility_alias UIFont so that it can be used in both AppKit and UIKit. Unfortunately, that doesn't fix your short term problem that you cannot link both AppKit and Opal. I'm not sure what the quick fix would be, but the text system in Opal is a bit incomplete, so maybe you can just disable the NSFont related stuff in Opal for the time being? I think CTFont should still continue to work in that case if you also link AppKit (it just typedefs CTFontRef as NSFont). Cheers, Niels _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
