EN/to-dos

From Wiki
Revision as of 06:35, 30 March 2012 by Sancho (talk | contribs) (moved To-Dos to EN/to-dos)
Jump to navigationJump to 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 resources 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

Application Help Development To Do

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

  • has been removed now (along with the version mapping stuff in SfxItemPool) in CWS tl77

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.

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.

Needed skills: C++, Windows API
Difficulty: Medium
Contact: cd at openoffice dot org

  • Toolbar and popup menu controllers which are more powerful and easier to use than the current ones.

Needed skills: C++, GUI experience
Difficulty: Medium
Contact: cd at openoffice dot org

  • Improve code handling configuration settings
    • Cleanup the code of 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.

Needed skills: C++, configuration background
Difficulty: Medium/Hard
Contact: cd at openoffice dot org

  • User interface to associate templates to existing documents

Needed skills: C++, GUI experience
Difficulty: Medium
Contact: cd at openoffice dot org

Needed skills: C++, GUI experience
Difficulty: Medium/Hard
Contact: cd at openoffice dot org

  • Implement start center for Mac without using a main window

Needed skills: C++, GUI and Mac OS X experience
Difficulty: Medium
Contact: cd at openoffice dot org

  • Implement a fancy user interface for the user interface migration feature. OpenOffice.org can currently migrate user changes between versions. It would be nice for experienced users to select changes with a fancy user interface.

Needed skills: C++, GUI experience, User interface design
Difficulty: Medium
Contact: cd at openoffice dot org

  • Tabbed-Window interface: Enhanced the current implementation to support a tabbed window user interface. There is a simple extension available which can be used as a starting point.

Needed skills: C++, GUI experience, experience with MVC concepts
Difficulty: Medium/Hard
Contact: cd at openoffice dot org

Porting/To-Dos

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

Areas to port 

* Documentation/DevGuide/AdvUNO/Advanced_UNO
* Documentation/DevGuide/GUI/Graphical_User_Interfaces


Contact 

   * dev@porting.openoffice.org
   * Martin Hollmichel (mh 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

NLC:whatshot

Qa/To-Dos

Release QA Tracking Tool

Tracking a release with dozens of languages and several platforms can be tedious. This is especially the case if the only used tool is a manually maintained table with colors indicating the status.

A web based tool should help us to keep track of the location and status of the builds as well as the responsible contact. The workflow in place should be supported. The tool should provide an overview, the means to maintain a release including easy status manipulations.

Contact 

   * dev@qa.openoffice.org
   * Andre Schnabel (Andre.Schnabel at gmx.net)


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

Stats/To-Dos

SVG Import ToDo

SVG Import ToDo

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: Development Opportunities

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 are great opportunities for interested developers as the list mostly contains features that have been demanded for by the OpenOffice.org community. So providing them surely would be appreciated by the users. Of course interested developers are also invited to present their own ideas they would like to implement for the Writer project. They can count 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 Pages

Features with a high number of votes

Statusbar control for line and column number in Writer

Issue 18004

A statusbar control that shows the line and column number of the current cursor position. While this sounds easy for simple documents, it can become quite "interesting" for documents with tables, text frames etc.

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.


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!

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.

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


Integration of spell checking into the proof reading code

OOo Writer calls Grammar Checkers from a new, multi threaded implementation that iterates over paragraphs and sentences. OTOH spell checkers are called from the main thread and just iterates over the single words of the text. For several reasons it would be desirable to integrate both iterations to a common one, where all spell checkers still can be called with single words as nowadays:

  • spell checkers that can be called with larger blocks of text can be served better by providing a specialized component (Mac spell checker!)
  • some grammar checkers might also do spell checking, so calling them from different places in the code for both tasks is inefficient
  • spell checking can happen in a parallel thread of execution

Integration of Grammar Checking into Calc, Draw and Impress

Grammar Checkers can be used from Writer only, the other applications lack the necessary text iteration loops. Also an implementation of the text iteration API that is used to communicate with Grammar Checkers is not provided by the text engine that these applications use ("EditEngine"). For efficiency reasons this task should not be started before the task "integration of spell checking into the proof reading code" has been finished.

Integration of language guessing and selection into Calc, Draw and Impress

Issue 66798

The language status bar control together with its ability to propose a language for text and offer an easy selection of the correct language currently only works for flow text in Writer.

Visualization of RDF meta data

Issue 109598

OOo Writer supports RDF meta data according to the ODF 1.2 specification for a number of objects. We need a user interface component that shows them like e.g. our current comment (notes) sidebar. This would require to refactor the components of this sidebar so that they use an API that can support comments as well as meta data and change tracking comments.

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

See also:

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.

Enable Picture Insertion

For example uses see table MAPS in File:ToursDB schema.sql and File:DerbyToursDB.odb. HCPotter

Discuss Remote Operation Necessity

When File:DerbyToursDB.odb is downloaded it can be used only when saved for local access. I have not tried the external application editing option. HCPotter 09:00, 14 June 2010 (UTC)
Retrieved from "https://wiki.harlamenkov.ru/index.php?title=EN/to-dos&oldid=20385"