To-Dos

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

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 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 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. 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 Issue 71289 Fixed Closed)
• Guides for new Chart Module (a big thank you to Regina for her updated files, see issue Issue 60360 Fixed Closed)
• 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 Issue 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 AOO, see issue 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 Issue 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

• Architecture/To-Dos
• Platform UI Differences
• UI Layout

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.

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

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

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)

• port Drawing Layer to XCanvas (see DrawingPrimitives for one of the preconditions)

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

• Split View support
• Vista Shell Extensions

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

• Improvements for AWT toolkit as discussed in our gap analysis

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

Marketing--ToDo

OOo Marketing Project Please view the guidelines before contributing.
Categories: Art Conference (OOoCon) Draft ideas and materials Marketing Pages: Major OOo Deployments New releases Info To Do List Quick and Easy Activities Marketing Volunteers List Market Share Analysis Marketing to Developers Press Coverage The Case for Switching Why.OpenOffice.org Marketing Activities Record MarketingCampaign_Q3-2007 OOo Conferences Checklist for Decision Makers User Perception Research Strategic Marketing Plan Pages: Strategic Marketing Plan SMP To Do Projects on this Wiki: (edit list) Art Project * Application Framework Documentation Education Project * Marketing Project * Native Language Confederation * Product Releases Security Team Universal Network Objects User Experience Project Website Project Writer Project
Marketing.OpenOffice View or edit this template.

< Marketing

Welcome

This page is intended for maintaining the Marketing ToDo List
Here you will find copied all the items from the [Marketing ToDo] from the OOo website. Use the links in the contents table to jump to the category that interests you. If you want to contribute with something please follow the general guidelines located [here]. To add/change an item in a specific To-Do section use the edit link near each section's title. Also do not forget to discuss it [here] and on the dev@marketing.openoffice.org mailing list.

Marketing ToDo List

INTRODUCTION/PROJECT PLANNING

What is OpenOffice.org Marketing Project?

ITEM	DEADLINE	STATUS	ISSUE TRACKER
Develop and maintain OpenOffice.org marketing strategy.	2004-8	...	Issue 26489

Organisation

ITEM	DEADLINE	STATUS	ISSUE TRACKER
[Native-Language Confederation communication list]	ongoing	List used for communication between Marketing Project and Native-Language Projects.	...
[Consultants Directory]	ongoing	Forms part of the BizDev Project.	...
Maintain Contacts (MarCon) list	...	Completed. MarCon members subscribe to [Marcon] mailing list.	...
Put up "how to get involved" instructions	ongoing	...	...

Objectives

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Products

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Development Programme/Policies

ITEM	DEADLINE	STATUS	ISSUE TRACKER
Archives in PDF - Useful for Analysis - Search - Dev@Marketing.OpenOffice.org	...	...	Issue 18872

Marketing Policy

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Summary of Marketing Policy

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

---

OPENOFFICE.ORG THE PRODUCT

General Product Description

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Technical Description

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Product Development Programme

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Product Support, Modifications and Upgrades

ITEM	DEADLINE	STATUS	ISSUE TRACKER
Icons not very distinct	...	...	Issue 11805
Module's name	...	...	Issue 12009
No slide/picture show during install	...	...	Issue 15173
hubris of corel leaves only one migration choice ...	...	...	Issue 23738

Strengths and Weaknesses

ITEM	DEADLINE	STATUS	ISSUE TRACKER
Office suite comparison	...	Draft template spreadsheet available for collation of further data.	Issue 27348
Security audit for OOo; Important for product comparisons	...	...	...
Text Left/Right alignment in a single Paragraph	...	...	Issue 14516

---

OPENOFFICE.ORG THE COMMUNITY

General Community Description

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Detailed Description

ITEM	DEADLINE	STATUS	ISSUE TRACKER
OSS Recommended Readings to add to the bibliography	...	...	Issue 4286

Community Development Programme

ITEM	DEADLINE	STATUS	ISSUE TRACKER
Native-Language Projects' Marketing Resources	ongoing	Follow and collate Native-Language Projects' resources.	Issue 27665
Select publicity team for OOo 1.1	...	...	...
Create press@ forwarding addresses for all languages.	...	...	...

Community Support, Modifications and Upgrades

ITEM	DEADLINE	STATUS	ISSUE TRACKER
Picture from LinuxWorld San Francisco	...	...	Issue 17954

Strengths and Weaknesses

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

---

THE MARKET

Introduction

ITEM	DEADLINE	STATUS	ISSUE TRACKER
OpenOffice.org/StarOffice Market Share Document	...	...	Issue 21674

Potential Markets/Customers

ITEM	DEADLINE	STATUS	ISSUE TRACKER
Online User Surveys	OOo 2.0	Includes multi-language surveys, voting, and polls.	Issue 28544
OOo Case Study Worksheet (in-depth version)	ongoing	In consultation with the [BizDev Project].	Issue 18858
Design Consultants Survey	...	...	...

Target Markets

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Competitor Products

ITEM	DEADLINE	STATUS	ISSUE TRACKER
Competitior Guides	ongoing	Myths and realities prepared from true false statements.	Issue 27642

Complementary Products

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Complementary Communities

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

---

MARKETING STRATEGY

Introduction

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Market Positioning

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Pricing/Value Policy

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Distribution

