OpenOffice.

org development: Next steps, next level

Mathias Bauer Mathias.Bauer@sun.com

3rd OpenOffice.org Conference, Koper 2005

Agenda

Notes about the speaker Past Goals Provided features and tools Present Balance of experience Analysis Future Plans for future releases OpenOffice.org Google Summer Of Code projects

Notes about the speaker

Working on StarOffice/OpenOffice.org since 1995 Application Framework (formerly sfx2 module) Object embedding (sot, so3) New UNO based Application Framework Now working as a Software Engineering Manager Application Framework Programmability (API/SDK/UNO) OpenOffice.org Application Framework Project Lead Member of OOo Engineering Steering Committee

OpenOffice.org Programmability

Past

Goals of the API and UDK projects

Provide an API to access the whole functionality of OpenOffice.org that allows developers to use it in their own applications. Enable users to extend OpenOffice.org with own components that bring new functionality to the program. Make internal implementations of existing functionality in OpenOffice.org replaceable by other components that work better or differently. Make componentization of OpenOffice.org possible

Use cases we have in mind

Creation of applications that connect to an instance of OpenOffice.org and use its functionality Writing macros or scripts with OpenOffice.org Basic or Scripting Framework Using predefined service provider APIs to bring new components into OpenOffice.org Document import or export filters Content providers Calc Add-Ins Data Connectors Add-Ons

What UNO provides to developers

