To-Dos

From OpenOffice.org Wiki

(Redirected from To-Do List)
Jump to: navigation, search

OpenOffice.org has many things which one could work on ... just see below :-)

Contents

API/To-Dos

Here you can find a list of ongoing or new to-dos in the area of the API project. If you are interested to help in this project please take a closer look on tihs list. Maybe you can find something interesting or if not please contact the project owner Jürgen Schmidt for more ideas or information.

The single to-dos are flagged to show the degree of difficulty.

easy should be quite easy, maybe some initial time is necessary to get some domain knowledge of the specific topic. But in general easy even for beginners
experienced for this to-dos a good base knowledge of the domain area where this to-do belongs to is helpful or required
advanced you should have advanced knowledge of the domain area where the to-dos belongs to


New Code Snippets

easy

Our famous Code Snippet Base always needs help. We are always looking for new snippets or translations of existing snippets into one of the other languages. It is a really good entry point to play a little bit with the API and learn for example the specifics for your preferred programming language. If you are interested please take a look on the How to contribute description or contact the project owner Jürgen Schmidt

Linguistic review of the API reference

easy

The API is specified in UNOIDL, a Corba IDL like interface definition language, and based on this UNOIDL files we generate a html reference documentation. This documentation is mainly written by non native speakers and can be improved always. If you are interested in doing some linguistic review of this documentation or to improve the existing documentation please contact the project owner Jürgen Schmidt

API tutorials

easy

Take for example a SDK example and document it step by step or convert it from Java to C++. Create a new tutorial in the Wiki and help in this way to spread the knowledge. Creating a tutorial is a good way to get started for yourself and it helps other users to get started as well.
If you have a specific use-case and have already implemented a solution for it, you are also welcome to provide it as a tutorial especially when it shows the usage of a specific API or a general API concept (e.g. working with textfields, ...)

Dynamic UNOIDL Reference Browser

easy - experienced required/useful skills: Java, UNO, XML and XSLT

We search for help to bring this GSOC project forward. The next steps are to build it as a component, improve the XSL transformation to be more javadoc compatible and to generate a javadoc like index .... The goal of this project is to provide a working reference browser in the internal StarBasic IDE. If you are interested in this interesting project please visit the project page of the Dynamic UNOIDL Reference Browser for more detailed info and feel free to contact Jürgen Schmidt for more information.

Enhance the uno-skeletonmaker

experienced

The uno-skeletonmaker is a useful tool to speed up the development of UNO components. Currently the tool can generate code for general UNO components as well as specific service provider interfaces (SPI) like calc add-ins or add-ons. The idea is to enhance the skeleton maker to support more SPI's and to make it more customizable. That means for example to allow prefixing of parameter names as well as internal member variables of generated classes. A further improvement can be the support of Python as a further programming language. Currently only Java and C++ are supported. For more detailed information feel free to contact Jürgen Schmidt.

Enhance NetBeans OpenOffice.org API plugin

advanced

The NetBeans OpenOffice.org API plugin is a useful tool to speed up the development of Java extensions for OpenOffice.org. But the design is not limited to Java only. The idea is to allow the selection of the programming language in the wizards and to generate the related Java or C++ project in the end. NetBeans offers already C++ support but to make use of it in the plugin it is necessary to do some research how a typical OpenOffice.org extension project can look like in NetBeans. The definition of C++ template projects is one part of this project. These templates will be later used in the plugin to generate new projects based on the collected information from the wizards. For more detailed information feel free to contact Jürgen Schmidt.

UNO awt graphical design editor in NetBeans

advanced

For powerful extensions it is often necessary to design own dialogs that fits perfect in the office environment. The internal Basic dialog editor from the office can be used for general use in the Java or C++ extensions as well but the whole design editor has limited capabilities. Currently there is some ongoing work to define a new xml based resource format that allows to define more layout constraints in the resou8rces already. A good and working layout manager is missing for a long time and this ongoing work looks at least promising. The idea is to enhance the really easy to use graphical GUI editor from NetBeans and adapt it to allow the design of UNO awt dialogs. A new limited palette with UNO awt controls have to be designed. The next step is to provide a transformation from the NetBeans internal *.forms files into the office xml resource format and vice versa. It's just a first idea and many many things have to be researched and defined. If you are interested in this experienced project feel free to contact Jürgen Schmidt for more information.

Application Documentation and Help Development To Do

