Summer Of Code 2009

From GNUstepWiki

(Difference between revisions)
Revision as of 09:48, 11 March 2009
Fred (Talk | contribs)
Mentors
← Previous diff
Revision as of 09:50, 11 March 2009
Fred (Talk | contribs)
GNUstep Ideas
Next diff →
Line 36: Line 36:
* '''AppKit''' * '''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). ** 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.

Revision as of 09:50, 11 March 2009

Contents

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


  • General Improvements
    • Windows support
    • 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.


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



Étoilé Ideas

Take a look at Étoilé Open Projects page.


GAP Ideas

Feel to add ideas…


OpenGroupware.org Ideas

Feel free to add ideas…


Mentors

  • Quentin Mathé
  • David Chisnall
  • Richard Frith-Macdonald
  • Fred Kiefer

Students

- t.b.a.