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

[Ivan Vučica]

I think so!

Just to note, David has already registered as a mentor; I don't have any 
specific idea how to work things out in this situation, but what I do have is 
appreciation for all the mentoring and help during the planning and coding 
phase that I can -- and apparently will -- get :-)

I did not submit my proposal yet, I'll post it to the lists when I do. 

Just to add for interested parties: Mailing list for coordination within GNU is 
summer-of-c...@gnu.org, in case someone wants to track that.

Regards,

Ivan Vučica
via phone

On 29. 4. 2013., at 10:22, Eric Wasylishen  wrote:

> Hi Fred, Ivan,
> 
> I'd be interested in mentoring a backend/Opal related project, or at least 
> offering guidance if we have a mentor already.
> I guess I have to register on the GSoC site?
> 
> Eric
> 
> On 2013-04-24, at 5:56 PM, Fred Kiefer  wrote:
> 
>> I thought again and I may be able to stand in as a backup mentor for your 
>> project. Not the main mentor, joining in later this summer to help out. I 
>> will try to register as a mentor, but you will still need an official 
>> mentor. Apart for the usual candidates as Richard and Greg I would like to 
>> suggest Eric and Niels. They both were excellent students at the GSoC 
>> themselves and would be able to pass on that experience to other students. 
>> And they are highly knowledgeable in the area.
>> 
>> Fred
>> 
>> On 24.04.2013 13:44, Ivan Vučica wrote:
>>> First, thanks everyone for support and ideas!
>>> 
>>> On Tue, Apr 23, 2013 at 12:02 AM, Fred Kiefer  wrote:
>>> 
 Hi Ivan
 
 I had long ago decided that I wont mentor for GSoC this year, but your
 mail led me to rethink that position. Your proposal is very convincing and
 would be highly beneficial for GNUstep. ...
 
 Sorry, but I wont be able to step in here. Hopefully somebody else in the
 GNUstep community will.
>>> 
>>> Thanks!
>>> 
 Best wishes and hope to see you in Cambridge,
>>> 
>>> 
>>> Ditto!
>>> 
>>> On Tue, Apr 23, 2013 at 9:31 AM, David Chisnall  wrote:
>>> 
 On 22 Apr 2013, at 21:43, Ivan Vučica  wrote:
 
> Ping! Student registrations have started. Any prospective mentors?
 
 I've registered as a mentor.  I'd also be most interested in the back end
 being refactored to support using Opal.
>>> 
>>> Based on feedback everyone gave, yes, the importance of this (and the
>>> importance of integration with Core Animation) seems to be the consensus.
>>> 
>>> Currently, basic idea that I have is to copy the entire Cairo backend (or
>>> maybe use derived classes, although long-term that seems a bad idea) and
>>> ensure that every Cairo surface is instead backed with an Opal context. I'd
>>> temporarily expose the Cairo surface from the Opal context, and ensure that
>>> calls are directed to the Cairo surface backing the Opal context instead of
>>> to the Cairo surface inside the backend.
>>> 
>>> Then, I'd be removing the Cairo surface from the backend and replacing
>>> Cairo calls with Opal calls.
>>> 
>>> Finally, I would be continuously looking at options for integrating Core
>>> Animation with AppKit (based on feedback).
>>> 
>>> I'll probably need more supervision compared to implementation of UIKit,
>>> but this is definitely a more useful long-term project for GNUstep.
>>> 
>>> I'll put together a proposal, register it on GSoC's Melange, and also send
>>> it to the mailing list.
>> 
>> 
>> ___
>> Gnustep-dev mailing list
>> Gnustep-dev@gnu.org
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

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

[Eric Wasylishen]

Hi Fred, Ivan,

I'd be interested in mentoring a backend/Opal related project, or at least 
offering guidance if we have a mentor already.
I guess I have to register on the GSoC site?

Eric

On 2013-04-24, at 5:56 PM, Fred Kiefer  wrote:

> I thought again and I may be able to stand in as a backup mentor for your 
> project. Not the main mentor, joining in later this summer to help out. I 
> will try to register as a mentor, but you will still need an official mentor. 
> Apart for the usual candidates as Richard and Greg I would like to suggest 
> Eric and Niels. They both were excellent students at the GSoC themselves and 
> would be able to pass on that experience to other students. And they are 
> highly knowledgeable in the area.
> 
> Fred
> 
> On 24.04.2013 13:44, Ivan Vučica wrote:
>> First, thanks everyone for support and ideas!
>> 
>> On Tue, Apr 23, 2013 at 12:02 AM, Fred Kiefer  wrote:
>> 
>>> Hi Ivan
>>> 
>>> I had long ago decided that I wont mentor for GSoC this year, but your
>>> mail led me to rethink that position. Your proposal is very convincing and
>>> would be highly beneficial for GNUstep. ...
>>> 
>>> Sorry, but I wont be able to step in here. Hopefully somebody else in the
>>> GNUstep community will.
>>> 
>> 
>> Thanks!
>> 
>>> Best wishes and hope to see you in Cambridge,
>> 
>> 
>> Ditto!
>> 
>> On Tue, Apr 23, 2013 at 9:31 AM, David Chisnall  wrote:
>> 
>>> On 22 Apr 2013, at 21:43, Ivan Vučica  wrote:
>>> 
 Ping! Student registrations have started. Any prospective mentors?
>>> 
>>> I've registered as a mentor.  I'd also be most interested in the back end
>>> being refactored to support using Opal.
>>> 
>> 
>> Based on feedback everyone gave, yes, the importance of this (and the
>> importance of integration with Core Animation) seems to be the consensus.
>> 
>> Currently, basic idea that I have is to copy the entire Cairo backend (or
>> maybe use derived classes, although long-term that seems a bad idea) and
>> ensure that every Cairo surface is instead backed with an Opal context. I'd
>> temporarily expose the Cairo surface from the Opal context, and ensure that
>> calls are directed to the Cairo surface backing the Opal context instead of
>> to the Cairo surface inside the backend.
>> 
>> Then, I'd be removing the Cairo surface from the backend and replacing
>> Cairo calls with Opal calls.
>> 
>> Finally, I would be continuously looking at options for integrating Core
>> Animation with AppKit (based on feedback).
>> 
>> I'll probably need more supervision compared to implementation of UIKit,
>> but this is definitely a more useful long-term project for GNUstep.
>> 
>> I'll put together a proposal, register it on GSoC's Melange, and also send
>> it to the mailing list.
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


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

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

[Fred Kiefer]

On 26.04.2013 09:13, David Chisnall wrote:

On 26 Apr 2013, at 07:41, "Lundberg, Johannes"
 wrote:


While we're discussing lower level graphics API I would like to ask
one more thing.

What would it take to run GNUstep on DirectFB instead of X? Is this
possible at this time?


Someone did create a DirectFB back end, but it was never pushed
upstream.  I'm not sure it's such an interesting target anymore,
because with GLES hardware becoming ubiquitous it's more important to
be able to offload rendering to the GPU (for power efficiency, and
also to do compositing of complex UIs at a reasonable speed).

Note that there are three parts to a back end:

- The rendering part, which is responsible for managing graphics
contexts and putting pixels on the screen (or not - it would be nice
to have a stub back end for headless applications that wanted to use
AppKit things for PDF rendering and so on)

- The input handling part, which is responsible for mapping host
system input events to NSEvents for the correct target.

- The host environment integration, which includes things like
exposing the same fonts as other applications and ensuring that
copy-and-paste / drag-and-drop work with non-GNUstep applications.

These are not entirely separated in the back end.  It would be nice
for Ivan's GSoC project to disentangle them a bit more so that each
nominal back end is formed by cleanly composing classes for each of
these things.  For example, DirectFB will want to supply its own
event handling, but will reuse the font management via FreeType and
will reuse the drawing from Cairo / Opal, but will provide its own
graphics context setup code.


We already have a few of the suggested splits in GNUstep back. When Adam 
rewrote the overall backend structure more than ten years ago we added a 
split between the class handling the drawing (a subclass of 
NSGraphicsContext) and the class handling events, resources and 
environment interaction (a subclass of GSDisplayServer). Font 
enumeration gets handled by subclasses of GSFontEnumerator and the 
copy-and-paste code is even in a separate tool. For D&D we currently 
only have minimal support, the code needs to be moved into to normal 
event handling to actually work.


In your DirectFB example the FreeType (or rather FontConfig?) support 
could be directly reused from the cairo backend code and the event and 
window handling are the bits that need to be written. I would think that 
they belong into the same class, as that class will need to know about 
which window an event should be send to and stuff like that, but you 
could argue here.


There are a lot of things that need a better structure in gui and back, 
for example font descriptors to make the integration of Opal as a 
backend easier. But support for a DirectFB backend should be fairly 
simple even for the current structure.


Fred



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

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

[Lundberg, Johannes]

We're basing our system on FreeBSD and there seems to be a DirectFB port,
however I don't know how complete it is. For our purpose, as long as it
runs on BSD, it's OK.

Johannes Lundberg
BRILLIANTSERVICE CO., LTD. 


On Fri, Apr 26, 2013 at 6:46 PM, Ivan Vučica  wrote:

> I think David refers to the need to cache as much drawables into
> OpenGL/OpenGL ES textures as possible and then composite them on screen
> using OpenGL/OpenGL ES. Putting pixels and updating them using 2D drawing
> commands ("put a rectangle here", "copy this rectangle into this
> rectangle") stops paying off at some point. For example, if you have a lot
> of alpha blending, or UI that animates without changing its own content, it
> probably makes little sense to do compositing in software.
>
> I'm not too familiar with DirectFB; does it expose a way to create an
> OpenGL context?
>
> Regards,
>
> Ivan Vučica
> via phone
>
> On 26. 4. 2013., at 11:32, "Lundberg, Johannes" <
> johan...@brilliantservice.co.jp> wrote:
>
> Do you mean that if rendering is offloaded to the CPU the performance
> gained from moving from X to DirectFB is not that big?
>
> For our head mount display all events will be generated from things like
> gestures and voice control so we don't really need X for input events.
>
> Johannes Lundberg
> BRILLIANTSERVICE CO., LTD. 
>
>
> On Fri, Apr 26, 2013 at 5:53 PM, Ivan Vučica  wrote:
>
>> On 26. 4. 2013., at 09:13, David Chisnall  wrote:
>>
>> > On 26 Apr 2013, at 07:41, "Lundberg, Johannes" <
>> johan...@brilliantservice.co.jp> wrote:
>> >
>> >> While we're discussing lower level graphics API I would like to ask
>> one more thing.
>> >>
>> >> What would it take to run GNUstep on DirectFB instead of X? Is this
>> possible at this time?
>> >
>> > Someone did create a DirectFB back end, but it was never pushed
>> upstream.  I'm not sure it's such an interesting target anymore, because
>> with GLES hardware becoming ubiquitous it's more important to be able to
>> offload rendering to the GPU (for power efficiency, and also to do
>> compositing of complex UIs at a reasonable speed).
>> >
>> > Note that there are three parts to a back end:
>> >
>> > - The rendering part, which is responsible for managing graphics
>> contexts and putting pixels on the screen (or not - it would be nice to
>> have a stub back end for headless applications that wanted to use AppKit
>> things for PDF rendering and so on)
>> >
>> > - The input handling part, which is responsible for mapping host system
>> input events to NSEvents for the correct target.
>> >
>> > - The host environment integration, which includes things like exposing
>> the same fonts as other applications and ensuring that copy-and-paste /
>> drag-and-drop work with non-GNUstep applications.
>> >
>> > These are not entirely separated in the back end.  It would be nice for
>> Ivan's GSoC project to disentangle them a bit more so that each nominal
>> back end is formed by cleanly composing classes for each of these things.
>>  For example, DirectFB will want to supply its own event handling, but will
>> reuse the font management via FreeType and will reuse the drawing from
>> Cairo / Opal, but will provide its own graphics context setup code.
>> >
>> > David
>> >
>> > -- Sent from my Cray X1
>> >
>>
>> I'll take a look and try to integrate some of that into the proposal. :-)
>>
>> Regards,
>>
>> Ivan Vučica
>> via phone
>>
>
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

[Ivan Vučica]

I think David refers to the need to cache as much drawables into OpenGL/OpenGL 
ES textures as possible and then composite them on screen using OpenGL/OpenGL 
ES. Putting pixels and updating them using 2D drawing commands ("put a 
rectangle here", "copy this rectangle into this rectangle") stops paying off at 
some point. For example, if you have a lot of alpha blending, or UI that 
animates without changing its own content, it probably makes little sense to do 
compositing in software.

I'm not too familiar with DirectFB; does it expose a way to create an OpenGL 
context?

Regards,

Ivan Vučica
via phone

On 26. 4. 2013., at 11:32, "Lundberg, Johannes" 
 wrote:

> Do you mean that if rendering is offloaded to the CPU the performance gained 
> from moving from X to DirectFB is not that big?
> 
> For our head mount display all events will be generated from things like 
> gestures and voice control so we don't really need X for input events.
> 
> Johannes Lundberg
> BRILLIANTSERVICE CO., LTD.
> 
> 
> On Fri, Apr 26, 2013 at 5:53 PM, Ivan Vučica  wrote:
>> On 26. 4. 2013., at 09:13, David Chisnall  wrote:
>> 
>> > On 26 Apr 2013, at 07:41, "Lundberg, Johannes" 
>> >  wrote:
>> >
>> >> While we're discussing lower level graphics API I would like to ask one 
>> >> more thing.
>> >>
>> >> What would it take to run GNUstep on DirectFB instead of X? Is this 
>> >> possible at this time?
>> >
>> > Someone did create a DirectFB back end, but it was never pushed upstream.  
>> > I'm not sure it's such an interesting target anymore, because with GLES 
>> > hardware becoming ubiquitous it's more important to be able to offload 
>> > rendering to the GPU (for power efficiency, and also to do compositing of 
>> > complex UIs at a reasonable speed).
>> >
>> > Note that there are three parts to a back end:
>> >
>> > - The rendering part, which is responsible for managing graphics contexts 
>> > and putting pixels on the screen (or not - it would be nice to have a stub 
>> > back end for headless applications that wanted to use AppKit things for 
>> > PDF rendering and so on)
>> >
>> > - The input handling part, which is responsible for mapping host system 
>> > input events to NSEvents for the correct target.
>> >
>> > - The host environment integration, which includes things like exposing 
>> > the same fonts as other applications and ensuring that copy-and-paste / 
>> > drag-and-drop work with non-GNUstep applications.
>> >
>> > These are not entirely separated in the back end.  It would be nice for 
>> > Ivan's GSoC project to disentangle them a bit more so that each nominal 
>> > back end is formed by cleanly composing classes for each of these things.  
>> > For example, DirectFB will want to supply its own event handling, but will 
>> > reuse the font management via FreeType and will reuse the drawing from 
>> > Cairo / Opal, but will provide its own graphics context setup code.
>> >
>> > David
>> >
>> > -- Sent from my Cray X1
>> >
>> 
>> I'll take a look and try to integrate some of that into the proposal. :-)
>> 
>> Regards,
>> 
>> Ivan Vučica
>> via phone
> 
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

[David Chisnall]

On 26 Apr 2013, at 10:32, "Lundberg, Johannes" 
 wrote:

> Do you mean that if rendering is offloaded to the CPU the performance gained 
> from moving from X to DirectFB is not that big?

DirectFB is a Linux (not-really portable) API that was designed to give direct 
access to the framebuffer for unaccelerated rendering.  It now enables you to 
create an OpenGL context, but there's not really any advantage of this over 
direct rendering in X11 - you're just using either one as an API to give you a 
full-screen GL context and then asking it to get out of the way.  

> For our head mount display all events will be generated from things like 
> gestures and voice control so we don't really need X for input events.

The overhead of X isn't that big when you're doing full-screen OpenGL 
rendering.  You're probably better off following the Android model though, and 
sitting directly on top of the GLES driver.  

David

-- Sent from my PDP-11


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

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

[Lundberg, Johannes]

Do you mean that if rendering is offloaded to the CPU the performance
gained from moving from X to DirectFB is not that big?

For our head mount display all events will be generated from things like
gestures and voice control so we don't really need X for input events.

Johannes Lundberg
BRILLIANTSERVICE CO., LTD. 


On Fri, Apr 26, 2013 at 5:53 PM, Ivan Vučica  wrote:

> On 26. 4. 2013., at 09:13, David Chisnall  wrote:
>
> > On 26 Apr 2013, at 07:41, "Lundberg, Johannes" <
> johan...@brilliantservice.co.jp> wrote:
> >
> >> While we're discussing lower level graphics API I would like to ask one
> more thing.
> >>
> >> What would it take to run GNUstep on DirectFB instead of X? Is this
> possible at this time?
> >
> > Someone did create a DirectFB back end, but it was never pushed
> upstream.  I'm not sure it's such an interesting target anymore, because
> with GLES hardware becoming ubiquitous it's more important to be able to
> offload rendering to the GPU (for power efficiency, and also to do
> compositing of complex UIs at a reasonable speed).
> >
> > Note that there are three parts to a back end:
> >
> > - The rendering part, which is responsible for managing graphics
> contexts and putting pixels on the screen (or not - it would be nice to
> have a stub back end for headless applications that wanted to use AppKit
> things for PDF rendering and so on)
> >
> > - The input handling part, which is responsible for mapping host system
> input events to NSEvents for the correct target.
> >
> > - The host environment integration, which includes things like exposing
> the same fonts as other applications and ensuring that copy-and-paste /
> drag-and-drop work with non-GNUstep applications.
> >
> > These are not entirely separated in the back end.  It would be nice for
> Ivan's GSoC project to disentangle them a bit more so that each nominal
> back end is formed by cleanly composing classes for each of these things.
>  For example, DirectFB will want to supply its own event handling, but will
> reuse the font management via FreeType and will reuse the drawing from
> Cairo / Opal, but will provide its own graphics context setup code.
> >
> > David
> >
> > -- Sent from my Cray X1
> >
>
> I'll take a look and try to integrate some of that into the proposal. :-)
>
> Regards,
>
> Ivan Vučica
> via phone
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

[Ivan Vučica]

On 26. 4. 2013., at 09:13, David Chisnall  wrote:

> On 26 Apr 2013, at 07:41, "Lundberg, Johannes" 
>  wrote:
> 
>> While we're discussing lower level graphics API I would like to ask one more 
>> thing.
>> 
>> What would it take to run GNUstep on DirectFB instead of X? Is this possible 
>> at this time?
> 
> Someone did create a DirectFB back end, but it was never pushed upstream.  
> I'm not sure it's such an interesting target anymore, because with GLES 
> hardware becoming ubiquitous it's more important to be able to offload 
> rendering to the GPU (for power efficiency, and also to do compositing of 
> complex UIs at a reasonable speed).  
> 
> Note that there are three parts to a back end:
> 
> - The rendering part, which is responsible for managing graphics contexts and 
> putting pixels on the screen (or not - it would be nice to have a stub back 
> end for headless applications that wanted to use AppKit things for PDF 
> rendering and so on)
> 
> - The input handling part, which is responsible for mapping host system input 
> events to NSEvents for the correct target.
> 
> - The host environment integration, which includes things like exposing the 
> same fonts as other applications and ensuring that copy-and-paste / 
> drag-and-drop work with non-GNUstep applications.
> 
> These are not entirely separated in the back end.  It would be nice for 
> Ivan's GSoC project to disentangle them a bit more so that each nominal back 
> end is formed by cleanly composing classes for each of these things.  For 
> example, DirectFB will want to supply its own event handling, but will reuse 
> the font management via FreeType and will reuse the drawing from Cairo / 
> Opal, but will provide its own graphics context setup code.  
> 
> David
> 
> -- Sent from my Cray X1
> 

I'll take a look and try to integrate some of that into the proposal. :-)

Regards,

Ivan Vučica
via phone
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

[David Chisnall]

On 26 Apr 2013, at 07:41, "Lundberg, Johannes" 
 wrote:

> While we're discussing lower level graphics API I would like to ask one more 
> thing.
> 
> What would it take to run GNUstep on DirectFB instead of X? Is this possible 
> at this time?

Someone did create a DirectFB back end, but it was never pushed upstream.  I'm 
not sure it's such an interesting target anymore, because with GLES hardware 
becoming ubiquitous it's more important to be able to offload rendering to the 
GPU (for power efficiency, and also to do compositing of complex UIs at a 
reasonable speed).  

Note that there are three parts to a back end:

- The rendering part, which is responsible for managing graphics contexts and 
putting pixels on the screen (or not - it would be nice to have a stub back end 
for headless applications that wanted to use AppKit things for PDF rendering 
and so on)

- The input handling part, which is responsible for mapping host system input 
events to NSEvents for the correct target.

- The host environment integration, which includes things like exposing the 
same fonts as other applications and ensuring that copy-and-paste / 
drag-and-drop work with non-GNUstep applications.

These are not entirely separated in the back end.  It would be nice for Ivan's 
GSoC project to disentangle them a bit more so that each nominal back end is 
formed by cleanly composing classes for each of these things.  For example, 
DirectFB will want to supply its own event handling, but will reuse the font 
management via FreeType and will reuse the drawing from Cairo / Opal, but will 
provide its own graphics context setup code.  

David

-- Sent from my Cray X1


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

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

[Lundberg, Johannes]

While we're discussing lower level graphics API I would like to ask one
more thing.

What would it take to run GNUstep on DirectFB instead of X? Is this
possible at this time?

Johannes Lundberg
BRILLIANTSERVICE CO., LTD. 


On Thu, Apr 25, 2013 at 7:57 AM, Ivan Vučica  wrote:

> Thank you!
>
> All assistance will be greatly appreciated.
>
> On 24. 4. 2013., at 23:56, Fred Kiefer  wrote:
>
> I thought again and I may be able to stand in as a backup mentor for your
> project. Not the main mentor, joining in later this summer to help out. I
> will try to register as a mentor, but you will still need an official
> mentor. Apart for the usual candidates as Richard and Greg I would like to
> suggest Eric and Niels. They both were excellent students at the GSoC
> themselves and would be able to pass on that experience to other students.
> And they are highly knowledgeable in the area.
>
> Fred
>
> On 24.04.2013 13:44, Ivan Vučica wrote:
>
> First, thanks everyone for support and ideas!
>
> On Tue, Apr 23, 2013 at 12:02 AM, Fred Kiefer  wrote:
>
> Hi Ivan
>
> I had long ago decided that I wont mentor for GSoC this year, but your
> mail led me to rethink that position. Your proposal is very convincing and
> would be highly beneficial for GNUstep. ...
>
> Sorry, but I wont be able to step in here. Hopefully somebody else in the
> GNUstep community will.
>
>
> Thanks!
>
> Best wishes and hope to see you in Cambridge,
>
>
>
> Ditto!
>
> On Tue, Apr 23, 2013 at 9:31 AM, David Chisnall  wrote:
>
> On 22 Apr 2013, at 21:43, Ivan Vučica  wrote:
>
> Ping! Student registrations have started. Any prospective mentors?
>
>
> I've registered as a mentor.  I'd also be most interested in the back end
> being refactored to support using Opal.
>
>
> Based on feedback everyone gave, yes, the importance of this (and the
> importance of integration with Core Animation) seems to be the consensus.
>
> Currently, basic idea that I have is to copy the entire Cairo backend (or
> maybe use derived classes, although long-term that seems a bad idea) and
> ensure that every Cairo surface is instead backed with an Opal context. I'd
> temporarily expose the Cairo surface from the Opal context, and ensure that
> calls are directed to the Cairo surface backing the Opal context instead of
> to the Cairo surface inside the backend.
>
> Then, I'd be removing the Cairo surface from the backend and replacing
> Cairo calls with Opal calls.
>
> Finally, I would be continuously looking at options for integrating Core
> Animation with AppKit (based on feedback).
>
> I'll probably need more supervision compared to implementation of UIKit,
> but this is definitely a more useful long-term project for GNUstep.
>
> I'll put together a proposal, register it on GSoC's Melange, and also send
> it to the mailing list.
>
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
> --
> Ivan Vučica
> i...@vucica.net - http://ivan.vucica.net/
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

[Ivan Vučica]

Thank you!

All assistance will be greatly appreciated.

On 24. 4. 2013., at 23:56, Fred Kiefer  wrote:

> I thought again and I may be able to stand in as a backup mentor for your 
> project. Not the main mentor, joining in later this summer to help out. I 
> will try to register as a mentor, but you will still need an official mentor. 
> Apart for the usual candidates as Richard and Greg I would like to suggest 
> Eric and Niels. They both were excellent students at the GSoC themselves and 
> would be able to pass on that experience to other students. And they are 
> highly knowledgeable in the area.
> 
> Fred
> 
> On 24.04.2013 13:44, Ivan Vučica wrote:
>> First, thanks everyone for support and ideas!
>> 
>> On Tue, Apr 23, 2013 at 12:02 AM, Fred Kiefer  wrote:
>> 
>>> Hi Ivan
>>> 
>>> I had long ago decided that I wont mentor for GSoC this year, but your
>>> mail led me to rethink that position. Your proposal is very convincing and
>>> would be highly beneficial for GNUstep. ...
>>> 
>>> Sorry, but I wont be able to step in here. Hopefully somebody else in the
>>> GNUstep community will.
>>> 
>> 
>> Thanks!
>> 
>>> Best wishes and hope to see you in Cambridge,
>> 
>> 
>> Ditto!
>> 
>> On Tue, Apr 23, 2013 at 9:31 AM, David Chisnall  wrote:
>> 
>>> On 22 Apr 2013, at 21:43, Ivan Vučica  wrote:
>>> 
 Ping! Student registrations have started. Any prospective mentors?
>>> 
>>> I've registered as a mentor.  I'd also be most interested in the back end
>>> being refactored to support using Opal.
>>> 
>> 
>> Based on feedback everyone gave, yes, the importance of this (and the
>> importance of integration with Core Animation) seems to be the consensus.
>> 
>> Currently, basic idea that I have is to copy the entire Cairo backend (or
>> maybe use derived classes, although long-term that seems a bad idea) and
>> ensure that every Cairo surface is instead backed with an Opal context. I'd
>> temporarily expose the Cairo surface from the Opal context, and ensure that
>> calls are directed to the Cairo surface backing the Opal context instead of
>> to the Cairo surface inside the backend.
>> 
>> Then, I'd be removing the Cairo surface from the backend and replacing
>> Cairo calls with Opal calls.
>> 
>> Finally, I would be continuously looking at options for integrating Core
>> Animation with AppKit (based on feedback).
>> 
>> I'll probably need more supervision compared to implementation of UIKit,
>> but this is definitely a more useful long-term project for GNUstep.
>> 
>> I'll put together a proposal, register it on GSoC's Melange, and also send
>> it to the mailing list.
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

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

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

[Fred Kiefer]

I thought again and I may be able to stand in as a backup mentor for 
your project. Not the main mentor, joining in later this summer to help 
out. I will try to register as a mentor, but you will still need an 
official mentor. Apart for the usual candidates as Richard and Greg I 
would like to suggest Eric and Niels. They both were excellent students 
at the GSoC themselves and would be able to pass on that experience to 
other students. And they are highly knowledgeable in the area.


Fred

On 24.04.2013 13:44, Ivan Vučica wrote:

First, thanks everyone for support and ideas!

On Tue, Apr 23, 2013 at 12:02 AM, Fred Kiefer  wrote:


Hi Ivan

I had long ago decided that I wont mentor for GSoC this year, but your
mail led me to rethink that position. Your proposal is very convincing and
would be highly beneficial for GNUstep. ...

Sorry, but I wont be able to step in here. Hopefully somebody else in the
GNUstep community will.



Thanks!


Best wishes and hope to see you in Cambridge,



Ditto!

On Tue, Apr 23, 2013 at 9:31 AM, David Chisnall  wrote:


On 22 Apr 2013, at 21:43, Ivan Vučica  wrote:


Ping! Student registrations have started. Any prospective mentors?


I've registered as a mentor.  I'd also be most interested in the back end
being refactored to support using Opal.



Based on feedback everyone gave, yes, the importance of this (and the
importance of integration with Core Animation) seems to be the consensus.

Currently, basic idea that I have is to copy the entire Cairo backend (or
maybe use derived classes, although long-term that seems a bad idea) and
ensure that every Cairo surface is instead backed with an Opal context. I'd
temporarily expose the Cairo surface from the Opal context, and ensure that
calls are directed to the Cairo surface backing the Opal context instead of
to the Cairo surface inside the backend.

Then, I'd be removing the Cairo surface from the backend and replacing
Cairo calls with Opal calls.

Finally, I would be continuously looking at options for integrating Core
Animation with AppKit (based on feedback).

I'll probably need more supervision compared to implementation of UIKit,
but this is definitely a more useful long-term project for GNUstep.

I'll put together a proposal, register it on GSoC's Melange, and also send
it to the mailing list.



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

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

[Dr. H. Nikolaus Schaller]

Am 22.04.2013 um 22:43 schrieb Ivan Vučica:

> Ping! Student registrations have started. Any prospective mentors?
> 
> (Crossposting this to discuss-gnustep.)
> 
> On Sat, Apr 20, 2013 at 6:31 PM, Ivan Vučica  wrote:
> Hello all,
> 
> In the end, I only played with compiling Base for Android since writing the 
> previous mail. But, here's some bad news -- that happen to be good for my 
> contributions to GNUstep :-) 
> 
> It looks like I'll be free from the part-time job that I had last summer. So, 
> any frustration that Fred may have had with me during Google Summer of Code 
> should hopefully go away this year. That, of course, if someone still happens 
> to think I can contribute interesting things :-)
> 
> I've thought a bit more about potential contributions for this GSoC, if 
> someone chooses to mentor me and GNUstep gets a GNU slot. Here they are, in 
> order of how "independently" I could implement them.
> 
> - UIKit. An implementation of UIKit, along with fixes to QuartzCore needed to 
> make this happen (and to improve performance). I can mostly do this on my 
> own, except for code review, advice and discussion that would improve the 
> work.
> - Core Data persistence. From what I understand, there is a basic 
> implementation of Core Data for GNUstep. I could work on extending it with 
> implementations of NSAtomicStore and NSIncrementalStore. I would not focus 
> too much on multithreading, migration, lightweight migration, context 
> merging, etc.

Yes, it is here including a DataBuilder - but the model files are not Cocoa 
compatible :-(

http://www.gnustep.org/softwareindex/showdetail.php?app=94

> - Integration of QuartzCore into AppKit. This also requires a lot of 
> handholding. Sadly, I don't quite have the "big picture" in my head of how 
> GNUstep GUI works, especially the backends.
> 
> I'm of course most interested in things that do with QC, since I already 
> spent a lot of time on Core Animation.
> 
> Is someone willing to mentor me for GSoC? Student applications start on 
> Monday. It might also make sense to make an announcement at 
> summer-of-c...@gnu.org; maybe a more interesting candidate than me appears 
> (or maybe GNU chooses to give us two slots). 
> 
> On Mon, Feb 25, 2013 at 11:17 AM, Ivan Vučica  wrote:
> I think it might also be a better year for me to participate as well.
> 
> I'd start preparing this week by working on:
> - an OpenGL and OpenGL ES wrapper that would be usable by not just AppKit 
> apps (a thin wrapper around GLX that uses CGL API)
> - by moving QuartzCore to use that instead of AppKit
> 
> If I have some results by the deadline for student registration, I would feel 
> confident to register this year, so it gets to be an even better experience 
> for everyone :-)
> 
> The project would be: an implementation of parts of UIKit, along with 
> patching QuartzCore where needed.
> 
> Thoughts?
> 
> Regards,
> 
> Ivan Vučica
> via phone
> 
> On 25. 2. 2013., at 09:19, Fred Kiefer  wrote:
> 
> > Just to remind you. As every year, the Google Summer of Code is approaching 
> > and we need to decide, whether we are going to participate. Last year I 
> > mentored Ivan and it was great fun and of course I learned a lot. Still it 
> > was the wrong year for me to do so, I didn't have enough free time to 
> > really fill up the role of a mentor. This year I should have more time for 
> > this but would prefer to pass on the mentor role to somebody else. And of 
> > course we should only participate if we can find suitable students.
> >
> > Fred 
> 
> -- 
> Ivan Vučica - i...@vucica.net
> 
> 
> 
> 
> 
> -- 
> Ivan Vučica - i...@vucica.net
> 
> ___
> Discuss-gnustep mailing list
> discuss-gnus...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


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

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

[Ivan Vučica]

First, thanks everyone for support and ideas!

On Tue, Apr 23, 2013 at 12:02 AM, Fred Kiefer  wrote:

> Hi Ivan
>
> I had long ago decided that I wont mentor for GSoC this year, but your
> mail led me to rethink that position. Your proposal is very convincing and
> would be highly beneficial for GNUstep. Then before I had the time to write
> a mail another thing happened. An old friend of mine asked me to take over
> the mentoring of a group of high school kids that participate in an ESA
> robotic challenge. Original he was the mentor of the group, but having
> fallen sick he needs a replacement. And as he is really a very old friend
> of mine I could not turn down the request.
>
> Sorry, but I wont be able to step in here. Hopefully somebody else in the
> GNUstep community will.
>

Thanks!

I work with kids myself (although it's only a small beginner's game
development class on Saturday) -- so I understand the importance.

And if it's not just a random group, but also work for an ESA competition
-- I can only convey my best wishes. Good luck! :-)


> Best wishes and hope to see you in Cambridge,


Ditto!

On Tue, Apr 23, 2013 at 9:31 AM, David Chisnall  wrote:

> On 22 Apr 2013, at 21:43, Ivan Vučica  wrote:
>
> > Ping! Student registrations have started. Any prospective mentors?
>
> I've registered as a mentor.  I'd also be most interested in the back end
> being refactored to support using Opal.
>

Based on feedback everyone gave, yes, the importance of this (and the
importance of integration with Core Animation) seems to be the consensus.

Currently, basic idea that I have is to copy the entire Cairo backend (or
maybe use derived classes, although long-term that seems a bad idea) and
ensure that every Cairo surface is instead backed with an Opal context. I'd
temporarily expose the Cairo surface from the Opal context, and ensure that
calls are directed to the Cairo surface backing the Opal context instead of
to the Cairo surface inside the backend.

Then, I'd be removing the Cairo surface from the backend and replacing
Cairo calls with Opal calls.

Finally, I would be continuously looking at options for integrating Core
Animation with AppKit (based on feedback).

I'll probably need more supervision compared to implementation of UIKit,
but this is definitely a more useful long-term project for GNUstep.

I'll put together a proposal, register it on GSoC's Melange, and also send
it to the mailing list.
-- 
Ivan Vučica - i...@vucica.net
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

[David Chisnall]

On 22 Apr 2013, at 21:43, Ivan Vučica  wrote:

> Ping! Student registrations have started. Any prospective mentors?

I've registered as a mentor.  I'd also be most interested in the back end being 
refactored to support using Opal.  

David

-- Sent from my STANTEC-ZEBRA


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

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

[Lundberg, Johannes]

This looks really interesting. Getting Chameleon UIKit to work with
GNUstep's core graphics and core animation would be very nice!

For the Viking project I'm not sure how much of UIKit/AppKit we will use
and how much we'll build our own UI. Most likely,  we will start out with
existing UI classes and replace with our own customized along the way as we
discover what is appropriate for a head mount display.

What is on the other hand important is to have CG and CA that's working
together with UIKit/AppKit, and also optimized for embedded device with low
power usage and high performance. We are hoping to have a early version of
a SDK ready during first half of 2014...

We will help out any way we can.

If you don't know about Viking, please have a look at the pamphlet at:
http://www.brilliantservice.co.jp/viking

If we can join forces, complete and "merge" all these libraries that are
under development and create a fully functional platform independent Cocoa
/ Cocoa Touch API with CA+CG I think we will succeed in getting Objective-C
out there, beyond the walls of Apple and let everyone discover the
wonderful language it is, along with its API.

Johannes Lundberg
BRILLIANTSERVICE CO., LTD. 


On Tue, Apr 23, 2013 at 6:36 AM, Jordan Schidlowsky
wrote:

> I would really love if Ivan can move forward with some QuartzCore
> development!  I've been really looking forward to Ivan's improvements in
> these areas.
>
> Full disclosure: we heavily use GNUStep to cross-compile iOS applications
> and games to Android...  We've shipped about 20 games that use GNUStep
> under the hood.  We actually have a pretty extensive implementation of
> UIKit as well thats based on the Chameleon UIKit implementation ( REALLY
> REALLY great project,  see link below ) and we also already use the
> existing quartzcore gnustep project, although we don't actually use it to
> paint any UIKit components to the screen.
>
> https://github.com/BigZaphod/Chameleon/tree/master/UIKit
>
> Anyways, if we had a working implementation of CoreAnimation that would be
> very useful for us.  I would also gladly help out any way I can.
>
> On 2013-04-22, at 2:43 PM, Ivan Vučica wrote:
>
> Ping! Student registrations have started. Any prospective mentors?
>
> (Crossposting this to discuss-gnustep.)
>
> On Sat, Apr 20, 2013 at 6:31 PM, Ivan Vučica  wrote:
>
>> Hello all,
>>
>> In the end, I only played with compiling Base for Android since writing
>> the previous mail. But, here's some bad news -- that happen to be good for
>> my contributions to GNUstep :-)
>>
>> It looks like I'll be free from the part-time job that I had last summer.
>> So, any frustration that Fred may have had with me during Google Summer of
>> Code should hopefully go away this year. That, of course, if someone still
>> happens to think I can contribute interesting things :-)
>>
>> I've thought a bit more about potential contributions for this GSoC, if
>> someone chooses to mentor me and GNUstep gets a GNU slot. Here they are, in
>> order of how "independently" I could implement them.
>>
>> - *UIKit*. An implementation of UIKit, along with fixes to QuartzCore
>> needed to make this happen (and to improve performance). I can mostly do
>> this on my own, except for code review, advice and discussion that would
>> improve the work.
>> - *Core Data persistence.* From what I understand, there is a basic
>> implementation of Core Data for GNUstep. I could work on extending it with
>> implementations of NSAtomicStore and NSIncrementalStore. I would not focus
>> too much on multithreading, migration, lightweight migration, context
>> merging, etc.
>> - *Integration of QuartzCore into AppKit.* This also requires a lot of
>> handholding. Sadly, I don't quite have the "big picture" in my head of how
>> GNUstep GUI works, especially the backends.
>>
>> I'm of course most interested in things that do with QC, since I already
>> spent a lot of time on Core Animation.
>>
>> Is someone willing to mentor me for GSoC? Student applications start on
>> Monday. It might also make sense to make an announcement at
>> summer-of-c...@gnu.org; maybe a more interesting candidate than me
>> appears (or maybe GNU chooses to give us two slots).
>>
>> On Mon, Feb 25, 2013 at 11:17 AM, Ivan Vučica  wrote:
>>
>>> I think it might also be a better year for me to participate as well.
>>>
>>> I'd start preparing this week by working on:
>>> - an OpenGL and OpenGL ES wrapper that would be usable by not just
>>> AppKit apps (a thin wrapper around GLX that uses CGL API)
>>> - by moving QuartzCore to use that instead of AppKit
>>>
>>> If I have some results by the deadline for student registration, I would
>>> feel confident to register this year, so it gets to be an even better
>>> experience for everyone :-)
>>>
>>> The project would be: an implementation of parts of UIKit, along with
>>> patching QuartzCore where needed.
>>>
>>> Thoughts?
>>>
>>> Regards,
>>>
>>> Ivan Vučica
>>> via phon

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

[Jordan Schidlowsky]

I would really love if Ivan can move forward with some QuartzCore development!  
I've been really looking forward to Ivan's improvements in these areas.

Full disclosure: we heavily use GNUStep to cross-compile iOS applications and 
games to Android...  We've shipped about 20 games that use GNUStep under the 
hood.  We actually have a pretty extensive implementation of UIKit as well 
thats based on the Chameleon UIKit implementation ( REALLY REALLY great 
project,  see link below ) and we also already use the existing quartzcore 
gnustep project, although we don't actually use it to paint any UIKit 
components to the screen.  

https://github.com/BigZaphod/Chameleon/tree/master/UIKit

Anyways, if we had a working implementation of CoreAnimation that would be very 
useful for us.  I would also gladly help out any way I can.  

On 2013-04-22, at 2:43 PM, Ivan Vučica wrote:

> Ping! Student registrations have started. Any prospective mentors?
> 
> (Crossposting this to discuss-gnustep.)
> 
> On Sat, Apr 20, 2013 at 6:31 PM, Ivan Vučica  wrote:
> Hello all,
> 
> In the end, I only played with compiling Base for Android since writing the 
> previous mail. But, here's some bad news -- that happen to be good for my 
> contributions to GNUstep :-) 
> 
> It looks like I'll be free from the part-time job that I had last summer. So, 
> any frustration that Fred may have had with me during Google Summer of Code 
> should hopefully go away this year. That, of course, if someone still happens 
> to think I can contribute interesting things :-)
> 
> I've thought a bit more about potential contributions for this GSoC, if 
> someone chooses to mentor me and GNUstep gets a GNU slot. Here they are, in 
> order of how "independently" I could implement them.
> 
> - UIKit. An implementation of UIKit, along with fixes to QuartzCore needed to 
> make this happen (and to improve performance). I can mostly do this on my 
> own, except for code review, advice and discussion that would improve the 
> work.
> - Core Data persistence. From what I understand, there is a basic 
> implementation of Core Data for GNUstep. I could work on extending it with 
> implementations of NSAtomicStore and NSIncrementalStore. I would not focus 
> too much on multithreading, migration, lightweight migration, context 
> merging, etc.
> - Integration of QuartzCore into AppKit. This also requires a lot of 
> handholding. Sadly, I don't quite have the "big picture" in my head of how 
> GNUstep GUI works, especially the backends.
> 
> I'm of course most interested in things that do with QC, since I already 
> spent a lot of time on Core Animation.
> 
> Is someone willing to mentor me for GSoC? Student applications start on 
> Monday. It might also make sense to make an announcement at 
> summer-of-c...@gnu.org; maybe a more interesting candidate than me appears 
> (or maybe GNU chooses to give us two slots). 
> 
> On Mon, Feb 25, 2013 at 11:17 AM, Ivan Vučica  wrote:
> I think it might also be a better year for me to participate as well.
> 
> I'd start preparing this week by working on:
> - an OpenGL and OpenGL ES wrapper that would be usable by not just AppKit 
> apps (a thin wrapper around GLX that uses CGL API)
> - by moving QuartzCore to use that instead of AppKit
> 
> If I have some results by the deadline for student registration, I would feel 
> confident to register this year, so it gets to be an even better experience 
> for everyone :-)
> 
> The project would be: an implementation of parts of UIKit, along with 
> patching QuartzCore where needed.
> 
> Thoughts?
> 
> Regards,
> 
> Ivan Vučica
> via phone
> 
> On 25. 2. 2013., at 09:19, Fred Kiefer  wrote:
> 
> > Just to remind you. As every year, the Google Summer of Code is approaching 
> > and we need to decide, whether we are going to participate. Last year I 
> > mentored Ivan and it was great fun and of course I learned a lot. Still it 
> > was the wrong year for me to do so, I didn't have enough free time to 
> > really fill up the role of a mentor. This year I should have more time for 
> > this but would prefer to pass on the mentor role to somebody else. And of 
> > course we should only participate if we can find suitable students.
> >
> > Fred 
> 
> -- 
> Ivan Vučica - i...@vucica.net
> 
> 
> 
> 
> -- 
> Ivan Vučica - i...@vucica.net
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

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

[Ivan Vučica]

Ping! Student registrations have started. Any prospective mentors?

(Crossposting this to discuss-gnustep.)

On Sat, Apr 20, 2013 at 6:31 PM, Ivan Vučica  wrote:

> Hello all,
>
> In the end, I only played with compiling Base for Android since writing
> the previous mail. But, here's some bad news -- that happen to be good for
> my contributions to GNUstep :-)
>
> It looks like I'll be free from the part-time job that I had last summer.
> So, any frustration that Fred may have had with me during Google Summer of
> Code should hopefully go away this year. That, of course, if someone still
> happens to think I can contribute interesting things :-)
>
> I've thought a bit more about potential contributions for this GSoC, if
> someone chooses to mentor me and GNUstep gets a GNU slot. Here they are, in
> order of how "independently" I could implement them.
>
> - *UIKit*. An implementation of UIKit, along with fixes to QuartzCore
> needed to make this happen (and to improve performance). I can mostly do
> this on my own, except for code review, advice and discussion that would
> improve the work.
> - *Core Data persistence.* From what I understand, there is a basic
> implementation of Core Data for GNUstep. I could work on extending it with
> implementations of NSAtomicStore and NSIncrementalStore. I would not focus
> too much on multithreading, migration, lightweight migration, context
> merging, etc.
> - *Integration of QuartzCore into AppKit.* This also requires a lot of
> handholding. Sadly, I don't quite have the "big picture" in my head of how
> GNUstep GUI works, especially the backends.
>
> I'm of course most interested in things that do with QC, since I already
> spent a lot of time on Core Animation.
>
> Is someone willing to mentor me for GSoC? Student applications start on
> Monday. It might also make sense to make an announcement at
> summer-of-c...@gnu.org; maybe a more interesting candidate than me
> appears (or maybe GNU chooses to give us two slots).
>
> On Mon, Feb 25, 2013 at 11:17 AM, Ivan Vučica  wrote:
>
>> I think it might also be a better year for me to participate as well.
>>
>> I'd start preparing this week by working on:
>> - an OpenGL and OpenGL ES wrapper that would be usable by not just AppKit
>> apps (a thin wrapper around GLX that uses CGL API)
>> - by moving QuartzCore to use that instead of AppKit
>>
>> If I have some results by the deadline for student registration, I would
>> feel confident to register this year, so it gets to be an even better
>> experience for everyone :-)
>>
>> The project would be: an implementation of parts of UIKit, along with
>> patching QuartzCore where needed.
>>
>> Thoughts?
>>
>> Regards,
>>
>> Ivan Vučica
>> via phone
>>
>> On 25. 2. 2013., at 09:19, Fred Kiefer  wrote:
>>
>> > Just to remind you. As every year, the Google Summer of Code is
>> approaching and we need to decide, whether we are going to participate.
>> Last year I mentored Ivan and it was great fun and of course I learned a
>> lot. Still it was the wrong year for me to do so, I didn't have enough free
>> time to really fill up the role of a mentor. This year I should have more
>> time for this but would prefer to pass on the mentor role to somebody else.
>> And of course we should only participate if we can find suitable students.
>> >
>> > Fred
>>
>
> --
> Ivan Vučica - i...@vucica.net
>
>


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

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

