I meant keeping in sync the fact that CGColorRef is a @class CGColor. I did not mean that we teach -gui (and I mean -gui, not -back) what @interface CGColor looks like :]
To my knowledge, CGColor is not toll-free bridgable with NSColor. On Tue, Jun 20, 2017, 17:34 Fred Kiefer <[email protected]> wrote: > > > Am 20.06.2017 um 18:22 schrieb Ivan Vučica <[email protected]>: > > > > On Tue, Jun 20, 2017 at 5:17 PM, Fred Kiefer <[email protected]> wrote: > >> Sounds like we should just put the implementation of these in the opal > part of gnustep-back. We will need the declarations in the guidelines > headers of course. > > > > Presumably you meant 'gui', not 'guidelines' and you got autocorrected? > > Yep. > > > Doesn't feel totally right, but I guess we can have 'unimplemented' > > stub in -gui, and only implement in -back. > > Yes it feels like a hack, but better than having a separate library just > for that. > > > It does mean we have to somehow define CGColorRef and CGImageRef > > (presumably @class + typedef), and ensure we keep opal, gui and back > > in sync if that ever changes. > > No, we already have CGColorRef and CGImageRef in opal and if we don’t > support toll free conversions we can just convert the AppKit object into > the opal version by calling CGColorCreate and the like. > We always have to keep gui and back in sync and the same is true for back > and opal. So we loose nothing here. > _______________________________________________ > Gnustep-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev >
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