This list of to-dos gives some ideas where in the Application Help your contribution may be needed most.

Writing new guides

The documentation project and application help offer users the means to get an understanding of using OpenOffice.org. The following list applies to both aspects of the project. So you can help with guides, HOW-TOs, Template development and making Application Help better.

For creating manuals, guides et cetera, use the appropriate templates for preparing publishable documents.

  • See documentation main page for a general view of the various resources.
  • See specification page for information on new and changed features in the various modules that make up OpenOffice.org
  • Guides for Calc DataPilot
  • Improving Calc function references (a big thank you to David King for his help, see issue 71289)
  • Guides for new Chart Module (a big thank you to Regina for her updated files, see issue 60360)
  • Guides for Base Connectivity (all platforms): ODBC, JDBC, MySQL, Access
  • Guides for using form controls to create form documents
  • Guides for Writer Envelopes, Labels, Business Cards
  • Guide for all types of text boxes, see 45152 what happens after HTML or PDF export?
  • Guides for Writer Mail Merge
  • Guides for Writer Numbering/Bullets
  • Guides for XForms documents
  • Guides for Impress Slides & Master slides
  • Guides for Impress Effects
  • Meta guides for Submitting OLH issues
  • Meta guides for Fixing OLH issues
  • Meta guides for Delivering OLH as Extensions
  • Help with restructuring of Application Help for OOo 3, see issue 52158
  • Work with different stakeholders to publish the Application Help pages on the Web, making them bookmarkable and googleable
  • Guide for Regular Expression Searches
  • Guide for Mail Merge
  • New Start page for Tools-Options (see also 54487)
  • Troubleshooting Information
  • Introductory table guides for Writer, Calc and Base

and much more...

Improving existing guides

All guides of all modules should get navigation links to easily click through to the next/previous/parent page. You can submit an idea how to define a consecutive order for the existing guides.

Coding Help

As a developer with good programming skills and much energy and time, you can help to improve the Help in many ways. For example, we would like to improve the Help Viewer to fully support the Gecko rendering engine.

Standardisation of Help source files

Some help sources and related files need to be brought fully in line with the current specifications. See Help: Standardisation issues.

Content on this page is licensed under the Public Documentation License (PDL).



Architecture/To-Dos

This page intends to collect various architectural deficiencies (aka the pet peeves of various people) of OpenOffice.org, and lists the areas where's work in progress to improve on the architecture.

Depending on the specific count algorithm, OOo consists of approximately 7E6 lines of code (the overwhelming lot being c++, all other being an order of magnitude less (Java, Perl, Basic, Python)). This sheer size in and of itself is a problem - the code base is notorious for crashing or slowing down to a crawl various software engineering tools, from debugger to dependency analysis to reverse design extraction.

The code itself varies greatly in quality, style, and age (the latter invariably leading to the former, if you recall the history and evolvement of c++), with parts being there virtually unmodified for 10+ years, and others just recently written from scratch.

Taken together, this leads to a lot of complexity and redundancy, which is very hard to remove.

Facing this amount of code, the big rules must be:

  • simplify
    • remove internal redundancy
    • remove external redundancy (use external projects, whereever possible)
    • remove unused or dead code
    • remove legacy functionality, which does no longer provide noticeable value (e.g. binfilter)
  • refactor for orthogonality
    • make subsystems implement independent functionality
    • enable combinations of those subsystems to be freely combinable
    • carry that to the UI level (no artificial restrictions on what one can do with UI objects - e.g. shapes can be rotated, and clearly text frames should, too)


Architectural To-Dos

Infrastructure Improvements

  • Speeding up the build system, and maybe even make it consider global dependencies (currently, OOo has the notion of modules, which approximately map to toplevel directories in the build tree. Automatic build-time dependency calculation is currently only available on the intra-module level).
  • Making the actual design more accessible, improving upon existing solutions like LXR or Bonsai. Ultimately, this should result in refactorings of the source code being both much easier and much safer than today, by providing information where and how specific functionality is used. A prerequisite for that would be a parser that really knows about c++ - gccxml might be a starting point.


Runtime System Improvements

