Summer of Code 2007

From Apache OpenOffice Wiki
Revision as of 10:34, 12 March 2007 by Frank Schoenheit (Talk | contribs)

Jump to: navigation, search

Similarly to the last year, OpenOffice.org would like to participate in the Summer of Code initiative sponsored by Google.

This page is here to collect the suitable suggestions. So - if you have a task that is challenging enough, and are willing to mentor the task, feel free to add it below. Each entry should contain the task description, required skills and personal contact. Links to the To-Dos are appreciated provided that the task is well described there ;-)

We would be glad to support a few projects. Mentoring capacities are limited, so we depend on your dedication during the preparation of the detailed specification and description of the outcome.

For further general questions about the initiative Google prepared a FAQ.

The Tasks

===Example entry===

This is just an example - the real entry must not start with a space at the beginning
of the line.
A full description of the task should be here; one that will help to see that this task
is important,  and interesting to hack on.  Alternatively it could be an exact link to
the description that is already in To-Dos.

* Required skills/knowledge: Language, technology1, technology2, ...

; Contact
: dev@project.openoffice.org
: The.Mentor at organization com

Draw/Impress: SVG Import Filter

SVG (Scalable Vector Graphics) is a vector graphics format that describes 2D graphics in XML.

There's no native SVG import filter for OOo. There exists an external one, but unfortunately it has very strong dependencies - Java 5.0, and Batik. The goal of this task is to create a new implementation that does not require any too big libraries.

A proof of concept implementation written in C++ using the UNO Draw API, and a lighweight libsvg library exists (see here), but it needs a lot of work to be really usable. Also libsvg does not seem to be too actively maintained, so maybe it would be desirable to use something other library than libsvg; but similarly to it, the solution should be lighweight.

More information is available in Kendy's blog.

  • Required skills/knowledge: C++, XML knowledge is a plus
Contact
Jan Holesovsky - kendy at openoffice org
Fridrich Strba - fridrich_strba at openoffice org

Calc: Integration of R into Calc

Create an add-on component that allows a Calc user to let the R environment do calculations on data from Calc cells and put the results into the spreadsheet again.

This should include a dialog to select input parameters and options, and allow results to be values or graph images. Note that the incompatible licenses (R is under GPL) have to be taken care of, possibly by starting R as a separate process.

Some more thoughts on the subject have been collected at Statistical Data Analysis Tool#Third Party Library Integration.

  • Required skills/knowledge: Some familiarity with statistical methods
Contact
dev@sc.openoffice.org
Niklas.Nebel at sun.com

Calc: Watch Window

A Watch Window is a separate, small window that remains "on top" and enables users to monitor a selected set of cells, see issue 28386.

This could be implemented as an add-on component with a modeless dialog containing the list of watched cells as well as the UI to add or remove cells.

  • Required skills/knowledge: Java or C++
Contact
dev@sc.openoffice.org
Niklas.Nebel at sun.com

Writer: RTF Generator

The current RTF export of OpenOffice.org is not as good as the export to the Word (.doc) format. Parsing the generated Word format stream with a Word tokenizer and handing over the generated events to an RTF generator would lead to an RTF export filter with the same quality as the binary Word export filter. Remark: the tokenizer itself isn't complete today but in its current state covers enough parts of the Word format to make this a valuable project for the planned time span.

  • Required skills/knowledge: C++, some knowledge about the Word file format would be a plus
Contact
dev@sw.openoffice.org
Henning.Brinkmann at sun.com

Writer: Lotus WordPro filter

If you know something about the format of Lotus WordPro - here's the perfect task for you! Anything can be useful as a start, even a simple filter that just excerpts the pure text. A first patch is available but it doesn't work good enough until now.

  • Required skills/knowledge: C++, some knowledge about the WordPro file format
Contact
dev@sw.openoffice.org
Mathias.Bauer at sun.com

Framework/Writer: Status bar control to display/change the language at the cursor position or the document language

Currently the Writer lacks means to display the language in use. There's also no easy way to change the language as the user has to use the menu. A status bar control would help to solve these problems. The control should be implemented using existing UNO APIs.

  • Required skills/knowledge: C++
  • Useful skills: Basic UNO API knowledge
Contact
dev@framework.openoffice.org, Carsten.Driesner at sun.com
dev@sw.openoffice.org, Thomas.Lange at sun.com

Framework: Shell Extensions for Desktop file search and showing meta data in windows explorer needs to be rewritten for Vista

Vista changed his mechanism to integrate those shell extensions incompatible. Extensions valid for Win98/2000/XP doesnt work any more. A set of new interfaces was designed. But they are available on Vista only. So OOo has to support two sets of shell extensions: one set for Win98/2000/XP and a new set for Vista and might following windows versions. For this project the new Vista extensions has to be implemented only. See 71112 and 70944 for further informations.

  • Required skills/knowledge: C++
  • Useful skills: Windows API knowledge
  • Requirements: Windows Vista 32 Bit
Contact
dev@framework.openoffice.org, Andreas.Schluens at sun.com

ODF Toolkit: Tools and best practice samples for ODF creation and manipulation

