Re: Questions about OSX compatibility

[Ivan Vučica]

To chime in...

On Wed, Jun 14, 2017 at 9:48 PM, Daniel Ferreira (theiostream) <address@hidden> wrote:

Hi guys,

Over the last days I've moved on with compiling WebKit based on
GNUstep, and some recent issues over how to move some headers around
for OSX compatibility. I'll mention many loosely related issues since
they overlap at some point.

The first issue is that of framework amalgamation. Apple has
frameworks like ApplicationServices.framework[1] or
CoreServices.framework that don't do much by themselves. However, have
"sub-frameworks" both in their headers. For instance,
ApplicationServices.h includes CoreGraphics, CoreText, ImageIO,
HIServices and many others. Supposing GS implemented all of these
frameworks, how should we handle the installation of this "global
header" that imports all of these frameworks given the current module
model?

My view is a new 'project' (repository) per framework would be good enough. It would certainly be clear what you need to clone in order to get 'ApplicationServices/ApplicationServices.h' if the repository was called 'libs-applicationservices'. Using git submodules, we can also ensure dependencies are installed at the same time.

But, if we know that this is a pattern, then maybe a single project containing these compatibility and amalgamation headers would be a better option?

Feedback would be appreciated here.

 

The second matter comes to CarbonCore's Unicode and text conversion
facilities (e.g. TEC* functions[2]). They have not yet been deprecated
by Apple and are used by WebKit, and would thus need to be implemented
in GS. Ivan suggested there might be a case for expanding
https://github.com/gnustep/libs-ucsdata's purpose into including these
functions. Do you agree with this or should it become part of another
framework or be a new one?

No suggestion here aside from what I mentioned earlier. :)

Feedback would be appreciated here.

 

The third matter comes to Opal's CGImageSource/CGImageDestination
APIs. In Opal, it is part of OpalGraphics (thus under CoreGraphics'
headers). However, in OSX, these interfaces are part of a separate
framework called ImageIO. That said, I think it does not make sense to
keep them inside OpalGraphics, but aside from that I don't know how
you see the issue. Is it the case of moving them to another module; to
another "subproject" inside Opal (e.g. OpalImage or something); or not
move it from OpalGraphics at all and just change where we are
installing the headers?

This one, I'd keep it in the Opal repo.

"""Originally part of the Core Graphics framework, Image I/O resides in its own framework to allow developers to use it independently of Core Graphics."""

OpalImage sounds like a nice name.

(Which reminds me... I should really rename 'quartzcore' project into 'opalanimation' or something like that.)