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 <fredkie...@gmx.de> wrote: > > > Am 20.06.2017 um 18:22 schrieb Ivan Vučica <i...@vucica.net>: > > > > On Tue, Jun 20, 2017 at 5:17 PM, Fred Kiefer <fredkie...@gmx.de> 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 > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