This is about making the implementation languages safer, and easier to use. What follows could also be subsumed under "transparency on the implementation level". When something can be used transparently, or appears transparent to a user, it is an implementation aspect she need not care about. Being able to program in an environment which is transparent with regard to lots of aspects, empowers the developer to focus on the problem at hand, not having to litter her code with mundane tasks such as memory management or locking.

  • Make threading transparent. Currently, fulfilling the contract of a UNO component regarding thread-safeness is
  1. tedious work, because normally each involved object has to acquire and release a mutex on method entry and exit, respectively
  2. almost impossible to get right, let alone verified to work correctly (no races, no deadlocks), because of the sheer mass of involved objects and mutices (the number of distinct states that would have to be checked for a proper verification is intractable for anything but the most trivial examples). The upcoming extended Binary Uno threading-model makes thread-safeness transparent, by automatically locking and unlocking when entering or exiting components on a much coarser level than single methods.
  • Make other mundane stuff transparent. Like memory management (via garbage collection, or refcounting via smart ptrs, UNO reference), or transactionality (the mode of making changes take place either completely, or not at all. Having a component behave in a non-transactional way in the face of an error makes recovery rather hard. There's more to transactionality than exception-safeness. Imagine two users collaborating on the same document).

General Refactoring Improvements

For many reasons the OpenOffice.org codebase is difficult to understand and navigate. On of the reasons is a lack of cleanup in the code. There is a never ending list of things that ought to be done-- add some of your own.

  • Actually remove deprecated things. Things like String and UniString need to go. svtools and tools have loads of stuff that is duplicated elsewhere or is deprecated. Getting rid of these sorts of things will make maintaining application code much easier.
  • Document things. Some of the code has comments that at one time were correct. Some code has German comments. While most of the OpenOffice.org programmers sind Deutschschprachig, there is an unofficial understanding that German comments mean "don't touch."

Code Improvements

Remove unused code

Binary Loading/Saving stuff in ItemSets, depend on EditEngine Loading/Saving (only used for Clipboard) - MT

Remove duplicate code

Consolidate slightly copied and modified code.

  • BigPointerArray vs. SvPointerArray
  • RTL Strings with Tools Strings

Consolidate Text Engines

  • Text Engine
  • Writer Engine
  • Edit Engine

Replace code with 3rd party

Replace self made containers with STL containers.

  • Tools Container
  • SvPointerArray, BigPointerArray
  • "GetPos" is mostly used wrong -> remove it (algorithmic complexity to hight O(n*n))

Improve modularity

?Clear "Mission Statements" for modules?

VCL

get rid of internal event queue.

Framework Improvements

The framework module already has a very modular architecture solely based on UNO components. Amongst others, it manages menus and toolbars, but it does not manage docked windows like e.g. navigator or impress task pane. These windows are still managed in sfx2 and their implementations are based on sfx2 classes. No non-sfx2 based module can use them.

Here's the roadmap:

  • add a LayoutManager for DockingWindows to the framework module that works in the same way as the LayoutManager for toolbars
  • implement docking handlers for the windows managed by this LayoutManager in the same way as for the toolbars
  • provide factories for the sfx2 based implementations of Docking Windows
  • simplify the frame classes in sfx2; without the sfx internal layout manager for DockingWindows only one "frame" class is necessary
  • put the current container windows inside of task windows managed by a Task service (later they might become tabs in a tab bar)
  • move the LayoutManager from the frame to the task (or add some "super manager") so that frames can share their tools

Amongst others this will allow to have more than one view to one ("split view") or several documents in one system task window.

Status Quo

The new LayoutManager and the docking handlers are already worked on and nearly finished. Next step will be the mentioned factories. There also is a prototype for a task window and a task service that can be adjusted to our needs. The biggest challenge currently is the "super manager".

Application-specific Improvements

One of the lingering problems on the application level is the fact that, in spite of modularized lower-level functionality, application functionality cannot be shared between OOo's applications (except via embedding of a whole application (OLE)). This is because for neither Calc nor Writer, there are reusable application engines, like a text engine providing text editing and layouting functionality, or a table engine providing formula and calculation support. Draw/Impress already uses a shared engine, dubbed 'Drawing Layer'. But there's still considerable functionality hidden in the application code, which is worth extracting. Especially the missing Writer engine manifests itself in duplicated text editing functionality in EditEngine and TextEngine (used by Impress and Calc for their corresponding text functionality).

Example 1

The Writer uses a different implementation when displaying pictures, opposed to Draw/Impress. Thus, if you insert a picture into a writer document, you have a different feature set available as in Draw/Impress or Calc. For example, the Writer graphic object is able to render a variety of border styles, but at the same time, is unable to rotate the picture. To have rotated pictures in Writer, one has to insert that picture in a Draw document, copy the resulting drawing layer object, and paste that into Writer.

Example 2

The Draw/Impress applications use a different implementation for displaying text, as opposed to the Writer. Thus, if you insert a text shape in Impress, you can't have two-column layout with it, nor does it provide change tracking ('redlining'). On the other hand, the Writer's fly frames, which superficially perform the same task as the Impress text shape, cannot be rotated.

Another area of improvement is rendering. Currently, all application's graphical output is based on the OutputDevice class, which provides only very basic rendering facilities (in fact, besides largely extended text output functionality (to handle OOo's i18n requirements), this interface has basically remained unchanged for a long time). Specifically, things like performant alpha compositing or anti-aliased geometry rendering are extremely hard to achieve with the current design. Therefore, starting with OOo 2.0, the XCanvas interface is slated to gradually replace OutputDevice in all applications.

Writer

  • break up the monolith
  • make the import filters more modular
  • port rendering to XCanvas

Calc

See Calc/To-Dos

Draw/Impress

  • break up the monolith
  • become more decoupled from sfx2
  • redesign API ( performance)
  • Allow slides to inherit animations from the master slide

Framework/To-Dos

You can find a list of tasks that we would like to implement but until now didn't find the time to do so. These tasks can be implemented by experienced C++ developers that want to help us. You would definitely get support or help of the regular framework developers. If you are interested to work on one of these tasks please contact us on our "dev" mailing list or via e-mail to the framework project lead.

  • Vista Shell Extensions
    • issue 72556   Use new FileOpenDialog. OOo should support the same Look & Feel then other Vista programs does.
    • issue 71112   Desktop full text search in ODF Documents doesn't work.
    • issue 70944   Meta information will not shown in explorer.
  • OpenOffice.org startup. Optimizing the startup process, find bottlenecks and refactor libraries so we don't load unnecessary code.
  • Toolbar and popup menu controllers which are more powerful and easier to use than the current ones.
  • Cleanup the svtools configuration items (make them write-through instead of write-back with their own cache) to support immediate updates on configuration changes.
  • Update the 'Tools - Options' dialogs to support the read-only OpenOffice.org configuration item state.
  • A search toolbar as an extensions (see Firefox search bar)
  • Add support for user-defined properties in the document properties dialog
  • Brush-up the "Styles and Formatting" floating window
  • Brush-up the "Templates" dialog
  • User interface to associate templates to existing documents
  • Docking windows accessible via UNO API and extensions.

Porting/To-Dos

OpenOffice.org Platform Technology: Mac OS X -- Carbon Port with Aqua NWF

Currently the Mac OS X port OpenOffice.org requires an X11 server at runtime. This adds an additional burden to installation, and adds a huge footprint on startup performance. Further on it disables a native look and feel. Providing a port based on Carbon, using an Aqua Native Widget Framework will add tremendously to the acceptance of the Macintosh version and will be a highly visible and well received feature. The project is in need of developers, testers, qa, etc. Contact 

   * mac@porting.openoffice.org
   * Eric Bachard (ericb at openoffice.org)

Links for Mac OS X Carbon port

http://wiki.services.openoffice.org/wiki/User:Ericb

http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s

Helping push a particular port forward (sparc, arm, netbsd, etc, etc)

Contact 

   * dev@porting.openoffice.org
   * Martin Hollmichel (mh at openoffice.org)


Working with affiliated patch trees to speed integration of patches

From the Ximian build system and other third party developers into OOo Contact 

   * dev@porting.openoffice.org
   * Martin Hollmichel (mh at openoffice.org), Michael Meeks(mmeeks at openoffice.org)

Mac OS X Porting - Work Areas/ToDos

This page is intended to serve as a living ToDo list for the OpenOffice.org Mac OS X port. To keep things simple it contains the ToDos for both the X11 version and the upcoming Aqua version of OpenOffice.org for Mac OS X. The page is divided into different work areas which either assigned to a person in charge or are unassigned yet. Below each area there is a detailed list of todos which has to be maintained by the respective people himself. Persons who are in charge of a certain area are responsible for keeping their respective part of the page up-to-date.


If you're interested in contributing to the project please coordinate with Eric Bachard

Areas and ToDos Aqua Version