We already have some code snippets in Java and C# and looking for help to extend these tool sets or to provide tool sets in other languages. These tool sets are designed to offer basic ODF functionality even outside of OO.o.

  • Required skills/knowledge: Java or C# or Perl or C++ ...
  • Useful skills: ODF, XML
Contact
dev@odftoolkit.openoffice.org,
Dieter Loeschky at sun.com

UNO specifications changes in Eclipse Integration

This project aims at improving the way to develop OpenOffice.org extensions and UNO components using Eclipse. This project should help the developer to changes its specifications easily. This project could be parted into several smaller parts.

See the Todo task description for further informations.

  • Required skills/knowledge: Java, Grammar & Compilers
  • Usefull skills: Eclipse API, JavaCC, UNO & UNO IDL
Contact
dev@api.openoffice.org
CedricBosdo at openoffice.org

OOo connector for External IDE for OOo scripting languages

This project will solve the problem of lack of IDE for scripting languages in OOo. Scripts can be seen as macros in various languages and are complementary to Extensions. Actually, only OOoBasic has its IDE embedded in OOo. Javascript and Beanshell have limited ones and python nothing. To avoid implementing different IDE for various languages into OOo, the proposed choice is to provide a connector to any external IDE

The project is dived into 2 complementary parts :

  • defining and implementing common tools at OOo side to put the scipts at the correct place and manage OOo scripts menus
  • implement an Eclipse extension as an IDE that could handle scripts in python language, using the previously defined OOo tools.
Requirements
  • Required skills/knowledge: java, python, UNO
  • Usefull skills: Eclipse API, OOo API, IDE general knowledge
Contact
dev@extensions.openoffice.org
LaurentGodard@openoffice.org


Mac OS X native port : complete User Interface respecting Aqua Human Interface Guidelines (Aqua Only )

  • Concerns: OpenOffice.org 2.x for Mac OS X Aqua only
  • Skills: Knowledge of languages C/C++ Mac OS X APIs and Application frameworks like Carbon

Original OpenOffice.org vcl widgets are not Aqua HIG compliant, and we need to implement all controls, respecting Aqua Human Interface Guidelines, some will use HIView, or HITheme or even other part of Carbon API.

  • Tasks: some controls are already implemented, but some are still missing.

The job consists in write the code and implement :

- tabs ( implement and bind the TabitemValue class, using Carbon API )

- spinbuttons ( implement and bind SpinbuttonValue class, using Carbon API )

- comboboxes ( implement and use HICombobox )

- listboxes ( work already started )

- texts in comboboxes / listboxes ( better task definition to be completed )

- other types of controls : highlight, respect dimensions/spacing ..etc

- Windows background ( using Aqua theme )

Proposed by 
Eric Bachard
Contact 
mac@porting.openoffice.org
ericb at openoffice dot org

Mac OS X native printing ( Aqua only )

Concerns: OpenOffice.org 2.x for Mac OS X Aqua only

Objective : currently, the native printing implementation is missing on Aqua port and needs to be implemented.

The objective is to use the same box users have in any Mac application.

Skills: Knowledge of languages C/C++ Mac OS X APIs and Application frameworks like Carbon

Tasks:

Familiarize with the Mac OS X printing API's

Familiarize with the current OOo printing API

Expected : Write code to Implement native printing with Aqua version of OpenOffice.org :

Contact
mac@porting.openoffice.org
fheckl at openoffice dot org

Proposed by : Florian Heckl

Mentor : Florian Heckl


Writer: Better "Notes" functionality

The "Notes" functionality in Writer could be better in terms of usability and does not look very appealing.

  • Required skills/knowledge: C++
Contact
dev@sw.openoffice.org
Mathias.Bauer at sun.com

Base: Joins in dBase Queries

Queries to dBase files can currently contain one table only. Scope of the project is to enhance Base' built-in simple query engine to be capable of executing statements line SELECT table1.field1, table2.field2 FROM table1, table2. The dBase driver, the text/csv driver, and the Spreadsheet driver would all benefit from this extension.

Be prepared to dig around here before starting the project, the project touches low-level core implementations, including some heavy-to-read STL stuff, so be prepared to invest some time before writing the first line of code.

Base: Dialogs with Form Functionality

When creating a form, the user always needs to bother with a Writer document. Very often, this is much too oversized. It would be sufficient to have a simple dialog which contains all the data access controls.

The advantage would be to not slay the user with things she does not bother – a writer document offers a lot of possibilities which are not relevant for a form. In some cases, a full writer document does even contradict to what users expect from a form – one thing to mention here is that documents are always freely sizable, which is nothing you expect from a carefully designed form, where controls are placed at concrete positions and have a fixed size.

The project is to - extend the dialog runtime engine to (optionally) include data-aware form controls - create a form designer for dialog-based forms (similar to the existing Basic Dialog IDE) - implement persistence of dialog-based forms - embed dialog-based forms into database documents (.odb)

Depending on more fine-grained planning, it might become apparent that not all of this can be done in the scope of a Google Summer of Code project, and reasonable milestones need to be defined.

Personal tools