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 <[email protected]> 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 - [email protected]
> >
> >
> > _______________________________________________
> > Discuss-gnustep mailing list
> > [email protected]
> > https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>
>
> -- Sent from my brain
>
>
>
>
> --
> Ivan Vučica - [email protected]
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