Messaging Tino Rachui
Todo Status Assigned to
Implement messaging infrastructure New Unassigned


Windowing Tino Rachui
Todo Status Assigned to
Implement salframe.cxx New Unassigned


Drawing Stephan Schaefer
Todo Status Assigned to
Implement drawing support In progress Stephan Schaefer


Native Printing support Yvan BARTHÉLEMY
Todo Status Assigned to
Make some docs Done Yvan BARTHÉLEMY
Native look & feel for Print and Print Setup In progress Yvan BARTHÉLEMY
Panel for OpenOffice.org specific options New Unassigned
Implement native Print support New Unassigned
Implement native Print setup New Unassigned

Work in progress, see: Mac OS X Porting - Native Printing

Description:

OpenOffice.org side:

AquaSalPrinter class is located in aqua/source/gdi/salprn.cxx

Headers are in: 

vcl/inc/salinst.hxx 
vcl/inc/salgdi.hxx  
vcl/inc/salprn.hxx

Aqua implementation:
aqua/inc/salprn.h (AquaSalPrinter class implementation, inherits from SalPrinter)


Mac OS X API side:

Todo: implement missing methods, using Carbon API

Link for Mac OS X API documentation:

http://developer.apple.com/documentation/Carbon/Reference/CarbonPrintingManager_Ref/index.html



Key input Unassigned
Todo Status Assigned to
accelerators for native menu In progress Ismael



Native sound support
Todo Status Assigned to
Implement native sound support Started Eric Bachard


New page has been updated.

See: Native Sound Implementation on Mac OS X

Estimation of code remaining to write: 40% (macosxplayer.cxx mainly)


Image Acquisition Eric Bachard
Todo Status Assigned to
Implement Image Acquisition In progress Eric Bachard

See: Mac OS X Porting - Data Acquisition



Native font support Eric Bachard
Todo Status Assigned to
ATS Started Eric Bachard

salatslayout.cxx License origin is justified here: http://qa.openoffice.org/issues/show_bug.cgi?id=23283]

OpenOffice.org side:

See : Mac OS X Porting - Native Fonts 

Carbon API implementation (binding) is made in salatslayout.cxx

ATS and ATSUI starting point: http://developer.apple.com/documentation/Carbon/Conceptual/ATS_Concepts/atsfonts_intro/chapter_1_section_1.html

Apple's starting page leading to deeper docs: http://developer.apple.com/documentation/TextFonts/Typography-date.html

Todo-list for native font implementation: 

- missing methods (to be implemented):

bool ATSLayout::GetGlyphOutlines()
ATSLayout::InitFont()
ATSLayout::MoveGlyph()
ATSLayout::DropGlyph()
ATSLayout::Simplify()

- Fix known bugs:
 MultiLine does not work (writer cannot be used, because)
 Bad keyboard/charset ? (missig chars)
 When redrawing, everything is redrawn using the most little font size -> even the dialog boxes on menu bars
 Bad values returned 

- Implement MultiSalLayout
- Complete implementation  
- read Apple API [ Work in progress]
- describe current implementation: organisation / design [work in progress]
- design of new implementation [FIXME] find examples

Estimation of code remaining to write ~40 %

Done (mainly Stephan Schaefer, with initial salatslayout.cxx file written by Herbert Duerr)

Work in progress : understand MultiSalLayout

Resources: use sample code to test/initialize ATS server (using e.g. ATSUIDirectAccessDemo)

For more informations, see: Mac OS X Porting - Native Fonts

Areas and ToDos X11 Version

Packaging
Packaging related tasks 		Oliver Braun
Todo Status Assigned to
Improved packaging for OOo Done Oliver Braun


Installation
Installation related tasks 		Oliver Braun
Todo Status Assigned to
Provide an improved installer for OOo New Oliver Braun
Error messages during installation when no X11 is installed Started (messages need to be localised and more info supplied) Unassigned
Support language pack instalation New Unassigned


Desktop Integration
Desktop integration related tasks 		Oliver Braun
Todo Status Assigned to
Allow opening of documents with path names that need to be escaped for shell scripts Integrated for 2.1 see [1] Shaun McDonald
Save documents in ~/Documents by default New Unassigned
Use the Mac OS X key chain for document signing New Unassigned
Read proxy settings and user information from the system settings New Unassigned
Mac OS X address book integration New Unassigned
Make use of the Mac OS X spell checker New Unassigned
Improved clipboard support New Unassigned
Support for standard Mac OS X shortcuts according to HI guideline New Unassigned
Integrate native FileOpen/FileSave dialog into OOo Started Florian Heckl


