Summer Of Code 2009

Summer Of Code 2009

The Summer Of Code is a Google program that offers student developers stipends to create new freely available programs or to help currently established projects. It would be an excellent opportunity for GNUstep to fund some developments.

We need more mentor(s) to manage the volunteers… More infos on the SoC FAQ

Joint Application

The idea of a joint application for GNUstep, Étoilé, GAP and OpenGroupware.org has been brought up. A lot of the projects that were accepted last year were joint applications (e.g. GNU, GNOME, KDE), so it might improve our chances. Please discuss!

GNUstep Ideas

Here are some ideas -- Feel free to add more

• Core Data: A CoreData compatible library is today in a alpha stage and needs some improvements.
  • NSPersistentStore concrete classes based on SQLite, XML, binary, etc. backends.
  • DataBuilder.app is a graphical application for designing data models. The GUI needs some improvement. Moreover DataBuilder should be turn into a true CoreData application.
  • File formats compatibility with Cocoa, including model files.
  • Model versioning and data Migration : Instances of NSMigrationManager and associated classes perform a migration of data from one persistent store to another using a given mapping model.
  • NSPersistentDocument is a subclass of NSDocument that integrates with the Core Data framework.
  • NSEditor and NSEditorRegistration protocols are implemented by NSManagedObjectContext.

• WebKit / SimpleWebKit
  • Porting WebKit (using GCC 4.x with ObjC++ support) should be a lot easier by now (see http://lwat.blogspot.com/2008/11/redistributable-webkit.html and http://lwat.blogspot.com/2009/02/opencflite-476171-release.html)
  • helping to improve Simple WebKit which does not require gcc 4.xx and Obj-C++ and has less dependencies and a much smaller footprint than full WebKit

• General Improvements
  • Compare current API with Leopard's (Mac OS X 10.5) API, indicate which classes are missing, and summarize the current status of the existing ones, then work to complete them... ;) The best would be to have a tool which parses all headers (both from Cocoa and GNUstep) and outputs differences in HTML (XML probably too by the way). This would summarize missing classes, missing or partially implementated methods in existing classes and GNUstep-specific extensions. Eventually we should include links to the related documentation on both GNUstep and Cocoa web sites.
  • Garbage Collection ... get this working reliably for all classes in the base library (mostly done already) and then make the gui and back libraries support garbage collection too. The existing support consists of an option in gnustep-make to build everything with GS_WITH_GC defined and link with the Boehm garbage collecting library and the garbage collecting version of the runtime, and near complete support for the OSX10.5 garbage collection APIs in gnustep-base. the project would involve making sure that all classes handle memory management properly in a GC environment, and would require the student to develop a thorough understanding of the benefits and pitfalls of using garbage collection, and how to alter existing design patterns to make classes operate efficiently in a garbage collecting environment. existing code would need to be stress-tested in both single and multi-threaded use and on different platforms (at least gnu/linux and mswindows).
  • Craft a system which allows to distribute GNUstep to the various packaging systems (rpm, debian, ports, etc.) on various distributions (Ubuntu, Red Hat, FreeBSD, etc.) with a snap and without knowledge of the specific packaging system. This system should be able to distribute GNUstep libraries, and existing or new applications written with it. The user should be able to choose how often this is done: on request, on each release, on in regular intervals, tracking a source code repository. Ideally, changes to the library/app's sources are minimized and/or calculated at runtime.

• Backend
  • Windows support : Win32 backend lacks some features
  • Unified backend : Win32 and X11 backends share a lot of functionalities. Many of them might be provided by a base class. The student would have to find out these functions shared by both backend, design an interface to theses functions, and adapt the current backend classes that would then use the new interface.
  • Cairo/DirectFB backend : a DirectFB backend for GNUstep would run on low-end embedded devices. As Cairo can already draw on a DirectFB surface, the project concern the system part of the backend and the access to low level resources through DirectFB. The student would have to understand both GNUstep backend and DirectFB interface, and link them through a standardized interface (see above).
  • Cairo/Glitz/OpenGL backend : Glitz is an OpenGL backend for Cairo graphics. Today in an alpha stage, Glitz based GNUstep graphic backend gives access to hardware accelerated graphics on platforms that only implement OpenGL (or OpenGL-ES) functions like some embedded devices. It might be used along with a DirectFB backend (see above). Glitz itself is in a beta stage and not actively maintained.

• Foundation
  • Update the main class/API coverage to match OSX 10.5 by implementing missing methods and in particular the missing NSXML classes (for tree-based XML processing and XSLT etc) and the NSOperation class (leave the scripting classes as a separate task). This is quite a wide and varied project. Checking for and implementing missing minor features provides an easy introduction to the OpenStep/Cocoa API without any need to go into great depth, while implementing the missing XML classes will develop a good understanding of how XML works, and implementing the NSOperation code is an interesting problem in task scheduling and efficient multi-threaded programming, as an ideal implementation would involve multiple threads working with a single queue and avoiding locking overheads.
  • CoreFoundation ... implement the CoreFoundation API as an extension of the base library so that Apple code which uses it can easily be ported. This is a great exercise in writing portable code as it must provide the same (working) API on both unix-style systems and on mswindows. The CoreFoundation library would be built as a subproject of the base library and could both wrap base library classes and implement new code changing the base library classes to wrap the new code, as appropriate. This combination of Foundation/CoreFoundation allows maximum re-use of existing code, but also allows for critical parts to be written for optimum performance and/or clarity/maintainability.
  • Implement the apple scripting classes and produce example/test programs and utilities/tools for scripting using those classes from applescript and/or an objective-c like scripting language. Supporting applescript would be good for OSX compatibility. Supporting objective-c scripting would be great for GNUstepWeb. Helge Hesse has written objective-c interpreter code which could be used as a basis for an objective-c scripting language.
  • Implement a version of distributed objects binary compatible with the Apple implementation by using keyed archiving (work on NIB support means that the keyed archiving is now basically binary compatible) and my using Nicolas' work on NSSocketPort etc in mySTEP (he says that his port implementation is binary compatible with OSX). This would let GNUstep applications communicate directly with cocoa applications, something which was until recently considered too big a job to attempt.

• AppKit
  • Themes for GNUstep. This includes the moving of all drawing code from the GUI classes into theme methods, replacing all hard coded panels with Gorm/NIB files, updating Thematic.app to support the new theming methods, and as the proof of the concept a native Windows theme (Or at least one theme that looks sufficiently different from standard GNUstep).
  • Implement a test framework for the graphical part of the GNUstep AppKit implementation. We already have a great test framework for base and this is well suited for non-graphical tests.
  • NSMovie/QTMovie class : on Mac OSX, the NSMovie (now deprecated) and QTMovie classes are based on QuickTime Apple tecnologies. GNUstep compatible classes might be based on open source ans multiplatform technologies like VideoLAN
  • NSOpenGLPixelBuffer : this class has been introduced in Mac OSX 10.5. It might be useful for any modern OpenGL application.
  • Improve/clean the text system -- add temporary attributes, pango support

• GNUstepWeb
  • GNUstepWeb (add script language support, etc)
  • Create a AJAX Framework for GNUstepWeb (similar to what Project Wonder provides for WebObjects

• More Ideas

Étoilé Ideas

Take a look at Étoilé Open Projects page.

GAP (GNUstep Application Project) Ideas

• Debug and Complete FlexiSheet, making sure it works on Cocoa as expected and noting incompatibilities with GNUstep. Those should be either fixed for both platforms (FlexiSheet portability of code improvment) or noted as a bug or missing feature in GNUstep.
• implement (Extract from Addresses) an iSync compatible framework, its corresponding managment application and then integrating it with AddressBook (which already has part of such framework). The goal would be to have syncronization of Addresses (but in future, perhaps calendar, Vespucci bookmarks) gnustep to gnustep, gnustep to mac and gnustep to .Mac/MobileMe by having such account.
• porting of Applications from OpenStep or Cocoa abandonware. This needs to be checked on application-per-application: License and dependencies can be a problem as defining the scope of the project well.
• Some miscellaneous applications that run a Cocoa GUI could be ported to GNUstep:
  • Vim GUI : at least two cocoa-based gui projects already exist - vim-cocoa and mac-vim
  • VLC media player : a Cocoa based interface exists for VLC.
  • NetHack3D is a Cocoa port of NetHack with 3D graphics.
• OpenGL extensions management API: before using an OpenGL extension a program must first determine its availability. The mechanism for doing this is platform-specific and libraries such as w:GLEW and w:GLEE exist to simplify the process. The target of this project is a multiplatform Objective-C wrapper around OpenGL platform-specific functions.
• HID API: GNUstep can only handle the usual human interface devices (HID) : keyboard and mouse. A multiplatform framework would allow GNUstep application to handle joystick, graphic tablet or 3D device.

Feel to add ideas…

OpenGroupware.org Ideas

Some ideas by Sebastian Reitenbach:

(a) port SOPE/OGo from libFoundation to gnustep-base

(b) implement the CalDAV/CardDAV REPORT operations in ZideStore

(c) implement VTODO put in ZideStore

(d) Complete the SOAP implementation in SOPE.

For (b) and (c) I think I could help them out and both I would consider pretty 'educational' since it touched on allot of things (Obj-C, HTTP, DAV, etc...) They are also [relatively] small-ish. Whereas I would apply to help with (a).

Mentors

• Quentin Mathé
• David Chisnall
• Richard Frith-Macdonald
• Fred Kiefer
• Riccardo Mottola (as co-Mentor, as Fred suggested)
• Xavier Glattard
• Nicolas Roard

Students

- t.b.a.