Summer of Code 2006

From Apache OpenOffice Wiki
Revision as of 12:30, 25 April 2006 by St (Talk | contribs)

Jump to: navigation, search

OpenOffice.org Summer of Code Projects

OpenOffice.org is proud to participate in the Summer of Code initiative sponsored by Google. Below you'll find some suggestions we find suitable for the program. If you have ideas for other tasks please send a note to the developer list of the related OpenOffice.org project or contact the project lead.

We would be glad to support a few projects. Please understand that mentoring capacities are limited. So we depend on your dedication during the preparation of the detailed specification and description of the outcome.

The timeframe for applications is May 1 - May 8. But keep in mind that it may need some prearrangement before you are ready to apply.

For further general questions about the initiative Google prepared FAQs for students and mentors.



API / Programmability

Programmability: Dynamic IDL-Referenz-Browser

The OpenOffice.org API is specified in IDL (Interface Definition Language). IDL allows a language independent description of the API and language bindings/bridges allows the use of the same API from various languages where exactly such a language binding/bridge exists. But often it is difficult for users of the API to map the language independent IDL reference documentation to their preferred and used programming language, e.g. Java or StarBasic. But exactly this would speed up their daily work, a Java programmer would like to have a Javadoc like reference of the API. The idea of a “Dynamic IDL Reference Browser” is to develop a new concept for documenting IDL types in XML and a concept to provide a dynamically created representation for different languages. That means in detail that the reference browser would dynamically create a piece of XML code from the IDL definition and the provided XML documentation string for the IDL type. An appropriate XSL transformation would convert the XML representation into the required language representation. For example a Java developer gets the correct Java mapping for an IDL interface type. The dynamically approach has the advantage that we can (in a second step) analyze the navigation path to a type and can show context specific documentation. That can be very useful for generic types which have different meanings in different contexts. For example a return type of a generic type XEnumeration from function F of interface X. The generated documentation for XEnumeration would show exactly the info which is necessary to understand and use XEnumeration in the context of function F from interface X. It shows for example that the enumeration in this context always contains objects of type Y and even more information for more complex context dependent information.

  • required skills/knowledge: Java, XML, XSLT
Contact
dev@api.openoffice.org
Juergen.Schmidt at sun.com

Basic IDE: BASIC/UNO Object Browser

Target of this project is to create an UI component that allows to browse through the structure of UNO objects. Unlike the Basic IDE watch window that recently has been improved to display object properties and their values in an reasonable way the object browser should show the objects' API structure (properties, methods, interfaces, services). It has to be specified if this should refer to the Basic API view (Basic types, no explicit distinction of different interfaces) or the UNO view (UNO types, interface oriented) or if the browser should support two modes allowing to switch between Basic and UNO view. A Basic view is more challenging because it requires Basic related knowledge and probably new functionality in the Basic project. Actually the component is more like a type browser as the objects' static class/interface structure should be displayed, but unfortunately most information are only available for a "living" object using the XtypeProvider interface and the Reflection and Introspection API. Nevertheless it would also make sense to support types directly, e.g. to show the new style UNO service / multi inheritance interfaces.

  • required skills/knowledge: Java, C++, StarBASIC, UNO
Contact
dev@api.openoffice.org
Andreas.Bregas at sun.com


Calc

Calc: Show formula syntax in tip help

When a cell formula is being edited, in addition to the function selection above the cell, show some input hints (like the syntax of the function that is edited) in a tip help window below the cell.

  • required skills/knowledge: good C++ expertise
  • recommended skills/knowledge: -
Contact
dev@sc.openoffice.org
Niklas.Nebel at sun.com

Calc: Add resizeable margin on page preview