Printing Unassigned
Todo Status Assigned to
Improved printing support (CUPS) Done Oliver Braun
Use the native print dialog in OOo New Unassigned



Ease of use Unassigned
Todo Status Assigned to
Reduce visible toolbars New Unassgined
Suppress icons in OOo menus by default New Unassigned
Suppress xterm window when launching OOo New Unassigned


Implement NeoLight plugin Unassigned
Todo Status Assigned to
Implement NeoLight (spothlight plugin) in OpenOffice.org 2.0. For more informations, please have a look at [2] New Unassigned


Assurance Quality and Mac OS X port


Mac OS X QA Unassigned
Todo Status Assigned to
Collect informations and manage Mac OS X QA on the wiki New Unassigned


NLC:whatshot

OOo Native Language Confederation

Please view the wiki usage guidelines
before contributing.

Categories:

Pages:

Projects on NLC Wiki: (edit list)
NLC on the main site


View or edit this template.

What's hot in the NLC ?

On this page you will find a quick and dirty list of ToDos and urgent matters that need to be addressed. This page is updated frequently. There is also an area called the "ChalkBoard" that lets you write daily thoughts and important messages.

The Quick and Dirty List

Documentation ClearingHouse Initiative: help bring consistant documentation to the Native-Lang projects!

  • Deadline for 2.4 localization: [3]

The Chalkboard

Qa/To-Dos

Official QA'ing of contributed builds

From other locales or lesser known ports Contact 

   * dev@porting.openoffice.org or dev@qa.openoffice.org
   * Kevin Hendricks (khendricks at openoffice.org)

More formal regression testing

Contact 

   * dev@porting.openoffice.org
   * Kevin Hendricks (khendricks at openoffice.org)

Bug Tracking System statistics

Provide statistics issues submitted per time, number of active contributors, etc 

   * dev@tools.openoffice.org
   * Martin Hollmichel (mh at openoffice.org)

Stats/To-Dos

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 [4] cia would be helpful. 

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

SVG Import ToDo

ToDo list for SVG Import Filter

OOoSVG-110.png
SVG Import
(external impl.)
Overview
Download
Source code
Features
Restrictions
FAQ
TODO
OpenDocument
Gradients
Group opacity
Elliptic arcs
Path semantics
Coordinate systems
  • Fix the import of opacity gradients.
    • Implemented in r2131.
  • Provide a better approximation for (especially radial) color gradients.
    • Implemented in r2131.
  • Add import of embedded bitmaps.
    • This is especially important for importing MS Visio drawings containing icons.
    • Implemented in r2131.
  • Close files properly after import.
  • Improve text placement.

-- Bernhard Haumacher - 12 Oct 2005

Tools/To-Dos

Maintaining tinderbox builds for all available platforms

   * tinderbox@tools.openoffice.org
   * Michael Meeks (mmeeks at openoffice.org)

OpenOffice.org Platform Technology: Faster Startup

Probably the most discussed problem since StarOffice 4.0. One first shot would be to optimize library exports. Contact 

   * dev@tools.openoffice.org
   * Martin Hollmichel (martin.hollmichel at sun.com)

Code Analysis

Keeping the code flexible, maintainable, extensible, is highly desired. However the current state of the code is quite opaque. Providing tools to detect areas that became or become prone to be examined would be highly desirable. Contact 

   * dev@tools.openoffice.org
   * Martin Hollmichel (martin.hollmichel at sun.com)

Uno/To-Dos

To-Dos and potential To-Dos.

General

Clear Separation of C and C++ Uno

There are various obstacles in the way to cleanly separate C Uno (AKA Binary Uno) from C++ Uno. Some of these are

  • the C Uno runtime is implemented in C++,
  • a C++ Uno runtime would be stacked on top of C Uno,
  • there is no living C language binding,
  • the C++ Uno runtime offers various functions for bootstrapping Uno, which are not yet available for Binary Uno.
  • Upper level modules headers may not be used, until they are delivered, even if they are self contained.

Some of the obvious tasks are:

Bugs

