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 _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep