Could GNUStep allow for iPhone porting to Android?

2011-09-28 Thread Jackie Gleason
I was playing around with a tutorial last night
here,
and it got me thinking...

Now I am a noob to GNUStep but my understanding is that with a certain
toolchain you can develop iOS apps. Although I am interested in this too,
last night got me thinking, could it be integrated into the gnustep make in
order to work with ndk-build? I'm sure there are a variety of hardware
virtualizing issues, however, seems very possible.

Anyone have thoughts?
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: Could GNUStep allow for iPhone porting to Android?

2011-09-28 Thread David Chisnall
On 28 Sep 2011, at 14:45, Jackie Gleason wrote:

> I was playing around with a tutorial last night here, and it got me 
> thinking...
> 
> Now I am a noob to GNUStep but my understanding is that with a certain 
> toolchain you can develop iOS apps. Although I am interested in this too, 
> last night got me thinking, could it be integrated into the gnustep make in 
> order to work with ndk-build? I'm sure there are a variety of hardware 
> virtualizing issues, however, seems very possible.
> 
> Anyone have thoughts?

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)
- 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...

David

--
This email complies with ISO 3103


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: Could GNUStep allow for iPhone porting to Android?

2011-09-28 Thread Ivan Vučica
On Wed, Sep 28, 2011 at 16:48, David Chisnall  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?


> - 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?
-- 
Ivan Vučica - i...@vucica.net
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: Could GNUStep allow for iPhone porting to Android?

2011-09-28 Thread David Chisnall

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

>> On Wed, Sep 28, 2011 at 16:48, David Chisnall  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


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: Could GNUStep allow for iPhone porting to Android?

2011-09-28 Thread Ivan Vučica
On Wed, Sep 28, 2011 at 16:32, David Chisnall  wrote:

> 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.
>

Sounds like something I *really* need to dig into.


>
> > 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.
>

That sounds awesome.
-- 
Ivan Vučica - i...@vucica.net
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: Could GNUStep allow for iPhone porting to Android?

2011-09-28 Thread David Chisnall
On 28 Sep 2011, at 20:52, Ivan Vučica wrote:

> On Wed, Sep 28, 2011 at 16:32, David Chisnall  wrote:
>> 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.
>> 
> Sounds like something I *really* need to dig into.

I'm not sure what the exact status of Opal is, but it was making some 
nice-looking demos (things like gradients and shadows working nicely for 
example) - maybe Eric can give an update.  The thing that's really needed is 
integration with the back end.

We discussed this a bit at FOSDEM, and the basic idea (I think) was that there 
would be a slight restructuring of the back end so that Opal would always do 
the drawing and the window management part would just be responsible for 
providing Cairo drawing contexts.  If you want to use a system without native 
Cairo support, you could just render to an image surface and then draw using 
something else.

Then FOSDEM ended, and no one had the time to implement any of this...

>>  > 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.
>> 
> That sounds awesome.

Unfortunately, sounding awesome is as far as it's got.  If you're looking for a 
project...

David

-- Send from my Jacquard Loom


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


FOSDEM 2012 (was: Re: Could GNUStep allow for iPhone porting to Android?)

2011-09-28 Thread Lars Sonchocky-Helldorf

Am 29.09.2011 um 00:07 schrieb David Chisnall:

> We discussed this a bit at FOSDEM, and the basic idea (I think) was that 
> there would be a slight restructuring of the back end so that Opal would 
> always do the drawing and the window management part would just be 
> responsible for providing Cairo drawing contexts.  If you want to use a 
> system without native Cairo support, you could just render to an image 
> surface and then draw using something else.
> 
> Then FOSDEM ended, and no one had the time to implement any of this...


Btw. the date for the next FOSDEM is out since some days:

> Von: Philip Paeps 
> Datum: 12. September 2011 00:26:44 MESZ
> An: fos...@lists.fosdem.org
> Betreff: [FOSDEM] Dates for FOSDEM 2012: 4 & 5 February
> Antwort an: FOSDEM announcements and visitor questions 
> 
> 
> 
> All, we have recently agreed with our venue that FOSDEM 2012 will take place
> on Saturday 4 and Sunday 5 February 2012.  It is safe to assume that there
> will also be a beer event as usual, on Friday 3 February 2012.
> 
> Looking forward to seeing everyone there.
> 
> - Philip
> 
> -- 
> Philip PaepsPlease don't Cc me, I am
> phi...@fosdem.orgsubscribed to the list.
> 
> 
> 
> ___
> FOSDEM mailing list
> fos...@lists.fosdem.org
> https://lists.fosdem.org/listinfo/fosdem



Are we going to participate in 2012?


cheers,

Lars
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev