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.

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
.

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

SDBC driver for LDAP directories

New/Enhanced Form Controls

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.

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

Embed Derby into OpenOffice.org databases

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:

it's not dynamic, three filter criterions are the maximum

The dialog does not really clearly distinguish between ORing and ANDing
filters. Though there the user can make a choice for AND or OR, it's not clear
what is the result if these are
mixed. This UI is simply not
intuitive.

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

it's impossible to add a filter with two AND criterions for the same column,
such as "name LIKE '%Foo%" and "name LIKE '%Bar%'".

it's not intuitive, too (well, this is personal taste :)

some functionality cannot be accessed from within the navigator, but only by
entering text in the form fields (for instance, try creating a new filter in a
form which previously does not have any filter

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.

Apache and the Apache feather logo are trademarks of The Apache Software Foundation.
OpenOffice, 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.