[Ivan Vučica]

Hello all,

In the end, I only played with compiling Base for Android since writing the
previous mail. But, here's some bad news -- that happen to be good for my
contributions to GNUstep :-)

It looks like I'll be free from the part-time job that I had last summer.
So, any frustration that Fred may have had with me during Google Summer of
Code should hopefully go away this year. That, of course, if someone still
happens to think I can contribute interesting things :-)

I've thought a bit more about potential contributions for this GSoC, if
someone chooses to mentor me and GNUstep gets a GNU slot. Here they are, in
order of how "independently" I could implement them.

- *UIKit*. An implementation of UIKit, along with fixes to QuartzCore
needed to make this happen (and to improve performance). I can mostly do
this on my own, except for code review, advice and discussion that would
improve the work.
- *Core Data persistence.* From what I understand, there is a basic
implementation of Core Data for GNUstep. I could work on extending it with
implementations of NSAtomicStore and NSIncrementalStore. I would not focus
too much on multithreading, migration, lightweight migration, context
merging, etc.
- *Integration of QuartzCore into AppKit.* This also requires a lot of
handholding. Sadly, I don't quite have the "big picture" in my head of how
GNUstep GUI works, especially the backends.

I'm of course most interested in things that do with QC, since I already
spent a lot of time on Core Animation.

Is someone willing to mentor me for GSoC? Student applications start on
Monday. It might also make sense to make an announcement at
summer-of-c...@gnu.org; maybe a more interesting candidate than me appears
(or maybe GNU chooses to give us two slots).

On Mon, Feb 25, 2013 at 11:17 AM, Ivan Vučica  wrote:

> I think it might also be a better year for me to participate as well.
>
> I'd start preparing this week by working on:
> - an OpenGL and OpenGL ES wrapper that would be usable by not just AppKit
> apps (a thin wrapper around GLX that uses CGL API)
> - by moving QuartzCore to use that instead of AppKit
>
> If I have some results by the deadline for student registration, I would
> feel confident to register this year, so it gets to be an even better
> experience for everyone :-)
>
> The project would be: an implementation of parts of UIKit, along with
> patching QuartzCore where needed.
>
> Thoughts?
>
> Regards,
>
> Ivan Vučica
> via phone
>
> On 25. 2. 2013., at 09:19, Fred Kiefer  wrote:
>
> > Just to remind you. As every year, the Google Summer of Code is
> approaching and we need to decide, whether we are going to participate.
> Last year I mentored Ivan and it was great fun and of course I learned a
> lot. Still it was the wrong year for me to do so, I didn't have enough free
> time to really fill up the role of a mentor. This year I should have more
> time for this but would prefer to pass on the mentor role to somebody else.
> And of course we should only participate if we can find suitable students.
> >
> > Fred
>

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

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

[Ivan Vučica]

On 26. 2. 2013., at 22:34, Lars Sonchocky-Helldorf 
 wrote:

> I doubt this would be possible since Linux (and so Android) uses a different 
> binary format. More likely is that you "develop once, deploy everywhere", 
> e.g. you just recompile your app for Android using GNUstep. So this is more a 
> help for developers than for pirates.

Luboš is actually working on binary compatibility of OS X and Linux (and 
apparently iOS :P). Similar effort for iOS by Christina Brooks: 
http://crna.cc/magenta_source.html

But, it'd definitely focus more on "develop once, deploy everywhere"; anything 
else is a bonus. :-)

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

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

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

[Lars Sonchocky-Helldorf]

Am 26.02.2013 um 21:20 schrieb Luboš Doležel:

> On 02/26/2013 01:35 PM, Ivan Vučica wrote:
>> 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.
> 
> Well, should such think materialize, I'd be worthwhile - and relatively easy 
> in fact - to support direct launching of iOS apps on Android via Darling. 
> Although I imagine Apple wouldn't be too happy about this, since I assume 
> pirated iOS apps could then be run on (non-rooted) Android devices :-)

I doubt this would be possible since Linux (and so Android) uses a different 
binary format. More likely is that you "develop once, deploy everywhere", e.g. 
you just recompile your app for Android using GNUstep. So this is more a help 
for developers than for pirates.

cheers,

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

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

[Luboš Doležel]

On 02/26/2013 01:35 PM, Ivan Vučica wrote:

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.


Well, should such think materialize, I'd be worthwhile - and relatively 
easy in fact - to support direct launching of iOS apps on Android via 
Darling. Although I imagine Apple wouldn't be too happy about this, 
since I assume pirated iOS apps could then be run on (non-rooted) 
Android devices :-)


So far I haven't been lucky even with running a console iOS "Hello 
World" on Android, since the it segfaults even before Darling's main() 
is called. Crappy Android dynamic loader is to blame :-(

I've had a lot of "fun" with it on other occasions, too.

But I wish a lot of good luck to you. There is a *lot* of untapped 
potential in GNUstep...


--
Luboš Doležel

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

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

[Ivan Vučica]

On 26. 2. 2013., at 12:52, David Chisnall  wrote:

> On 26 Feb 2013, at 08:21, Luboš Doležel  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  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
i...@vucica.net - http://ivan.vucica.net/


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

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

[David Chisnall]

On 26 Feb 2013, at 08:21, Luboš Doležel  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.  

David

-- Send from my Jacquard Loom


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

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

[Maxthon Chan]

About reimplementing UIKit, you can actually map UIKit to AppKit. Those code 
are largely similar.

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

在 2013-2-26，下午4:21，Luboš Doležel  写道：

> On 25.2.2013 11:17, Ivan Vučica wrote:
>> I think it might also be a better year for me to participate as
>> well.
>> 
>> I'd start preparing this week by working on: - an OpenGL and OpenGL
>> ES wrapper that would be usable by not just AppKit apps (a thin
>> wrapper around GLX that uses CGL API) - by moving QuartzCore to use
>> that instead of AppKit
>> 
>> If I have some results by the deadline for student registration, I
>> would feel confident to register this year, so it gets to be an even
>> better experience for everyone :-)
>> 
>> The project would be: an implementation of parts of UIKit, along with
>> patching QuartzCore where needed.
>> 
>> Thoughts?
>> 
> 
> Hi,
> 
> 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...
> 
> -- 
> Luboš Doležel
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


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

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

[Luboš Doležel]

On 25.2.2013 11:17, Ivan Vučica wrote:

I think it might also be a better year for me to participate as
well.