In the page preview, add the possibility to interactively change page margins by dragging an indicator, instead of using the page style dialog (see http://www.openoffice.org/issues/show_bug.cgi?id=51656).

  • required skills/knowledge: good C++ expertise
  • recommended skills/knowledge: -
Contact
dev@sc.openoffice.org
Niklas.Nebel at sun.com


Database Access

Linking external text tables into OOo databases

Native OOo Base databases (.odb) use the HSQLDB (http://hsqldb.org/) database engine. HSQLDB features a mechanism to link external text tables into the database, as if they were a native HSQL table (http://hsqldb.org/doc/guide/ch06.html).

The task of this project is to bring this feature to OpenOffice.org. For this, the respective database driver of OOo Base has to be extended with an API to administrate such text table links. Additionally, an user interface needs to be designed and implemented for using this API.

  • required skills/knowledge: C++, relational database concepts
  • recommended skills/knowledge: OOo's component technology (UNO)
  • useful skills/knowledge: HSQLDB text table concepts
Contact
dev@dba.openoffice.org
Frank.Schoenheit at Sun.COM

Native SQLite driver

SQLite (http://www.sqlite.org/) is a SQL database used as lean backend in a number of applications. The task is to write a native SDBC database driver (resp. finalize the existing skeleton: http://dba.openoffice.org/drivers/sqlite/index.html) for OpenOffice.org, accessing SQLite files efficiently.

  • required skills/knowledge: C++, relational database concepts
  • recommended skills/knowledge: SQLite API
  • useful skills/knowledge: OOo's component technology (UNO)
Contact
dev@dba.openoffice.org
Ocke.Janssen at Sun.COM

Embed Derby into OpenOffice.org databases

OpenOffice.org Base features an abstract mechanism to embed database backend files into OOo databases (.odb). Currently, this is implemented for HSQLDB (http:///hsqldb.org), which is used as OOo's default database engine.

To allow this feature for other engines, one must:

  • virtualize the engine's file access, so that it re-routes all its file operations through an abstract API.
  • implement this API on the OOo Base side

The project is to do those implementations for Apache Derby database (http://db.apache.org/derby/).

  • required skills/knowledge: C++
  • recommended skills/knowledge: relational database concepts
  • useful skills/knowledge: OOo's component technology (UNO)


Contact
dev@dba.openoffice.org
Ocke.Janssen at Sun.COM

Database driver UI modularization

OpenOffice.org Base follows a component-oriented approach for enabling database access. For this, database drivers are installed in OpenOffice.org which provide access to a certain (class of) database(s).

While at the driver level, the implementation is pretty good modularized, the UI implementation can be improved. Currently, there are a lot of places in the code with hard-coded information, such as "database X requires UI option Y".

The goal of this project is to design and implement a reasonable architecture for bringing a driver to the UI. The existing implementation needs to be migrated to this new architecture. As a proof of concept, an existing currently-external driver (e.g. http://dba.openoffice.org/drivers/postgresql/index.html) should be modified so that it can be deployed into an OOo installation and makes use of the features of the new architecture.

  • required skills/knowledge: C++
  • recommended skills/knowledge: OOo's component technology (UNO)
  • useful skills/knowledge: OOo's configuration concepts
Contact
dev@dba.openoffice.org
Frank.Schoenheit at Sun.COM

HSQLDB: single-file backend

HSQLDB (http:///hsqldb.org) is the database engine used by OpenOffice.org.

HSQL currently creates a number of adjacent files to store its data, where all files together comprise the whole database. To allow the user of OpenOffice.org Base to have a "all-in-one-file" database experience, those HSQL files are currently embedded in some OOo-specific container-file (the .odb file).

To overcome various disadvantages of this approach, it is desirable that HSQL stores its data in a single, large file. Preliminary code and concepts exist for this, but no final implementation.

This project needs to be worked on in close collaboration with the HSQLDB project, whose owner, Fred Toussi, will act as co-mentor.

  • required skills/knowledge: good Java expertise, relational databases
  • recommended skills/knowledge: HSQLDB architecture
Contact
dev@dba.openoffice.org
Frank.Schoenheit at Sun.COM


Framework

Performance: Fast native implemented OOo Dispatch Loader

Implementing a faster small Office Loader, independent from OOo libraries that uses native APIs to show the splashscreen. This will speed up UI response time after first Office start by 90 percent. Implementing propagation of command line parameters with a native pipe implementation. This will speed up loading of documents after double clicking them in the OS desktop environment. Remove any dependency to OOo libraries from the loader code, so that it is implemented with native APIs only. This allows the loader to be as small as possible and to run without any bootstrapping. This will reduce I/O overhead and unnecessary code execution at startup. Adjust the pipe implementation in desktop module to fit the native pipe implementations Prototypes of a Loader for Windows and Linux are available, implementing the required features at least on one platform.

Contact
dev@framework.openoffice.org
Hennes.Rohling at sun.com


Graphics

Filter: creating a Visio filter for OOo Draw

OOo currently lacks support for a Visio import filter, so that it would be good to have someone starting to write such a filter from scratch utilizing the OOo API for direct creation of the document or the ODF format as input format to be loaded by the OOo application. Although a full blown filter seems to be unrealistic to be written within the short timeframe, large parts of Visio documents should be able to be filtered correctly.

  • required skills/knowledge: good C++ expertise, graphics programming
  • recommended skills/knowledge: Visio file format / ODF or OOo API
Contact
dev@graphics.openoffice.org
Sven.Jacobi at Sun.COM

Stats

Source Code Repository Activity

Provide statistics for CVS repository activity. The first step would be a quick analyse what type of statistics other projects are providing. Together with our requirement to better understand how the code base and groups of committers are evolving this should give input to start work on the preparation of some nice stats and graphs about repository activity. Results should be generated with open-source tools, automatically and on a regular basis for the http://stats.openoffice.org website. Additionally an interface to cia would be helpful.

Contact
dev@stats.openoffice.org
Stefan Taxhet (stefan.taxhet at sun.com)

Tools

Integrating Autodoc generated IDL documentation into the Visual .NET IDE

Background

Autodoc (http://tools.openoffice.org), the OpenOffice.org (http://www.OpenOffice.org) documentation parser, creates a series of HTML documentation pages out of the SDK IDL files (see http://api.openoffice.org/docs/common/ref/com/sun/star/module-ix.html). The generated documentation can be integrated for example into Netbeans. “Integrated” means that from that IDE (integrated development environment) the documentation is accessible via internal indexes and/or context sensitive help. It would be useful to be able to integrate it also into other much used development environments, for example the Visual .NET IDE. Integration into the Visual .NET IDE can be done by providing some additional files that match the MS Help 2.0 format (see http://www.helpware.net/mshelp2/h20.htm for some information).

Task
  1. Enable Autodoc to provide the additionally needed files to integrate the created documentation into the Visual .NET IDE.
  2. Document the mechanism to compile those files and make the Autodoc generated documentation visible within the IDE.
Skills
  • Needed: Good C++.
  • Helpful: Knowledge about the OpenOffice.org SDK, experience with an IDE.
Contact
dev@tools.openoffice.org
Nikolai.Pretzell at sun.com

Writer

Writer: Improved Lotus WordPro Import Filter

Currently there is a very basic import filter for WordPro that only imports pure text. It would be desirable to import more content and structure from WordPro documents.

Contact
dev@sw.openoffice.org
Oliver.Specht at sun.com

Writer: Component for guessing the language of a text

Currently the OOo spell checker tries to guess the language of a text with an unknown word by searching for it in a fixed number of dictionaries or thesauri because checking all available languages would be too much. This limited search is inconvenient if the used language is not amongst the preselected ones. There are already known heuristic approaches to guess the possible language of a text, some of them are available as descriptions, some even as source code. Integrating such a component into OOo would improve working in multi language documents.

(Possibly useful references: #1, #2)

Contact
dev@sw.openoffice.org
Thomas.Lange at sun.com

Writer: Import Filter for Word Perfect Graphics files

The writerperfect import filter for WordPerfect(tm) documents, based on libwpd (http://libwpd.sourceforge.net), was integrated into the OOo2.0. The libwpd is a standalone library also used by other projects like KOffice or AbiWord. Another standalone library that reads WordPerfect graphics files would improve the interoperability with the WordPerfect Office Suite. An import filter for this file format based on this new standalone library can become embedded into OOo in the same way as libwpd. Please find more information at http://fridrich.blogspot.com/2006/04/wordperfect-graphics-conversion-wants.html."

Contact
dev@wp.openoffice.org
Fridrich Strba (fridrich_strba at openoffice.org)


Porting

Porting: Integrate the native Mac OS X FilePicker into OpenOffice.org (Aqua/X11)

Concerns : OpenOffice.org 2.0.3 or superior, for Mac OS X port (both Aqua and X11 versions)

Integrate the native Mac OS X FilePicker into OpenOffice.org The OOo FilePicker is already designed as a UNO component. What is needed is a new implementation of the FilePicker component based on the native Mac OS X FilePicker as it has been done on MS Windows for instance. On current Mac OS X port of OpenOffice.org, the current FilePicker is not native, less ergonomic.

Possible tasks :

Familiarize with the native Mac OS X FilePicker API and the OOo UNO interfaces for the FilePicker Describe current implementation : design, concerned modules, isolate classes and parameters to manage propose a new design using Apple API write and test a proof of concept

Skills : knowledge of languages C / C++ , using Carbon/Cocoa API

Proposed by : Tino Rachui

Contact
dev@porting.openoffice.org
Tino Rachui ( Tino dot Rachui at Sun dot COM )

Porting: Implement native font support, using native Apple API (Aqua / X11)

Does concern : OpenOffice.org 2.0.3 or superior, for Mac OS X port (both Aqua and X11 versions)

Subject proposed by : none yet

Tasks :

(1) analyze current implementation : design, concerned modules, isolate classes and parameters

(2) propose a design for the new one, using Apple API

(3) write and test a proof of concept

If enough time: (4) implement the solution, with possible backport to X11 version.

Skills : knowledge of languages C / C++ , using Carbon/Cocoa API, knowledge of font systems and font technology

Contact
dev@porting.openoffice.org
Eric Bachard (ericb at openoffice dot org)



OOo Project

SoC Sample Suggestion Title

Description

Contact
list@project
Contact Person (email at domain)
Personal tools