Hello! The concept looks great.
On 4. 3. 2013., at 08:04, "Lundberg, Johannes" <[email protected]> wrote: > Since we love Objective-C and the Cocoa frameworks we definitely want to have > it as the application framework in our OS. > > We still have a long way to go before the framework and libraries are ready > for use in a commercial product but we are convinced that GNUstep is the way > to go and that it will attract many developers world wide to develop apps for > our platform once it is released. That's great! Will you be focusing on AppKit itself, or just reusing Foundation for a new UI API? > The first priority for us would be to complete CoreGraphics and CoreAnimation > and make these work properly with AppKit. As David said, Core Graphics API is implemented in a library we call Opal mostly written by Eric. I ran into problems with Opal as I worked on Core Animation, but it works okay, as long as one targets Opal first, and then ports to OS X or iOS (which is the recommended way to work with GNUstep anyway). I worked on Core Animation for last year's GSoC and it can be found in "quartzcore" library. For basic operation, it needs a just tiny bit of work; it needs to mark the rendering context as dirty and requiring a redraw. I wanted to do that by completing dynamic synthesis of properties at runtime, and simply marking the context as dirty when the setter is called. Also, "frame of next change" needs to be calculated; it'll be either zero (marking "as soon as possible", cca <refresh-rate-delay>ms in the future) or something larger. This would allow for avoiding continuous rendering of the screen. Then, shader for rendering shadow needs to be done, as well as calculating the on-screen size of a transformed layer. These are mostly tiny things, but I never got around to them. ---- Now, for integration with AppKit, primary blocker for proper integration of Core Animation is having a backend that can render into Opal's CGContext. Once that's done, I think most of integration can be done in a category. Using -setWantsLayer: would create a layer, and attach an OpenGL context to the view. This is already supported, and this is how NSOpenGLView already works. (It's mostly an NSView which gets an OpenGL overlay window added over it). I played a bit with OpenGL ES and if you look a bit into that hack in the quartzcore repository, you might have an easier time figuring out what I'm talking about. We just need to attach an OpenGL context, create a CARenderer, go down the view tree and tell all views to have a CALayer attached. Then, we have the CALayers request that the NSView paints the contents using Core Graphics API into the context that the CALayer provided. So, mostly doable with a small category on NSView -- perhaps we only need an NSDictionary i-var to store the layer, the renderer (if that view is the root of the hierarchy) and the value of wantsLayer property! ---- Last thing I want to get around to and which is interesting to you is implementation of CGL (Core GL) to permit decoupling of Core Animation from AppKit and to permit easier creation of OpenGL ES contexts in addition to desktop OpenGL contexts. Right now, our CA implementation depends on NSOpenGLContext instead of CGLContextObj or some other AppKit-independent object. > With this mail I'm hoping to start a dialog with you and discuss how we > together can bring GNUstep to it's full potential and spread Objective-C and > Cocoa outside of Apple's world. I'd personally be very happy to answer anything I know about GNUstep, and particularly about my small contributions to it! :-) -- Ivan Vučica [email protected] - http://ivan.vucica.net/
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
