SoC2010

From GnuCash
Revision as of 11:21, 4 March 2010 by Cstim (talk | contribs) (Proposed Applications 2010)
Jump to: navigation, search

Google Summer of Code 2010

GnuCash will apply as a mentoring organization to the 2010 Google Summer of Code (GSoC). The following are the proposed projects from the GnuCash developers. If you are interested in applying to the Google Summer of Code then follow the link to google and apply.

See SoC2007 for our previous ideas and four accepted students who worked on gnucash projects in the GSoC 2007.

Timeline

As copied from here:

  • March 12: Mentoring organization application deadline.
  • March 18: List of accepted mentoring organizations published
  • April 9: Student application deadline.
  • May 24 - August 16: Students work on their GSoC projects.

Proposed Applications 2010

Here we collect projects which are proposed for students interested in the 2010 GSoC.

Migrate Reports

Migrate reports from HTML-emitting Scheme to eguile-generator with templated HTML. There are multiple part of that undefined, so helping define them might be the first step.

  • Student:
  • Mentor: jsled
  • Backup mentor:

Register Rewrite

(copied from 2007, still relevant) Finish the re-write of the GnuCash register to use the GtkTreeView. Make sure all the interfaces that use the Register (Transaction Register, SX Register, Invoice Register) can use the new UI.

  • Student:
  • Mentor: ?
  • Backup Mentor:

Delimited file importer

(copied from 2007, still relevant) A CSV importer is the more direct way to say this, but general delimited file support would be best; think of the "Import text file" dialog in Gnumeric, and in fact try to leverage that same code, if possible. Supporting the core transaction profile is a good start, but "extended" import options (Invoices, time-spent, &c.) would be nice too.

There exists already a wizard-like GUI for accomplishing this task, but it is not yet finished and works only in very easy cases. The student working on this task can use the existing code as a starting point, which means there will already be some features to demonstrate and test. Eventually this feature should work with all sorts of CSV input files and extract the right portions of data, while communicating with the user in a reasonable way about the part of the data which cannot be recognized and imported. Ideally, each required decision should have a reasonably guessed suggestion, and additionally there should be a "preview" of what the user's decision will result in.

  • Student:
  • Mentor:
  • Backup mentor: