English:

The Free and Open Productivity Suite
Help us Help the World
Project Sections: Home | Specifications | QA | Development | Database Drivers
Development Sections: Developer Projects | Project Structure

Developer Projects

Below is a list of projects which could be implemented by interested developers. Most of these projects are relatively self-contained, and do not require too much knowledge about OOo's code infrastructure.

Note that this list doesn't claim to be a complete repository of what will be done in the near/medium future. There may be items on the list which will never be realized, and there definately are items which are not on the list, but will be implemented.

If you are interested in anything from the list, please speak at dev@dba.openoffice.org. We'll gladly help you to get started on this.

Also, make sure you don't miss OpenOffice.org's global TODO list, which also contains interesting projects for developers.

Here is what you'll find below:

  1. Joins in dBase queries
  2. SDBC driver for LDAP directories
  3. New/Enhanced Form Controls
  4. Dialogs with Form Functionality
  5. Database driver UI modularization
  6. HSQLDB: single-file backend
  7. Embed Derby into OpenOffice.org databases
  8. native, cross-platform access to MS Access databases
  9. SDBC driver for vCards
  10. New Filter Dialog

General Notes

Whenever we talk about user interface work, this implies working with VCL, the Visual Class Library in OpenOffice.org. If you are not familar with it, you will curse it, since especially some of the older parts never heard the word "documentation". On the other hand: In opposite to the native platform controls, everything is there as source code, so if you like "learning by debugging", you will love VCL smile.

Additionally, be aware of the fact that feature implementations in OpenOffice.org require a specification (you may visit the specifications project for more information). There's a rule that nothing is checked into the master branch which doesn't have a specification which all stakeholders agreed upon - so unlike other open source projects you may know, the specification really is an important part. Stakeholders are: the documentation team, the user experience team, the quality assurance team, and development. Usually, one representative from every team needs to accept your specification.

Well, don't let this hinder you in starting. Just be aware that there will be a time when a specification is finally needed. Most developers don't like writing such documents (and some people even claim that they shouldn't). Thus, you need to clarify who will take this for you, if you can't/don't want.

A note about the effort: This is a rather rough guess at the moment. In general, it may be a good idea to add two or more weeks or so simply for becoming familar with the code and some concepts, so if it is "2 weeks", don't expect to start today and finish it in 14 days ...


Joins in dBase queries

The descirption of this project has been moved to our Wiki.


SDBC driver for LDAP directories

The descirption of this project has been moved to our Wiki.


New/Enhanced Form Controls

The descirption of this project has been moved to our Wiki.


Dialogs with Form Functionality

description

When creating a form, the user always needs to bother with a writer (or calc or draw) document. Very often, this is much too oversized. It would be sufficient to have a simple dialog which contains all the data access controls. Now that we have UNO-based dialogs (in the Basic IDE), this is possible in general, as there already are some basics for doing this. There still would be a lot of work to be done (not mentioning the concrete design), but since some months, it's at least possible.

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 (and even do autosizing according to the previous instance of the same document type, the screen resolution, whatever), which is nothing you expect from a carefully designed form, where controls are placed at concrete positions and have a fixed size.

required skills
  • C++
  • UNO
useful skills
  • familarity with OOo's database access and form API
  • familarity with OOo's toolkit API (module com.sun.star.awt)
estimated effort 3 months
difficulty high


Database driver UI modularization

description

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. the native PostgreSQL driver) 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
  • C++
useful skills
  • OOo's component technology (UNO)
  • OOo's configuration concepts
estimated effort 2 months
difficulty high


HSQLDB: single-file backend

description

HSQLDB is the default database engine used by OpenOffice.org Base.

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

The following project description was provided by Fred Toussi, HSQLDB project owner:

Currently, HSQLDB stores the database information in four separate files. These files are written to using different API�s. Streams are used for some while random access is used for others.

The project�s aim is to allow a single file to be used for all permanent data (temporary session data, or file locking may still use a separate file). So existing files that need to be integrated into one are the .properties, .log, .data and .backup files. The new single file will be accessed only as a random access file.

The project consists of developing an interface between exsisting code. At the low level, there is already an implementation of a random access file, org.hsqldb.persist.ScaledRAFile. The new interfaces will allow existing file services to use the single random access file.

All the files in the org.hsqldb.persist package should be studied, with the understanding that the funtionality of many of these files, including lock and property saving functionality, will become redundant with the introduction of single file persistence.

The student is expected to study and become proficient in the Java IO packages and the API calls to these packages currently made from HSQLDB, and write the code and test packages.

The mentor will provide regular guidance and help on the design of required interfaces and supervise their implementation.

As this is considered an essential development for HSQLDB, all the work done by the student will be used, and if necessary, modified or improved by other project developers. The student will get due credit and will be provided with work references by the HSQLDB Project Maintainer upon successful completion of the project.

required skills
  • Java expertise
  • relational databases
useful skills
  • HSQLDB architecture
estimated effort 2 months
difficulty high


Embed Derby into OpenOffice.org databases

The descirption of this project has been moved to our Wiki.

See also some old information on this topic from the dba@dev.openoffice.org archives.


Native, cross-platform access to MS Access databases

description

preliminary note: In the meantime, there is an alpha version of a driver for this. It's an OOo database driver which uses MDB Tools to read MS Access databases. See it's home page for more info.

A major goal of OpenOffice.org is interoperability with other office applications, especially with a certain office suite which currently has some greater market share than OpenOffice.org has :).

Unfortunately, currently OOo users, as long as they don't work on Windows, are not able at all to access the databases of this office suite - we cannot read MDB files on platforms other than Windows (where we can use Microsofts own API).

So the goal here is to allow Linux users to at least read the data from MDB files, using OOo.

There are several ways how this could be done.
One is to use MDB Tools, and wrap them in OOo. Since the SQL capabilities of the MDB Tools parser are limited (e.g., no OR conditions in WHERE clauses are allowed), this requires work in either MDB Tools itself (by improving their parser), or it would be used as provider for raw data, and OOo would faciliate it's own parser/query engine (which unfortunately is also limited) to process this data.
Another current disadvantage of MDB Tools is that it doesn't handle UTF8, and since jet4 databases stored their data in UTF8, this implies that it cannot be used for jet4 databases containing non-ASCII characters (well, probably a little bit more that ASCII, but it's a serious limitation for an product as international as OpenOffice.org).

Another way would be to re-engineer the MDB format ourself, and write a native SDBC driver (which could be in C++ or probably even in Java) which provides the data. This is similar to the first approach, where MDB Tools would have been used as the provider of raw data.

required skills
  • C++
useful skills
  • familarity with OOo's database access API
estimated effort 2 months
difficulty medium


SDBC driver for vCards

description

OpenOffice.org has it's own open database access API called SDBC which is modeled on the architecture of Java's JDBC. SDBC supports several databases and database-like API's via an extensible provider architecture; ODBC 3.0, JDBC, ADO, dBase and CSV are among the databases and database management systems currently supported. Each SDBC provider is implemented as a UNO component.

It could be useful to have a dedicated driver for accessign vCards. There is an infrastructure in the existing SDBC implementations for file-based databases, which could be relatively easily specialized for vCard access. This would broaden the range of address book data which can be used in OpenOffice.org.

required skills
  • C++
  • familarity with UNO
useful skills
  • familarity with OOo's database access API
estimated effort 2 weeks
difficulty medium


New Filter Dialog

description

Similar to the Sort Dialog, there is a dialog which allows to filter queries and tables – it can be reached the same way as the sort dialog, by using the "Default Filter..." button in the toolbox of the data source browser.

This dialog suffers from some disadvantages:

This dialog should be re-implemented, so that it's functionality is extended and it's more intuitive. Design (before implementation) is an important part of this project.

One other place where a similar functionality is available is the filter navigator in the form based filter.

This will show the so-called filter navigator, which uses a tree view to represent the currently used filter for the form. It has other disadvantages

If the interface of the new implementation of the filter control in the new filter dialog is abstract enough, then on the long term we can use it for the filter navigator, too. This would require some discipline in designing the classes for the new implementations, and some abstraction capabilities. However, this is not the primary goal of this implementaton.

required skills
  • C++
useful skills
  • familarity with VCL (OpenOffice.org's visual toolkit)
estimated effort 1 month for an experienced developer
difficulty medium - high

Logo ApacheCon Europe 2014

Apache Feather

Copyright & License | Privacy | Website Feedback | Contact Us | Donate | Thanks

Apache, the Apache feather logo, and OpenOffice are trademarks of The Apache Software Foundation. OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.