Re: [GSoC Mentors Announce] Google Summer of Code 2013

[Ivan Vučica]

On 26. 2. 2013., at 12:52, David Chisnall <address@hidden> wrote:

> On 26 Feb 2013, at 08:21, Luboš Doležel <address@hidden> wrote:
> 
>> may I just ask what the intention behind implementing UIKit is?
>> Having fun / better abstraction somewhere / iOS apps on Android?
>> 
>> For the latter to be actually usable, we'd still need some sort of Android 
>> backend. I've seen Cairo working on Android, so it shouldn't be too 
>> difficult...
> 
> AppPortable has a UIKit implementation that runs on Android, using native 
> Android widgets.  An alternative would be to use the EGL back end for Cairo / 
> Opal and so have everything rendered via the NDK.  


I've laid out my thoughts previously back in 2011 [1], but here goes :-)

While Chameleon, the existing implementation of UIKit-over-AppKit, is 
absolutely amazing and works very well, I still believe that something that 
uses Core Animation and theoretically can be expanded to support everything 
that existing UIKit implementation (Apple's) can support. AppPortable's 
offering is probably excellent for apps; maybe not so much for games or getting 
as close results as possible to Apple's. If I had to grab something to quickly 
port an app and get support along with it, I'd go with AppPortable or, for GL 
games, with Yeeco's StellaSDK, or with some other offering on the market.

But, I think offering a mobile GUI for use with a mobile window manager on a 
mobile device is not a bad idea either. Building a project that can equally 
well run under an existing environment (e.g. rendering into an Android GL ES 
context and routing Android events into UIEvents), be used for development on 
desktops (in Xephyr and Xnest or even directly) and be used for running on an 
new platform while at the same time offering a recognizable and 
as-compatible-as-possible API... well, I think that's a good thing, too.

Aside from that, I can't propose other projects that I think are very important 
for GNUstep, primarily because every time I look at the relevant sections of 
code, I get lost. One of those projects is allowing rendering into 
-[NSGraphicsContext graphicsPort] using Opal, and adding -[NSView 
setWantsLayer:] which would create an NSOpenGLContext (or a CGLContext) on the 
relevant view (e.g. that view's parent, to avoid issues with clipping). This 
would allow for use of QuartzCore/Core Animation mixed with GNUstep's AppKit, 
and hence allow more complex transformations and animations of the GUI element 
than currently possible.

And -- adding backing with CALayers to NSView is (from what I understand) 
required for Chameleon. And since Chameleon exists, it makes little sense to 
replicate it just because of architectural limitations of GNUstep. Right? So 
reimplementing UIKit using AppKit doesn't sound interesting to me.

I feel I'd need a lot, lot, LOT of guidance for integration of Opal and QC, and 
may not even succeed in a reasonable time frame. I may be wrong, though, and it 
may be way simpler if someone who understands internals of AppKit laid out a 
(detailed?) plan and wrote an explanation of the internals :-)

Since I don't feel like I could do the required modifications, I propose the 
second best thing: starting to implement UIKit. If someone has a better and 
more interesting project, or can guide me in restructuring AppKit to integrate 
Opal and QuartzCore  -- let's discuss it!


[1]: http://lists.gnu.org/archive/html/discuss-gnustep/2011-09/msg00126.html


On 26. 2. 2013., at 09:23, Maxthon Chan <address@hidden> wrote:

> p.s. Is there any tool that converts Xcode project into Makefile?

Although this is completely unrelated, yes. Look into GNUstep's SVN repository, 
I think there is one tool that does just that (and another that builds directly 
from pbxproj).

--
Ivan Vučica
address@hidden - http://ivan.vucica.net/