I'd start preparing this week by working on: - an OpenGL and OpenGL
ES wrapper that would be usable by not just AppKit apps (a thin
wrapper around GLX that uses CGL API) - by moving QuartzCore to use
that instead of AppKit

If I have some results by the deadline for student registration, I
would feel confident to register this year, so it gets to be an even
better experience for everyone :-)

The project would be: an implementation of parts of UIKit, along with
patching QuartzCore where needed.

Thoughts?



Hi,

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


--
Luboš Doležel

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

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

[Ivan Vučica]

I think it might also be a better year for me to participate as well.

I'd start preparing this week by working on:
- an OpenGL and OpenGL ES wrapper that would be usable by not just AppKit apps 
(a thin wrapper around GLX that uses CGL API)
- by moving QuartzCore to use that instead of AppKit

If I have some results by the deadline for student registration, I would feel 
confident to register this year, so it gets to be an even better experience for 
everyone :-)

The project would be: an implementation of parts of UIKit, along with patching 
QuartzCore where needed.

Thoughts?

Regards,

Ivan Vučica
via phone

On 25. 2. 2013., at 09:19, Fred Kiefer  wrote:

> Just to remind you. As every year, the Google Summer of Code is approaching 
> and we need to decide, whether we are going to participate. Last year I 
> mentored Ivan and it was great fun and of course I learned a lot. Still it 
> was the wrong year for me to do so, I didn't have enough free time to really 
> fill up the role of a mentor. This year I should have more time for this but 
> would prefer to pass on the mentor role to somebody else. And of course we 
> should only participate if we can find suitable students.
> 
> Fred
> 
>  Original message ----
> Betreff: [GSoC Mentors Announce] Google Summer of Code 2013
> Datum: Mon, 11 Feb 2013 11:02:32 -0800
> Von: Carol Smith 
> Antwort an: gsoc-mentors-announce+own...@googlegroups.com
> An: gsoc-mentors-annou...@googlegroups.com
> 
> Hi GSoC mentors and org admins,
> 
> We've announced that we're doing Google Summer of Code 2013 [1]. Yay!
> 
> If you would like to help spread the word about GSoC, we have presentations
> [2], logos [3], and flyers [4] for you to use. Please host meetups, tell
> your friends and colleagues about the program, go to conferences, talk to
> people about the program, and just generally do all the awesome
> word-of-mouth stuff you do every year to promote the program.
> 
> The GSoC calendar, FAQ, and events timeline have all been updated with this
> year's important dates, so please refer to those for the milestones for
> this year's program. NB: the normal timeline for the program has been
> modified for this year. You'll probably want to examine the dates closely
> to make sure you know when important things are happening.
> 
> Please consider translating the presentations and/or flyers into your
> native language and submitting them directly to me to post on the wiki.
> Localization for our material is integral to reaching the widest possible
> audience around the world. If you decide to translate a flyer, please fill
> out our form to request a thank you gift for your effort. [5]
> 
> If you decide to host a meetup, please email me to let me know the date,
> time, and location so I can put it on the GSoC calendar. Also, remember to
> take pictures at your meetup and write up a blog post for our blog using
> our provided template for formatting [6]. If you need promotional items for
> your attendees, please fill out our form [7] to request some; we're happy
> to send some along. We can provide up to about 25 pens, notebooks, or
> stickers and/or a few t-shirts. Please keep in mind, though, that shipping
> restrictions and timeline vary country-to-country; request items early to
> make sure they get there on time! If you have questions about hosting
> meetups, please see the section in our FAQ [8].
> 
> Please also consider applying to participate as an organization again this
> year or maybe joining as a mentor for your favorite organization if they
> are selected this year.
> 
> We rely on you for your help for the success of this program, so thank you
> in advance for all the work you do!
> 
> [1] -
> http://google-opensource.blogspot.com/2013/02/flip-bits-not-burgers-google-summer-of.html
> [2] -
> http://code.google.com/p/google-summer-of-code/wiki/ProgramPresentations
> [3] - http://code.google.com/p/google-summer-of-code/wiki/GsocLogos
> [4] - http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers
> [5] - http://goo.gl/gEHDO
> [6] - http://goo.gl/wbZrt
> [7] - http://goo.gl/0BsR8
> [8] - http://goo.gl/2NGfp
> 
> Cheers,
> Carol
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Google Summer of Code Mentors Announce List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to gsoc-mentors-announce+unsubscr...@googlegroups.com.
> Visit this group at 
> http://groups.google.com/group/gsoc-mentors-announce?hl=en-US.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
> 
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

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

[Fred Kiefer]

Just to remind you. As every year, the Google Summer of Code is 
approaching and we need to decide, whether we are going to participate. 
Last year I mentored Ivan and it was great fun and of course I learned a 
lot. Still it was the wrong year for me to do so, I didn't have enough 
free time to really fill up the role of a mentor. This year I should 
have more time for this but would prefer to pass on the mentor role to 
somebody else. And of course we should only participate if we can find 
suitable students.


Fred

 Original message 
Betreff: [GSoC Mentors Announce] Google Summer of Code 2013
Datum: Mon, 11 Feb 2013 11:02:32 -0800
Von: Carol Smith 
Antwort an: gsoc-mentors-announce+own...@googlegroups.com
An: gsoc-mentors-annou...@googlegroups.com

Hi GSoC mentors and org admins,

We've announced that we're doing Google Summer of Code 2013 [1]. Yay!

If you would like to help spread the word about GSoC, we have presentations
[2], logos [3], and flyers [4] for you to use. Please host meetups, tell
your friends and colleagues about the program, go to conferences, talk to
people about the program, and just generally do all the awesome
word-of-mouth stuff you do every year to promote the program.

The GSoC calendar, FAQ, and events timeline have all been updated with this
year's important dates, so please refer to those for the milestones for
this year's program. NB: the normal timeline for the program has been
modified for this year. You'll probably want to examine the dates closely
to make sure you know when important things are happening.

Please consider translating the presentations and/or flyers into your
native language and submitting them directly to me to post on the wiki.
Localization for our material is integral to reaching the widest possible
audience around the world. If you decide to translate a flyer, please fill
out our form to request a thank you gift for your effort. [5]

If you decide to host a meetup, please email me to let me know the date,
time, and location so I can put it on the GSoC calendar. Also, remember to
take pictures at your meetup and write up a blog post for our blog using
our provided template for formatting [6]. If you need promotional items for
your attendees, please fill out our form [7] to request some; we're happy
to send some along. We can provide up to about 25 pens, notebooks, or
stickers and/or a few t-shirts. Please keep in mind, though, that shipping
restrictions and timeline vary country-to-country; request items early to
make sure they get there on time! If you have questions about hosting
meetups, please see the section in our FAQ [8].

Please also consider applying to participate as an organization again this
year or maybe joining as a mentor for your favorite organization if they
are selected this year.

We rely on you for your help for the success of this program, so thank you
in advance for all the work you do!

[1] -
http://google-opensource.blogspot.com/2013/02/flip-bits-not-burgers-google-summer-of.html
[2] -
http://code.google.com/p/google-summer-of-code/wiki/ProgramPresentations
[3] - http://code.google.com/p/google-summer-of-code/wiki/GsocLogos
[4] - http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers
[5] - http://goo.gl/gEHDO
[6] - http://goo.gl/wbZrt
[7] - http://goo.gl/0BsR8
[8] - http://goo.gl/2NGfp

Cheers,
Carol

--
You received this message because you are subscribed to the Google 
Groups "Google Summer of Code Mentors Announce List" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to gsoc-mentors-announce+unsubscr...@googlegroups.com.
Visit this group at 
http://groups.google.com/group/gsoc-mentors-announce?hl=en-US.

For more options, visit https://groups.google.com/groups/opt_out.






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