| Hey Ivan,
Feel free to create a branch (svn copy) of opal and commit your patch there, if you feel it's a hack / not really suitable to commit to trunk. In general it's fine with me if you commit to trunk though. :-)
As you say integrating opal and gui/back is complicated. I would love to have a proper solution. Currently it's hard to justify working on Opal because nothing uses it, and while there are things that could be done to improve GNUstep back as it is currently, I would rather spend time on making some kind of merger between back and Opal that combines the best of both (Opal being a standalone library is a big advantage, so it can be used by both gui/uikit and be tested on its own. On the other hand, Back's object-oriented design is better. I tried to structure the more recent parts of Opal I wrote more like that.)
It would be easier to proceed if we could agree on making cairo a required dependency of GNUstep-gui. Any thoughts on that now?
Regards, Eric
On 2012-06-03, at 11:25 AM, Ivan Vučica wrote: (CCing the list.)
Alright, I understand.
Unfortunately, as Niels said, that doesn't fix my short-term problem, and I really would be the wrong person to go and make -gui dependent on Opal. That's bound to break a lot of build scripts that people have set up and would require Opal to be moved to core.
Hence, for the simple purpose of making my small test of Opal-in-NSOpenGLView functionality work, I've replaced most of the implementations of NSFont{Descriptor} with #import <AppKit/NSFont{Descriptor}.h>, and by adding categories for missing methods.
I got rid of:
typedef union _OPAffineTransform
{
NSAffineTransformStruct NSTransform;
CGAffineTransform CGTransform;
CGFloat PSMatrix[6];
} OPAffineTransform;
which makes some pieces of code uglier, but shouldn't break anything.
I've quickly looked at Opal's tests, and things don't seem to be broken. However, I wouldn't apply my patch to Opal's trunk; it'd be best if someone more familiar with its operation were to patch it from scratch.
Patch is available in dev-libs/quartzcore/opal-nsfonthacks.patch
http://svn.gna.org/viewcvs/gnustep/libs/quartzcore/trunk/opal-nsfonthacks.patch?revision=35176&view=markup
On Sun, Jun 3, 2012 at 3:18 PM, David Chisnall <theraven@sucs.org> wrote:
NSFont (CTFont?) is toll-free bridged with two font classes: one in UIKit and one in AppKit. The goal for Opal was to provide an NSFont implementation that could be used in either.
David
On 2 Jun 2012, at 18:13, Ivan Vučica wrote:
> 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. Since UIKit doesn't contain NSFont, Apple's implementation obviously doesn't depend on NSFont. So, an alternative is to rename Opal's NSFont and explore what APIs would be broken.
>
> What free software currently uses Opal?
> --
> Ivan Vučica - ivan@vucica.net
>
>
--
Ivan Vučica - ivan@vucica.net
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
|