Re: New OS to use gnustep!

[David Chisnall]

Hi,

That's really awesome news!

We have a CoreGraphics implementation, mostly written by Eric, called Opal, but it's not integrated. Ivan also implemented a significant amount of CoreAnimation. Unfortunately, neither of them are integrated into the rest of the system.

The first step is probably to implement a back end using Opal. This would take the Display PostScript calls and call the CoreGraphics equivalents instead. Once this is done, you can mix CoreGraphics and AppKit drawing calls into the same context.

Integrating CoreAnimation is a bit more tricky. The current back end interface doesn't have a notion of layers. This would need to be added, along with some ability to have different rendering targets for different contexts.

Once that's done, there is room for some optimisation. For example, we should be able to draw views in different layers in parallel and cache the result so that we don't need to redraw the entire view hierarchy.

I think Gregory has done a little bit of work along the lines of integrating Opal with the back end, so maybe he can comment.

We're planning on having a developer meeting in Cambridge, probably at the end of June: it would be great if you could send someone along.

David

On 4 Mar 2013, at 07:04, "Lundberg, Johannes" <joha...@brilliantservice.co.jp> wrote:

> Hi all gnustep people!
>
> My name is Johannes Lundberg and I work for BRILLIANTSERVICE in Japan where I'm am leading the development of a new operating system called "Viking OS", especially designed for head mount displays.
>
> We believe that wearable devices (glasses, HMD) will replace the smartphones in a near future, and we are creating an OS based on BSD that will have special features like gesture control as main input method.
>
> 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.
>
> The first priority for us would be to complete CoreGraphics and CoreAnimation and make these work properly with AppKit.
>
>
> 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.
>
> We presented our OS together with a prototype HMD for the first time during MWC in Barcelona last week and the response was incredibly positive.
> Please look at our homepage or news articles from MWC. Further news will be posted on the blog.
>
> Viking OS blog
> http://hmdviking.blogspot.jp
>
> Viking OS homepage (download PDF pamphlet for more info, also attached to this mail)
> http://www.brilliantservice.co.jp/viking
>
> Laptop magazine
> http://blog.laptopmag.com/viking-ar-goggles
>
> All things D
> http://allthingsd.com/20130226/vikings-vision-for-a-cellphone-free-future/?refcat=news
>
> Best Regards
> --
> Johannes Lundberg
> BRILLIANTSERVICE CO., LTD.
> <viking-pamphlet.pdf>_______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep



-- Send from my Jacquard Loom

[Gregory Casamento]

Hi Johannes,

I agree this is exciting and wonderful news!

I am excited about the prospects which collaboration will bring.  I would love to talk further and see what we can do to make GNUstep everything you need it to be.

