Re: Could GNUStep allow for iPhone porting to Android?

[David Chisnall]

On 28 Sep 2011, at 17:03, Ivan Vučica wrote:

>> On Wed, Sep 28, 2011 at 16:48, David Chisnall <address@hidden> wrote:
>> 
>> It's something that we've discussed a few times.  There are two requirements 
>> for porting iOS apps to Android with GNUstep:
>> 
>> - An implementation of UIKit (GNUstep has the AppKit framework from OS X, 
>> not the UIKit framework from iOS)
> 
> Regarding UIKit, I thought of starting the design around painting UIKit in 
> generic OpenGL context, primarily because of heavy reliance on Core 
> Animation. However, that's probably not a good idea because any Quartz 
> implementation that GNUstep has would go unused in this scenario (and I'm not 
> very good with maths that deal with painting curves et al).
> 
> I haven't dealt with Cairo yet; would Cairo be a good thing to paint UIKit 
> with, instead of OpenGL?

We have a CoreGraphics implementation written on top of Cairo (Opal).  This 
would make sense for implementing UIKit, since custom views in UIKit will all 
use CoreGraphics.

Cairo supports rendering to an OpenGL texture.  Banlu did some work to render 
AppKit views to textures - this sort of thing would be a good base for the 
CoreAnimation stuff.

> 
>> - An Android back end (the part that handles drawing, window management, and 
>> event handling)
>> 
>> I am currently playing with the WebOS device that HP sent me.  GNUstep-base 
>> seems to be working nicely on it, but it only provides two ways of 
>> communicating with user are via HTML5 or SDL.  I will probably go the HTML5 
>> route for now.  I wanted the device to play with my Objective-C to 
>> JavaScript converter.  The Canvas API is basically a JavaScript binding to 
>> CoreGraphics, so implementing CoreGraphics on top of it should be relatively 
>> trivial, and that would make porting iOS apps relatively painless.  The same 
>> approach might work for Android, since it also has a WebKit / V8 browser...
>> 
>> Porting with Canvas API might be interesting, too. However, that would also 
>> be a limitation: what about embedded devices with no WebKit? WebKit is a 
>> larger thing to port than Cairo or software implementation of OpenGL/OpenGL 
>> ES
> 
> Targeting SDL and GL or SDL and Cairo might make things more universally 
> portable.
> 
> Any thoughts?

OpenGL doesn't make sense for 2D drawing - it lacks things like antialiased 
beziers, for example, which are the fundamental drawing primitive of all Cocoa 
stuff.  This needs to be layered on at a higher level, which is what Cairo does.

SDL makes some sense.  Gregory and I discussed this a while ago.  It's on the 
list of 'things that would be good if someone had time to work on them'.  I 
think Android has an SDL implementation, so if we could use SDL for events and 
window management, Cairo for drawing layers and OpenGL for compositing layers, 
then this would give us a back end that was fairly universally portable.

David

-- Sent from my STANTEC-ZEBRA