1) and 2) can get covered by uname-detecting and a little bit of command line art, and the rest get covered by clang. If a platform does not run clang, there is no point making GNUstep work there either, and this clang precondition pretty much means Linux and Windows only, and this already covered 99% of user base. Meanwhile, we do need an AArch64 objc_msgSend.
Your "99% of user base" does exclude some of our important contributors, who are using Solaris and other platforms others might consider arcane.
Somewhat amusingly, you mention that clang covers Linux and Windows, but you miss various other supported platforms such as FreeBSD.
Oh okay then - I will try wrap my mind around CMake, but gnustep-make is still going away. I will look into the package manager of Swift and create a workalike. gnustep-make is not really friendly and/or useful for the build system that uses Xcode project files anyway.
4) I need dispatch-io in CoreBase and Base, and don’t forget XPC…
You don't, and you can and should #ifdef those sections out.
Still, XPC? Those NSXPC* classes have to be implemented. Also this refactor have “support Swift” in mind but that requires Foundation have a hard dependency on libdispatch. 13) CG is full of CF classes and objects. Try this:
CGPathRef path = CGPathCreateWithRect(CGRectZero, NULL); id path_objc = CFBridgingRelease(path); NSLog(@address@hidden, path_objc.description);
Cocoa's CG is, but GNUstep's isn't. As long as the developer should be using it as an opaque pointer, it does not matter.
I don't know how an Objective-C object is impacted by being passed into CFBridgingRelease(). If it is not satisfactorily impacted, I guess C wrappers around the CGPath Objective-C class in Opal could return an opaque non-Objective-C pointer that wraps this pointer, and other functions could accept it. Someone that's more familiar with ARC could comment on this.
Full circle, buddy. The way you paired OPPath to CGPath is almost exactly how I am going to refactor the entire CF into, but some “exotic” Objective-C feature is used here.
14) Spec files will be supported, plugin will be supported but compatibility is a maybe.
I'm looking forward to seeing your results! 15) The Wayland-based graphics stack requires the client program to talk directly to Mesa over EGL so just like Qt, Clutter or GTK+ we have to speak EGL as well, or include yet another dependency (going against my intention of deprecating Back). EGL being a 3D API does not mean we cannot implement 2D on top of it. And I may end up implementing SpriteKit first as a “2D-on-EGL” layer and build the rest of Quartz2D on top of that. X11 is already on its slow way out so I am not going to make a dependency there.
That does not explain how and why you plan to draw circles, bezier paths and text -- which is what Opal does -- using EGL.
The EGL part comes in play because the drawing will be done using GLUT and Mesa which emits EGL directly (text is drawn by converting it into path first.) Essentially now not even Opal is drawing our graphics, the GPU is.
Opal implements a Quartz 2D-compatible API, also often referred to as Core Graphics. EGL and Wayland don't belong there.
There is no way QE on OS X draws any graphics by itself during normal operation. Once my Mac accidentally booted with “standard VGA” graphics mode and QE have to do all the drawing in software, and the performance dropped to the point I cannot even use the menus. This is an obvious proof that Apple’s QE uses OpenGL almost exclusively and it is usually a good practise (as graphics is offloaded to the GPU) whenever you have one.
Here we don’t need a fallback mode as Mesa have one already there for us.
|