Naming / Clean up

  • Rename module udk/cppu to reflect that it is implementing the Binary Uno runtime.
  • Rename module udk/cppuhelper to reflect that it is implementing the C++ Uno runtime.
  • Rename the Binary Uno to JNI (Jave Native Interface) bridge: java_uno -> jni_uno. Because that is what the bridge is about.
  • Rename the Binary Uno to Remote Uno bridge: urp_uno -> remote_uno. Because that is what the bridge is about (actually, there is no URP object to program against, at least not in Binary Uno).
  • Remove the "lib" prefixes under UNIX from the Binary Uno bridges.
  • Rename udk/cpputools to something like "unotools" (unfortunately this name is already in use).
  • Mark SAL_IMPLEMENT_MAIN_WITH_ARGS as deprecated, the right way to deal with args are the RTL command line arg functions, see porting/sal/inc/rtl/process.h

Simplification and Performance

  • Remove the Binary Uno Object Binary Interface (OBI) (struct uno_Interface) and friends, replace it with one of the platform C++ OBIs.
  • Support direct access of Uno types in Uno IDL, without includes.
  • Let the *makers retrieve type information from the type providers and not from rdb files.
  • Harmonize initial object access for Remote Uno and components -> it is actually the same. E.g. 
    "uno:library;[gcc3];<implementation name>"
    may be used to access an instance factory, or any other object of interest.
  • Leverage Purpose Bridges for global variables, e.g. the "ServiceManager" or the "ComponentContext". Use this for bootstrapping as well. E.g. 
    Reference<XComponentContext> cppu::getComponentContext();
    always returns the current component context. It is usable in components, libraries or applications and may even bootstrap Uno, if no context is available yet.
  • Remove all exception specifications.
  • Consolidate the Binary Uno structs "uno_Environment" and "uno_ExtEnvironment".
  • Remove #ifndef EXCEPTIONS_OFF macros, actually C++ Uno is not usable without exceptions anyway.
  • Is SAL_CALL really necessary for "inline" stuff? If not, remove it.
  • Unify command line interface for all Uno tools.
  • Convert the ProxyFactory service into a library and deprecate it.

Features

Tests

Writer ToDo

Intro

Here is a list of things that we would like to implement but until now didn't find the time to do so. In our opinion all of these tasks can be done by experienced C++ developers that are willing to enter the interesting world of OOo Writer. They can reckon on the support or the help of the regular Writer developers. If you are interested in working on one of these tasks please get in touch with us on our "dev" mailing list or via private mail to the Writer project lead. We can talk about existing specifications, ideas, stuff to read or hack etc.


Additional ToDo's Pages

Features with a high number of votes

Baseline Alignment of formula and text in writer

Issue 972

The implementation of this features comprises some work in Math and Writer. Math is a comparable small module so starting here as a new developer is doable even in a short time frame. In Writer the algorithm for object positioning must me changed, something that is considered to be one of the harder jobs. Some additional work in UI and file format.


Reveal Formatting Codes

Issue 3395

Especially former WordPerfect users very often ask for a special view or tools window where the formatting at a particular cursor position can be made visible by showing some "tokens" representing the applied formats.


Lotus WordPro filter

Issue 11215

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.


MathML Export

Exporting to HTML should turn Formulae into MathML (not GIFs). Issue 24256

Math already supports MathML export. The HTML export filter needs to be extended to use it instead of treating Math as an OLE object that is exported as a pixel graphic.


Support more colors in formulas

Issue 5156

Math only has some "hard coded" color values. It would be nice to have a full color palette as other applications in OOo. This requires to make the formula parser available of these colors.

Issue Tracker queries

Here are some issue lists of things we would like to get implemented:

Some other ideas

More text import and export filters

Perhaps you have experience with other file formats? Here's something for you!

Improve RTF filters

Currently the RTF filters of Writer are a separate implementation. The goal is to re-use the better binary Word filters with an upstream RTF tokenizer or a downstream RTF generator.

Shrinking text below a certain size

A component to shrink a document size by a defined page count, so the user can produce documents without a final halffull page. The component may then use different steps (for example: shrink all font sizes, or shrink the paragraph distance, or shrink ...) to come to a sensible result.

Improving Writer's compare function

Many powerful tools exist that can compare two versions of a text and report differences between them in a very fine grained manor. Providing a comparable tool that also takes text attributes and the more advanced strucure of an ODF document into account, would come in very handy. Development could be done in the OOo source code (C++), as an extension (C++, Java, Python) or even as a standalone application working on ODF directly (any programming language, but C++, Java, Python preferred as it would allow to convert the application into an extension).