I am working on an Opal/CoreGraphics backend.  Time constraints and a new release of Gorm (GNUstep's Interface Builder) coming up have prevented me from devoting as much time as I would like to it.   I also think that Fred and Ivan are planning on working on this as well.  I should get back to it by Wednesday/Thursday since I am planning on making a Gorm release either tonight or tomorrow.

Greg

Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com

[Ivan Vučica]

Hello!

The concept looks great.

On 4. 3. 2013., at 08:04, "Lundberg, Johannes" <joha...@brilliantservice.co.jp> 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

iv...@vucica.net - http://ivan.vucica.net/

[Richard Frith-Macdonald]

On 4 Mar 2013, at 09:40, David Chisnall wrote:

> Hi,
>
> That's really awesome news!
>
> We have a CoreGraphics implementation, mostly written by Eric, called Opal, but it's not integrated. Ivan also implemented a significant amount of CoreAnimation. Unfortunately, neither of them are integrated into the rest of the system.
>
> The first step is probably to implement a back end using Opal. This would take the Display PostScript calls and call the CoreGraphics equivalents instead. Once this is done, you can mix CoreGraphics and AppKit drawing calls into the same context.
>
> Integrating CoreAnimation is a bit more tricky. The current back end interface doesn't have a notion of layers. This would need to be added, along with some ability to have different rendering targets for different contexts.
>
> Once that's done, there is room for some optimisation. For example, we should be able to draw views in different layers in parallel and cache the result so that we don't need to redraw the entire view hierarchy.
>
> I think Gregory has done a little bit of work along the lines of integrating Opal with the back end, so maybe he can comment.
>
> We're planning on having a developer meeting in Cambridge, probably at the end of June: it would be great if you could send someone along.

That sounds really good to me ... I'd like to get to Cambridge then (possibly bringing family) for the hackathon. Currently I'm free the last two weekends in June and the first in July (possibly I could take some time off during the week), but it would help if we had firmer dates.

[Ivan Vučica]

On 4. 3. 2013., at 16:10, Richard Frith-Macdonald <ric...@tiptree.demon.co.uk> wrote:

We're planning on having a developer meeting in Cambridge, probably at the end of June: it would be great if you could send someone along.  

That sounds really good to me ... I'd like to get to Cambridge then (possibly bringing family) for the hackathon.  Currently I'm free the last two weekends in June and the first in July (possibly I could take some time off during the week), but it would help if we had firmer dates.

Just so it's known: I'd love to join, and I think I'd be free at the end of June, but financial situation is blocking me from attending any meetings anywhere outside Croatia.

If anything changes, I'll chime in.

[Lundberg, Johannes]

Hi

Thank you very much for the positive replies.

I'd love to participate in the next meeting. I will make sure I can be there in person.

Regarding which libraries we need. Since we making a completely new device with new input systems we were also thinking about creating a new UI API from scratch but that is still under consideration.

Currently we are extending NSWIndow, NSView, etc for our "AppKit". Since GNUstep is GPL we have to consider which parts we can implement into GNUstep and keep open and which parts we keep proprietary. Of course, we want to contribute as much as we can to GNUstep.

For the demo apps we did for MWC I tried using both CG and CA libraries (opal) available but performance was too poor so I ended up using AppKit (NSView, NSBezierPath and so on) with cairo as backend. I tried activating cairo's OpenGL backend support but without success so we used X as backend for cairo.

At this time we are running our system on an Intel based laptop but the goal is to run on a small ARM-based device so OpenGL ES is the way to go. Core GL implementation is also interesting.

Thanks again!

Johannes

_______________________________________________
Discuss-gnustep mailing list
Discuss...@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

--

[David Chisnall]

On 5 Mar 2013, at 01:24, "Lundberg, Johannes" <joha...@brilliantservice.co.jp> wrote:

> Currently we are extending NSWIndow, NSView, etc for our "AppKit". Since GNUstep is GPL we have to consider which parts we can implement into GNUstep and keep open and which parts we keep proprietary. Of course, we want to contribute as much as we can to GNUstep.

Just one small clarification: GNUstep is LGPL (I am not a lawyer, none of this is legal advice). This means that you must:

- provide your customers with the sources for any changes that you make to the GNUstep libraries (obviously, we'd rather you pushed them upstream, but that's not a requirement)

- Allow your customers to relink their binaries against a modified version of GNUstep. This is almost always done by using shared libraries[1].

You are not, however, required to publish the code for anything that merely links against GNUstep, or uses the GNUstep headers. Specifically, inline functions and macros from GNUstep headers do not 'taint' your binary.

More pragmatically, from my experience on the FreeBSD Core Team[2], we have seen several companies learn that maintaining a proprietary fork of an open source project is often much more expensive than any loss of competitive advantage from releasing their changes.

David

[1] Note: There are several cases of big companies apparently violating this requirement of the LGPL. One of the most prominent is Apple with WebKit on iOS, where they do not allow iDevice owners to relink mobile Safari against a custom WebKit. To my knowledge, this has never been tested in court in any jurisdiction.

[2] Totally off-topic, but you didn't say what kernel / userland you were planning on putting under GNUstep. We have a very nice one, and it is the one where Clang and libobjc2 receive the most testing...

-- Sent from my IBM 1620

[Lundberg, Johannes]

Hi

Just one small clarification: GNUstep is LGPL (I am not a lawyer, none of this is legal advice).  This means that you must:

Yes, I know. Sorry, it was an error in writing.
 

- provide your customers with the sources for any changes that you make to the GNUstep libraries (obviously, we'd rather you pushed them upstream, but that's not a requirement)

That's the plan.
 

You are not, however, required to publish the code for anything that merely links against GNUstep, or uses the GNUstep headers.  Specifically, inline functions and macros from GNUstep headers do not 'taint' your binary.

Yeah, that's were we hope to be able to put our proprietary code.
 

More pragmatically, from my experience on the FreeBSD Core Team[2], we have seen several companies learn that maintaining a proprietary fork of an open source project is often much more expensive than any loss of competitive advantage from releasing their changes.

Our goal is to release as much as we can to contribute to the GNUstep developer community.
 

David

[1] Note: There are several cases of big companies apparently violating this requirement of the LGPL.  One of the most prominent is Apple with WebKit on iOS, where they do not allow iDevice owners to relink mobile Safari against a custom WebKit.  To my knowledge, this has never been tested in court in any jurisdiction.

I can imaging that allowing this would mean serious security risks... Interesting case however.
 

[2] Totally off-topic, but you didn't say what kernel / userland you were planning on putting under GNUstep.  We have a very nice one, and it is the one where Clang and libobjc2 receive the most testing...

By "we", do you mean FreeBSD? Actually we are considering FreeBSD 10.