To chime in... On Wed, Jun 14, 2017 at 9:48 PM, Daniel Ferreira (theiostream) < bnm...@gmail.com> 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.)
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