"Beautifier" for Writer

Such a tool can modify existing documents in a way that the result looks the same but is optimized for whatever criteria the developer wants to fulfill: replace hard formatting (autostyles) by styles, detect multiple white spaces, detect superfluous hard formatting, optimize fonts, embed and resize pictures etc.

Integration of Mac Grammar Checker

Since OOo 3.0.1 the Grammar Checking API of OOo is final. Some extensions based on this API already exist and it would be great to have an extension integrating the Mac Grammer Checker.

Eclipse Integration ToDo

New Calc Add-in Wizard

  • Knownledge: Eclipse plugins, Eclipse API
  • Summary:
  • Duration:
  • Notes:
  • Mentor: Cédric Bosdonnat

IDL files modification assistance

  • Knownledge: Eclipse plugins, Grammar & compilers, JavaCC, Design Patterns, UNO IDL
  • Summary: Currently, the Eclipse integration for OpenOffice.org is providing tools to the extensions and UNO component developer to easily create a UNO component from scratch. The developer defines the specifications of its component and then write its implementation. However, in real developer life, we often have to change something in the specifications. The goal of this project is to create a graphical way of editing IDL files, parse existing IDL files to provide their tree structure to the editor and write back the changes to the IDL file and its implementation.
  • Duration: 1 - 2 month, full time
  • Notes: This task can be split into several independent parts:
    1. parsing the IDL file,
    2. IDL file editor with 2 tabs: form or graph tab and source tab (already done)
    3. Changing the implementations: find the implementations, then change them.
  • Mentor: Cédric Bosdonnat

C++ support

  • Knownledge: Eclipse plugins, Eclipse API, Eclipse CDT plugin API
  • Summary: create a new Eclipse plugin connected to the org.openoffice.ide.eclipse.core plugin to allow the development of C++ extensions / components. There is already a Java plugin and documentation to understand how it works and what should be done.
  • Duration: 1 month
  • Notes: This project could be split into several parts for a group of 2-3 students working together and then the duration would be shorter.
  • Mentor: Cédric Bosdonnat

Add other types creation wizards

  • Knownledge: Eclipse plugins, Eclipse API, UNO IDL
  • Summary:
  • Duration:
  • Notes:
  • Mentor: Cédric Bosdonnat

Add cheat sheets to help the new developer

  • Knownledge: Eclipse plugins, Eclipse API
  • Summary:
  • Duration:
  • Notes:
  • Mentor: Cédric Bosdonnat

XCS / XCU file editors

  • Knownledge: Eclipse plugins, Eclipse API, XCS / XCU schemas
  • Summary:
  • Duration:
  • Notes:
  • Mentor: Cédric Bosdonnat

addons.xcu file editor

  • Knownledge: Eclipse plugins, Eclipse API
  • Summary:
  • Duration:
  • Notes:
  • Mentor: Cédric Bosdonnat

Localization

Base To-Do

Below is a list of Base-related 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 the actual project descriptions are not yet moved to this place here, they still reside one of the project's static pages. Your'e encourage to visit this page, as it contains much more information currently.

(So if you want, one of the To-Dos of our project is to move the To-Dos from http://dba.openoffice.org/development/projects.html to this Wiki page.)

Joins in dBase queries

The content of this item moved to a dedicated page: Base_To-Do/Joins_in_dBase_queries

SDBC driver for LDAP directories

The content of this item moved to a dedicated page: Base_To-Do/SDBC_driver_for_LDAP_directories

New/Enhanced Form Controls

The content of this item moved to a dedicated page: Base_To-Do/New+Enhanced_Form_Controls

Dialogs with Form Functionality

The content of this item moved to a dedicated page: Base_To-Do/Dialogs_with_Form_Functionality

Database driver UI modularization

described in more detail at the here.

HSQLDB: single-file backend

described in more detail at the here.

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

  • required skills Java, C++
  • useful skills: OOo's database access API, OOo's component technology (UNO)
  • Contact: mailto:dev@dba.openoffice.org
  • effort: 2 months
  • difficulty: high


Native, cross-platform access to MS Access databases

described in more detail at the here.

SDBC driver for vCards

described in more detail at the here.

New Filter Dialog

described in more detail at the here.

Retrieved from "http://wiki.services.openoffice.org/wiki/To-Dos"
Personal tools
Create a book