gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Forking on Github and feedback


From: Ivan Vučica
Subject: Re: Forking on Github and feedback
Date: Sat, 05 Dec 2015 20:07:35 +0000

On Fri, Dec 4, 2015 at 3:10 PM 陈北宗 <address@hidden> wrote:
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.
 
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.
 
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. 
http://svn.gna.org/svn/gnustep/libs/opal/trunk/Source/OpalGraphics/OPPath.m
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.

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.

https://www.opengl.org/discussion_boards/showthread.php/173171-OpenGL-ES-vs-Quartz-2D?s=6470756514d1728dcdf9a7502cc70e3a&p=1213450&viewfull=1#post1213450
Opal implements a Quartz 2D-compatible API, also often referred to as Core Graphics. EGL and Wayland don't belong there.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]