ITEM	DEADLINE	STATUS	ISSUE TRACKER
Need way to purchase latest issue	...	...	Issue 15286

Educational Institutions

ITEM	DEADLINE	STATUS	ISSUE TRACKER
Setting up education mailing list and webpages	...	...	Issue 19759
Getting OO.org to students	...	...	Issue 15757

Libraries

ITEM	DEADLINE	STATUS	ISSUE TRACKER
OpenOffice LendingCD in Libraries HOWTO	...	...	Issue 23357

Other Segments

ITEM	DEADLINE	STATUS	ISSUE TRACKER
Rural Development Project implementing OOs	...	...	Issue 22590

---

PROMOTION

Introduction

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Image and Identity

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Special Promotions

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Conferences and Exhibitions

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Seminars

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Demonstrations

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Newsletters

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Sponsorship

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Press Advertising

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Radio Advertising

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Classified Advertising

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Television

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Public Relations

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Press Information and Releases

ITEM	DEADLINE	STATUS	ISSUE TRACKER
For the release of OOo 2.0.2: Marketing-PR-OOo2.0.2 Information that can be given in a press release or to your press contacts.	The beginning of March 2006	Final	...
For the release of OOo 2.0.3 Marketing-PR-OOo2.0.3 Information that can be given in a press release or to your press contacts.	The end of May 2006	...	...

Editorial Coverage

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Direct Mail

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Seminars/Training

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Supplier Publications

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

OpenOffice.org Newsletter

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Information to Sun Microsystems

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Promotions With Distributors/Suppliers

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Website

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Directories

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Online Elements (e.g. reciprocal links)

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Marketing Material

ITEM	DEADLINE	STATUS	ISSUE TRACKER
What can be used to replace Outlook?: Marketing-Material-ReplaceOutlook OOo currently doesn't have a e-mail and/or calendar application. This information helps to find alternatives. ...	...	Draft	...

Buttons

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Business Stationery and Cards

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Posters

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Flyers

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

Brochures

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

CD Artwork

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

New Contacts

ITEM	DEADLINE	STATUS	ISSUE TRACKER
...	...	...	...

---

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/Tod's

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: NLC Pages: Index NLC Projects Wiki Pages What's hot in the NLC? Projects on NLC Wiki: (edit list) ar.openoffice.org (Arabic/عربي) Bangla/Bengali Burmese da.openoffice.org de.openoffice.org fa.openoffice.org (Persian) fr.openoffice.org hu.openoffice.org id.openoffice.org it.openoffice.org ja.openoffice.org ko.openoffice.org (한국어) mn.openoffice.org (Монгол) Nepali nl.openoffice.org no.openoffice.org om.openoffice.org pa.openoffice.org pl.openoffice.org (polski) pt.openoffice.org Romanian Russian Serbian Sinhala Spanish sv.openoffice.org Turkish Bulgarian Slovenian Thai (ไทย) Việt zh.openoffice.org
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 consistent documentation to the Native-Lang projects!

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

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

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

SVG Import ToDo

ToDo list for SVG Import Filter

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

• Move documentation from http://udk.openoffice.org into the Uno wiki, see Uno/Effort/Migrate Documentation for details.

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:

• Move C++ stuff from udk/cppu to udk/cppuhelper.
• Move udk/cppuhelper bootstrap stuff to Binary Uno and let it provide a 'C' interface. Implement current udk/cppuhelper API as wrappers.
• Move udk/cppuhelper/source/shlib.cxx into the library loader (udk/stoc/source/loader). Let the library loader provide a C/C++ API. Note, this is not as easy as it may sound, because the module udk/stoc already depends on the module udk/cppuhelper, which than would depend on module udk/stoc stoc again.
• Move udk/cppuhelper/source/component_context.cxx into into its own core component in udk/stoc.

Bugs

• Move the module udkapi/api from API project into the Uno project.
• Fix udk/cli_ure dependency against api/offapi.
• Fix udk/cpputools dependency against api/offuh.
• Move the module util/io from the util project into the Uno project.
• Move the module udk/jut/util into the Uno project.
• Query for Uno 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

• Introduce process lifecycle based on living threads.
• Have Uno package support for the URE.
• Move the UCB into the URE.
• Move the configr mgr. into the URE.
• Move the most useful helpers from comphelper into the URE.
• Uno alien type support e.g. for Java (e.g. a type description provider implemented in Java based on Java reflection).
• A Uno-SOAP Bridge. Some considerations
• Allow (remote) proxy detection, needed for remote detection and optimizations.
• Zones.
• Write man pages.
• Write a DBUS bridge.
• Various IDE integrations.
• Allow connection parameters in environment descriptions for remote environments, e.g.

  "remote[urp,socket=<port>,host=<name>]"

• Bridge the interface gap e.g. of Java and C++ Uno - AKA know as "smart mapping".
• Graphical and Command line tool for registry data modification.
• COM Bridge
• CORBA Bridge Concept Paper
• Logging support
• Exceptions with Stack Traces
• Issue 75053: Language binding support for service contstructors

Tests

• API Tests - Help implement API tests.

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

• Writer Layouts
• ODF Enhancements
• PDF Import

---

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:

• Writer RFEs of the community

• Issue with many votes

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.

Eclipse Integration ToDo

EclipseIntegration ToDo