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
