OS X emulation layering

[Luboš Doležel]

On 11/18/2015 10:02 AM, Maxthon Chan wrote:
> We probably need to rearrange libraries a bit since the current
> layering is just too messy.
> 
> Foundation technology stack: libc -> libobjc (implement NSObject
> here) -> gnustep-corebase (with TFB classes implemented here) ->
> gnustep-base

I've done that slightly differently:

* libsystem depends on system_c, ..., and libobjc2 (needed because of
Blocks runtime embedded in libobjc2).

* corebase and base compiled together into a single .so. Required due to
an unpleasant dependency loop looming between the two. (NSCF* classes
require base and NSRunLoop will require corebase).

> Graphics technology stack: EGL (my suggestion) or
> gnustep-metal -> gnustep-qe -> gnustep-opal -> gnustep-gui
> Audio
> technology stack: ALSA -> gnustep-coreaudio (with Audio Units)

There is no gnustep-coreaudio, but there is Darling CoreAudio which can
already support a very simple app such as mpg123. It is built on top of
ALSA and ffmpeg APIs (audio decompression and processing), but can be
easily changed to support OSS for example.

There is still a lot of work left though (e.g. Audio Queues).

> Using Qt will result in Qt interfacing code being embedded deep into
> gnustep-gui (NSWindow at least, maybe even GUI elements) which may
> break some OS X apps that uses QC or CG to draw their own UI
> elements. EGL is a few layers lower and actually maps to the layer of
> OpenGLES that QC on iOS works on so we can just build the graphics
> stack iOS style.

I've already thought this through (the case you're mentioning) and it
can work. I'd specifically build on top of the Qt Quick engine.

Starting on the EGL layer is not realistic. Not without a large team of
people hacking on this, which is simply not there.
-- 
Luboš Doležel