Thursday, 08 May 2008
Thursday, 08 May 2008
tags: api architecture code development netbeans odf opendocument software specification sun xml
Friday, 25 Apr 2008
ODFDOM is the name of the upcoming free OpenDocument framework sponsored by Sun Microsystems Inc.
It will be the next evolutionary step after AODL and Odf4j. Designed together with their architects with the intent to provide an easy lightwork programming API for the ODF developer community. ODFDOM is meant to be portable to any object-oriented language.
The first pre-version of the Java 5 reference implementation of ODFDOM is planned to become available under LGPL3 in May 2008.
Please find further detailed information in the OOo Wiki.
tags: api architecture code development netbeans odf opendocument software specification sun xml
Monday, 18 Feb 2008
The OpenOffice.org Developer's Guide is now available online in the OpenOffice.org Wiki. The main purpose of moving the guide into the wiki is for maintenance reasons and the hope to get more contributions. We also hope to get a localized version of the guide to reach more users/developers all over the world.
But before anybody will start with localization i would suggest to wait for the official go becaue the guide requires some guidelines to keep the guide well formed in general and especially for later post processing (e.g. export of the whole wiki book/guide to PDF). The guidelines will also document some extensions like the IDL tags that are useful to link directly in the IDL reference and that are used to generate cross references from the IDL reference back into the DevGuide. But anyway you will get more infos soon and i am looking forward to a faster growing, an improved and always up to date guide.
Overview of the IDL tags
tags: api developer's guide
Monday, 11 Feb 2008
We still have one little issue that is no real error but it is definitely not nice. But the plugin works and is completely functional and because of many requests we decided to provide an intermediate version 1.1.1 on api.openoffice.org.
The problem is that the NetBeans editor complains about unknown types. These types are generated from IDL types and we generate Java class files directly because of backward compatibility reasons. The cool NetBeans editor feature (indeed nice) requires Java code files for all generated and used types in a project (background compilation etc.). Anyway you can build your projects and everything works. If you prefer to get rid of this annoying editor message you can add a further library dependency to your project.
<project_node> -> context menu -> Libraries -> Add Jar/Folder -> <project_dir>/dist/IDL_types.jar
We will try to fix this problem soon but we can't say when. So feel free to try the new version with NetBeans 6 and please report any kind of problems.
tags: api extensions netbeans openoffice.org plugin sdk
Thursday, 20 Dec 2007
To all NetBeans users and users of our OpenOffice.org API plugin,
currently our OpenOffice.org API plugin is not available via the normal NetBeans 6 Update Center. The reason is quite simple, we have to fix some minor problems first. We are not really happy with this situation and we will try to fix this as soon as possible. The problem is that we have limited time at the moment because of some other projects but anyway stay tuned we will support NetBeans 6 soon.
The key point for me behind all the questions when will the plugin be available for NB 6, will you support NB 6 etc. is that it is really used. This little fact is really motivating and it helps us to convince our managers that we can do more. You know if the demand is high we can probably spend more time on it ...
Anyway there are a lot of things that we can improve and we have a lot of other ideas how we can improve the plugin. Important is also that you as our users give us feedback. Share your ideas with us and we will see if and how we can achieve your ideas in the future development of the plugin. If you have experiences with NetBeans plugin development and if you are interested to join this project, please send me an email.
I wish you our plugin users, all OpenOffice.org users and developers and of course all GullFOSS readers a merry Christmas and a happy new year.
Juergen 
PS: the animated gifs are from http://www.fg-a.com/christmas.htm
Friday, 16 Nov 2007
Currently, several solver components for Calc are available (with different capabilities and different licenses), and OOo 3.0 is scheduled to contain another one in the default installation. Some areas, like non-linear models, are still open, so more solver implementations may appear in the future.
Instead of having a variety of “Solver xyz” entries in the “Tools” menu, each with their own dialog, it seems better to select between the implementations in a single dialog. So that's what we are doing: There's going to be a UNO service “com.sun.star.sheet.Solver” for the core implementation, without UI, and a dialog within the “sc” module to specify model parameters, and select between different service implementations. Future components will be able to implement just that service, and be called from the common dialog. The dialog design isn't final yet, but it will look similar to this (the images in the specification will be updated if the design is changed):
The “Options” button will open an options dialog where you can select an implementation and the options needed for that implementation.
The Solver service will be something like this, plus an XPropertySet for the options (note: even more preliminary than the dialog design):
enum SolverConstraintOperator
{
LESS_EQUAL,
GREATER_EQUAL,
EQUAL,
INTEGER,
BINARY
};
struct SolverConstraint
{
com::sun::star::table::CellAddress Left;
SolverConstraintOperator Operator;
any Right;
};
interface XSolver: com::sun::star::uno::XInterface
{
[attribute] XSpreadsheetDocument Document;
[attribute] com::sun::star::table::CellAddress Objective;
[attribute] sequence< com::sun::star::table::CellAddress > Variables;
[attribute] sequence< SolverConstraint > Constraints;
[attribute] boolean Maximize;
void solve();
[attribute, readonly] boolean Success;
[attribute, readonly] double ResultValue;
[attribute, readonly] sequence< double > Solution;
};
service Solver: XSolver;
|
As an added benefit, since the service implementation is available from outside the solver dialog, you will be able to easily use solver functionality from macros or other components.
Implementation will be in the child workspace “calcsolver”, and there's also a wiki page. Feedback is welcome on the sc-dev mailing list.
tags: api calc openoffice.org spreadsheet
Tuesday, 06 Nov 2007
i am sure that most of you have already seen or even better have visited our Extension repository. I always have fun when i take a look on the growing number of extensions. You can already find some useful stuff there and that is great. The whole thing is part of a vision that i have since years and i am looking forward to more really cool extensions.
But most important from my point of view is the community building aspect behind extensions. I mean the extensions where no company is behind, i mean the small things where individuals start simply work on something new. Or where they start to provide an existing feature in a more intuitive way. See for example the Pagination extension Mathias mentioned yesterday. People start working in there own small universe (mini projects). They learn the API and other basic concepts that are necessary to program with and for OpenOffice.org. They can partly use modern IDE's to speed up not only there initial work no their daily work. Features like code completion are common today and make developer's life much easier. No complex build system is necessary to get started. A further big advantage is the fast feeling of success. And we all know that it is often the motivation to do more. Developers that start today with an extension might be the main developers from tomorrow.
And with more complex extensions the demand for better or new API's to do more things via API is growing as well. Part of that is implicitly often a better modularization in the core. Well that is not obviously but i think it is true. Internal hacks are not possible anymore (at least theoretically), we need clear and well documented interfaces making new features available for extension developers.
The extensions infra structure is evolving and we've got useful new things with the last three releases and we will do so with the next. Let me highlight the extendable help feature that is making good progress and that will hopefully coming soon. Related to the help feature I am looking forward to an adapted filter for our help format to make it easy to write help files with the office directly. Localization support for the repository is ongoing and it will help us to reach more users all over the world. A localization community as we already have for the office would be nice for extensions as well and we will see how we can align all these things and how we can benefit form the existing community here.
I hope also that we can focus on further improvements and new features for our OpenOffice.org API plugin for Netbeans (currently it's somewhat stalled) because as i have mentioned above tooling is important to attract new developers. So you can help us to give feedback and let us know what you would like to see or where we can do things better. I know a lot of small things that we have not addressed yet or that are simply bugs but i would really like to here your feedback.
And for all of you who get started with extension. Don't give up when things are not working or are not possible at all. Simply let us know about the missing feature or the not working API's and we will fix them (most often quite fast). I also made this experience by doing something that was not the standard and we detect several problems in the toolkit and our dialog descriptions. But hey we took the source, fixed it on our cws and moved forward. My managers know that i am really no fan of our toolkit. But as long as we don't have a concrete plan and no concrete intend to replace it with something new or something better we have to live with it. But dreaming is allowed and i would like to have at least something like Matisse the GUI editor from NetBeans or a descriptive approach like XUL.
At the end i would like to point you again on the Smart Tag feature that was introduced for OpenOffice.org 2.3. A nice tutorial can you find in the wiki. Jacob Lechner made this feature possible and i think he was driven by some demand for it in his company. Anyway think about it for a while. Somebody needs a feature that doesn't exist, he simply started the work, got all the support he needs from Frank Meies and in the end he got the feature and the OpenOffice.org project got a further nice service provider interface (SPI) that allows fast integration of some nice features in the writer. You can help and can implement some nice Smart Tags as extension. I have already tried it for a workshop demo and was able to implement a simple one (with our NetBeans plugin) in 30 minutes or so. So just do it!
tags: api community extensions openoffice.org
Wednesday, 01 Aug 2007
Good news for extension developers. In the past it was not easy to get access to the root directory of an installed extension to get access to package local resources. With the upcoming OpenOffice.org 2.3 a new PackageInformationProvider singleton becomes available that solve this gap and provides easy access to the package root directory by simply using the unique package identifier. With this new XPackageInformationProvider interface we provide an often requested API and make the life for extension developers much easier. In the past it was only possible to define an own configuration schema and deploy the schema with an appropriate configuration file with the extension. The config data contained macros that could be resolved with the MacroExpander. Well it was possible this way to get access to local files in the package but it was or still is not really comfortable. The new API is quite easy to use as the following code snippet will show you:
...
// get the PackageInformationProvider singleton by simply using the get fucntion
// of the generated Java class (ease of use UNO feature)
// m_xContext is the gloabl ComponentContext
XPackageInformationProvider xPkgInfo = PackageInformationProvider.get(m_xContext);
// getPackageLocation called with the extension identifier returns an URL to
// the root directory of the extensions
String rootUrl = xPkgInfo.getPackageLocation("ooo.api.demo.ExtensionsRootTest");
// based on this URL you have access to all local files in your extension package
StringBuffer imageUrl = new Stringbuffer(rootUrl);
imageUrl.append(File.seperator + "images" + File.seperator + "me.png");
...
I used our OpenOffice.org API Plugin to create a simple demo add-on showing the usage of this new API. If you are interested in the demo NetBeans project, it is quite easy to try it out. You need a developer build of the upcoming OpenOffice.org 2.3. You need NetBeans (recommended 5.5.1), install the OpenOffice.org API Plugin over the normal Update Center and download the example from here. The demo is really simple and doesn't provide any useful functionality. It simply inserts a picture at the current cursor position in a text document. Try it out on your own risk ;-)
tags: api extensions
Monday, 23 Jul 2007
Last week a colleague has pointed me to a really cool Firefox addon Document Map which i would like to share with you. The addon analyzes web sites and creates dynamically a content table based on the headings. The content table can be easily displayed (pressing alt-o) in the same way as bookmarks on the left side in your browser. It helps a lot to navigate through huge sites like the Developer's Guide. Try it out and browse for example the Text Documents chapter of the Developer's Guide and press alt-o. I am sure you will like it.
Independent of this nice addon the work is still ongoing to publish the Developer's Guide in the Wiki. The updated Developer's Guide coming with the OpenOffice.org 2.3 SDK will be probably the last update in the old format. Stay tuned!
Thanks to Daniel Boelzle for this useful pointer.
tags: api openoffice.org sdk
Tuesday, 03 Jul 2007
The first flash demo showing how to use our OpenOffice.org API NetBeans plugin is available online. Roman Strobl (his blog about it) a colleague from the NetBeans team in Prague has created this cool flash demo showing how you can use our plugin to create quite easy a new built-in function for the Spreadsheet application. I met him last week in Zurich during the Jazoon conference and we talked about it and wow he has really fast created the demo. Many thanks Roman, you did a great job.
I already have it on my todo list to create this kind of stuff but have never found the time until now and of course i haven't any experience so far. But i think it is a really useful mechanism to do some promotion for our plugin and of course other OpenOffice.org related features as well.
How cool would it be to have a huge collection of nice flash demos showing/explaining
available on our OpenOffice.org website and maybe some of them on YouTube.
Roman is the expert in the NetBeans team and one of his last blog entries described how he did it. I would like to encourage you to read his blog entry and try it out. It is a good opportunity to help and contribute to the OpenOffice.org project, i would say low cost but really effective marketing.
tags: api extensions netbeans openoffice.org