Direct support for programming languages C++ Java Python OpenOffice.org Basic Support for Scripting Languages through Scripting Framework; currently JavaScript, BeanShell OLE Automation Bridge to support VB, Delphi etc. CLI UNO Bridge to support .NET (C#, VB.NET etc.)

What the SDK provides

Complete reference documentation of the whole API OpenOffice.org Developers Guide Programming Examples for all supported languages Development environment for C++ and Java UNO Runtime Environment libraries and documentation Creation of UNO packages for easy deployment

OpenOffice.org Programmability

Present

Experience after 4 years: plus ...

Many developers showed up on our lists, starting a lot of interesting discussions Several Add-Ons (both open and closed source) have been created Customer projects have been enabled by additional components Books have been written about OpenOffice.org Basic macro development OpenOffice.org itself benefits from UNO APIs by becoming more componentized

... and minus

Developers didn't use the provided documentation as much as we expected Many of those who used it still had a lot of questions People still fight with the SDK Component development, especially development of Add-Ons, didn't happen to the extent we hoped Macro development is done mostly by experts

Problems of the API

We have many very flexible and powerful APIs, but at the expense of missing type safety API uses a lot of generic interfaces API uses Any parameters and return values quite often This causes a lot of typechecks and interface negotiations (queryInterface) at runtime It makes the code harder to write and read People (especially Basic developers) very often think in objects, not in interfaces

Problems of the development tools

The SDK environment for the creation of UNO components is not very convenient many developers don't like shells and makefiles They miss the conveniences of modern IDEs Creation of components (especially Add-Ons) requires a lot of unproductive routine work provide code for component registration and instantiation hacking of XML configuration files

Problems of the documentation

The documentation is huge and detailed but it's hard to get in It lacks introductory parts (primers) to language bindings and most important topics It's hard to access or explore the functionality of an object using the UNOIDL reference Basic is not well supported by it at all Especially Basic developers ask for documentation in their native language

Conclusion

So alltogether this creates the famous...

Steep learning curve

OpenOffice.org Programmability

Future

First improvements: Shiny UNO

Multiple inheritance for UNO interfaces New Style Services with constructors Type safe methods to get and set attributes

Multiple inheritance for interfaces

Allows to create services that implement only one interface (important for new style services) Supports polymorphism of interfaces through base class interfaces instead of polymorphism of services through queryInterface calls Cleans up the service concept by replacing the old style abstract services

New style services

Implement one interface, no optional parts Constructors
> return the real interface, not css.uno.XInterface as the

createInstance method of the Service Manager > can have defined parameters with defined types, not a sequence < any > as the createInstanceWithArguments method of the Service Manager

Cleans up the service concept

> all new style services are instantiable

Interface attributes
Typesafe access by typed get/setMethod instead of any-based get/setPropertyValue methods Clean up concepts of interface and implementation by making clear that attributes belong to the interface and not to the service definition

Interface negotiations

Old style service

XDesktop xDesktop = null; XFramesSupplier xFrames = null; // Create Desktop object Object desktop = xServiceManager.createInstance( "com.sun.star.frame.Desktop"); xDesktop = (XDesktop) UnoRuntime.queryInterface(XDesktop.class, desktop); xFrames = (XFramesSupplier) UnoRuntime.queryInterface( XFramesSupplier.class,desktop);

New style service

XNewDesktop xDesktop = null; // Create Desktop object xDesktop = NewDesktop.create();

API plans for next releases

Condition: use new UNO features without losing compatibility to old versions of OpenOffice.org Starting with the most important services:
> take all currently mandatory interfaces of the object and

create a new multiple-inheritance interface from them > implement the new interface as new style service, but support old ones in queryInterface calls of this object > add all of the mandatory properties of the corresponding old style service as attributes to the interface of the new style service

Don't create any additional old style services

SDK plans for next releases

Provide a code generator
> Command line tool in SDK > Feed with a service or a combination of interfaces > Generate C++ or Java code that can be compiled,

packed and deployed without any user action > User edits this skeleton, only concentrating on his problem domain

Integrate the code generator into popular IDEs as a component wizard For Java: switch to ANT For C++: ???

IDE support in OpenOffice.org SDK

NetBeans (Java, C++)
> Started as a Google Summer Of Code project as well as

a project inside the SDK team

Eclipse (Java, C++)

> Started as a Google Summer Of Code project

Microsoft Developer Studio Other IDEs: ??? Open for contributions, help, suggestions...

Topics for an IDE integration

Create and build UNOIDL files
> wizard for routine work > syntax highlighting > create type information files

Java/C++/CLI development
> > > >

component wizard using code generator code completion in editor (needs more rich interfaces) build/deploy/debug in IDE integration of IDL reference into IDE

Scripting Framework
> deploy Java macros into documents and packages

More Add-On support

Special code generator
> retrieve necessary information from user > easy creation of menus/toolbars without XML hacking > creation of all necessary configuration files

New features in OpenOffice.org

> > > > >

Advanced toolbar controls (strings, lists, numerical items) Typed toolbar entries (void, integer, string, list etc.) Statusbar integration for Add-Ons Titles for toolbars Template based contexts

Component installation and updates

Make installation easier: textual registration Precondition for component updates: versioning
> > > >

components services Office versions dependencies

Precondition for component downloads: signing Cooperation: licencing of components Finally: download and update components

Documentation plans
More examples in all languages, showing best practice Advertise code snippet database Work with community to get more primer style documentation

Plans for OpenOffice.org Basic

Create UNO packages from Basic IDE Syntactical usability improvements
> parameters using arrays of PropertyValue

Exception handling Support constructors in Basic Would people accept static typing to get code completion? Extend object browsing capability
> show methods, interfaces > link to UNOIDL reference

Google Summer Of Code

10 Projects in OpenOffice.org 7 finished succesfully
> > > > >

1 API project (Grammer Checker API) 1 external tooling project (ODT-export for JasperReports) 1 Calc non-coding project (Validation of results) 2 Programmability projects 2 Coding projects, both delivered as UNO components
> prepare OOo text documents for Word export > tabbed windowing interface for OOo

GSOC: Tabbed windows interface

Develop tabbed window interface as a separately installable UNO component Component should replace the internal framework component that is used for the creation of new task windows Use an existing tab control with an event based UNO API First prototype > only one window with tabs > no new GUI functions Future plans: needs specification

Data about the project: Andrzej Wytyczak-Partyka Experienced C++ developer No knowledge in OpenOffice.org development Total time of 9 weeks for familiarizing with UNO based development, knowing and understanding the relevant APIs, development of component. Mentoring based on dev-list of Framework project done by Andreas Schlns (API project co-lead)

GSOC: NetBeans as UNOIDL editor

Develop plugin for NetBeans > syntax highlighting for UNOIDL > compile UNOIDL and create type information for Java development Future plans: integrate with further NetBeans plugins for UNO based Java development

Data about the project: Fintan Fairmichael No knowledge in OpenOffice.org development No prior knowledge about NetBeans Total time of 9 weeks for familiarizing with UNOIDL and tooling familarizing with NetBeans and NetBeans plugins development of plugin Mentoring done by Jrgen Schmidt (API project lead)

GSOC: Eclipse as UNOIDL editor

Develop plugin for Eclipse > syntax highlighting for UNOIDL > compile UNOIDL and create type information for Java development Future plans: extend functionality to support > code generator wizards > Java application and UNO component development Looking for developers working on similar functionality for C++ development

Data about the project: Cedric Bosdonnat No knowledge in OpenOffice.org development Good knowledge about Eclipse Total time of 9 weeks for familiarizing with UNOIDL and tooling development of plugin Mentoring done by Jrgen Schmidt (API project lead)

What you can do

Support the Code Snippet Database Help creating/porting SDK examples Work with us on the IDE integration Write development primers about your favorite topics Translate documentation Discuss missing or unsufficient APIs with us Work with us on native packaging

Community resources
http://api.openoffice.org http://udk.openoffice.org dev@api.openoffice.org dev@udk.openoffice.org http://codesnippets.services.openoffice.org

Waiting for your comments and suggestions

Mathias Bauer Mathias.Bauer@sun.com