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
Tuesday, 18 Mar 2008
Currently an extension can be installed on a system where it does not work. The extension then typically contains libraries which are not suitable for that platform. After installing it, the extension will most certainly not work. Unfortunately the Extension Manager does not warn the user about it.
An extension can, however, provide native libraries for many platforms. In that case the Extension Manager should install the suitable libraries and silently ignore all others.
The problem is, that an extension can declare for which platform a library is intended but it cannot declare what the target platforms of the whole extension are. People may inadvertently install extensions not suitable for their systems and will not be warned about it or even prevented from doing so.
A similar problem exists for extensions which support a locale different to that used by OOo. For example, an extension could show dialogs using a different language as the one of OOo. User might want to be informed about that when installing the extension.
If one develops an extension for different platforms, having one extension for each platform rather then one extension for all platforms, then these extensions must have different identifiers although they are logically the same. For example extension A and B provide exactly the same functionality but A works only on Windows and B works only on Linux x86. Their extension identifiers must be different.
By providing different identifiers we have somehow attached additional platform information to the identifier. One extension identifier represents exactly one or a set of target platforms. This is a requirement for the online update. Later versions of an extension have the same identifier and the Extension Manager assumes that an update supports also the same platforms as the currently installed version. That is, by using the extension identifier plus the version the Extension Manager can exactly identify the extension.
Although the identifier carries platform information, it cannot be
used by the Extension Manager to warn users in case they are going to
install an extension on the wrong system. The reason is, that it is
not defined how platform information are encoded into the identifier.
Extensions are currently installed, no matter what platforms or locales they support. Ideally one would only allow the installation of working extensions. What “working” means is certainly open to debate. As for the platform, it is safe to say, that only an extension can work which supports the platform of the system where it is deployed. But with locales the situation is not quite clear. A very obvious manifestation of an locale is the text used in dialogs. So let us use dialogs as an example. Assuming the extension does not support the locale of the office, then users may see a dialog in a language which they do not understand. This is actually the worst case and for most users this would be acceptable. We need to remember all the possible localizations of OOo. It is certain that extension would rarely support all locales. Therefore there will always be users who will not get localized extensions but they may be happy that there is an extension available at all.
In case an extension does not support the locale of the office, the user should be informed but the installation should be allowed.
What happens when the user switches the office's locale after installation of the extension? To prevent the user from surprises, the Extension Manager could also take all non-active locales of the office into account, when comparing the locales of the extension with those of the office.
Regarding the locales, we need to overcome another difficulty.
Locales are named by a string having a language, country and variant
parts, for example 'de-DE-hamburg'. There can even be multiple
variant parts. When there is no exact match, then one need to find a
“near match”. Assuming that the office uses a German locale
('de') and the extension supports only 'de-DE-hamburg' and 'en' then
one would probably not want to warn the users, because for most of
them 'de-DE-hamburg is just as well and any warning may be confusing.
A new version of an extension could bring support for additional platforms. This may be preferable over providing separate extensions for each platform. This way one could gradually evolve the extension to support more platforms over the next versions. Let's assume version 1.0 is Windows only and installed on a respective system. Let us further assume that later versions can be obtained by the online update feature of the Extension Manager. Then version 2.0 is published which additionally supports Linux x86. When running the update, version 2 will replace version 1 on the Window system.
In case users are not satisfied with version 2, then they could decide to downgrade to version 1. This cannot be done automatically but the user can simply add the previous version. Because version 1 has the same identifier as version 2, the Extension Manager will replace version 2. Now think of a Linux user, who had installed version 2 from the beginning and for some reason wants to replace it by version 1. Doing so will install a non-functioning extension – remember that version 1 is Windows-only.
In this case it would be desirable if the user is warned or even be prevented from installing the inappropriate extension.
There may, however, be the case where support for a platform will be dropped in a future version. Then users need to be notified and possibly be prevented from installing it. This would be a candidate for the “Show all” view in the update dialog for extensions. That is, the update would be displayed as 'available but not allowed'. In the case of a manual installation, a message box would be displayed.
We have a similar situation when adding / removing locales in future versions. Provided that both, the installed extension and the new version of the extension, do not support the office's locale the user probably does not need to be warned. However, when the installed extension supports the office's locale but the new version does not, then the user needs to be warned. This warning needs to be clearly expressed in the update dialog or in a message box in case of a manual update.
The warning needs also be displayed when installing a previous version.
However, we could consider the loss of a locale as acceptable as long as there is another partly matching locale. Then the warning need not be displayed. For example, there is an office with a locale 'en-GB' and a installed extension which supports 'en-NZ' (New Zealand). If this extension is going to be replaced by a version which only supports 'en-US, 'en' or 'en-GB-south', then a warning is probably unnecessary.
Another problem arises when a future version should unify different platforms. For example, there are two instances of version 1, one for Windows and one for Linux. Both have different extension identifiers. Now the developer decides to only have one extension as version 2, which supports both platforms.
By doing so, the developer would exclude one of the previous
versions from online updates. The new version of the extension must
have the same extension identifier as the earlier Windows or Linux
version. By using the identifier of the Windows extension, one would exclude the previous Linux version from the online update and vice versa.
To get around this situation one could invent an “alternative extension identifier” whose sole purpose is to offer a migration path. The new version would then use either the extension identifier of the previous Windows or Linux version and the identifier which it not uses would be the “ alternative extension identifier”. Therefore the new version of the extension would carry both identifiers. Now it would only be necessary to adapt the Extension Manager and the extension repository to allow updating all previous versions.
By using a combination of extension identifier and platform, one could provide different instances of an extension, which have different target platforms but still the same extension identifier. “Merging” the different instances in a later version would then be no problem, provided that the Extension Manager takes the different platforms into account.
The “alternative extension identifier” would therefore only be used to allow the migration of “legacy extensions”.
In a downgrade scenario we would need to prevent the installation of an extension which is inappropriate for the user's system. This is not possible for those “legacy extensions” because they do not contain yet information about their supported platforms.
Similar scenarios exist for using extensions with different locales. There could be two instances of the same logical extension which supported different locales. To ensure, that the proper version is used during the online update, one needs to provide different extension identifiers. This would have the same implications as those for using different platforms.
Providing different identifiers, however, allows that two instances can be installed in parallel. This is an “unwanted” situation as we will see later.
Similar to the platforms and language one could think of other “features”, which are somewhat related. Currently there does not seem to be other candidates, but we cannot discard the possibility of new future requirements.
The previous paragraphs showed some possible scenarios. One could of course think of combinations. For example, a new version could support additional platforms but drop some locales.
As we have seen, it is necessary that extensions provide additional information in order to warn a user or to prevent the installation of inappropriate extensions. To date we have identified platform and locale as such information but there may be others. The combined identifier would therefore be composed of the extension identifier, platform and locale.
The meaning of the extension identifier (we could perhaps rename it) would be changed from:
“... uniquely identifying and extension”
to: “a unique name for a logical extension.”
That is, there can be several instances of one logical extensions (that is, different files), which have the same extension identifier.
There can be one to many platforms and locales. To facilitate matters, there could be an 'ALL' locale and platform.
Currently the extension identifier is used for uniquely identifying an extension. This is important for two scenarios:
Manual installation. The Extension Manager must determine if an extension is already installed. If so, the extension which is being installed will replace the installed extension.
Online update. The Extension Manager needs to find exactly one version which represents an appropriate update.
When there are two extensions with the same extension identifier, then they can replace each other. For example, the extensions A and B have the same extension identifier and A is already installed. When the user is installing B, then the Extension Manager compares the identifiers. And when the identifiers are the same, then B will replace A. Depending on the versions, the users will be displayed a warning informing them that they are going to replace the same version, an earlier version or a later version.
The combined identifier would serve the same purpose. But then an extension need not have the same combined identifier but it would be sufficient to have a “similar” identifier to be a legitimate replacement to an already installed extension. The reason for this is to be as flexible as possible, with respect to adding, removing or merging platforms / locales in later versions.
Before we go on explaining what “similar” exactly means, let us be clear about what would happen, when two extensions are installed which have the same UNO services. UNO services are identified by their service names. If there are two extensions containing the same services and one is already installed, then installing the second extension will overwrite the registration entries of the services of the first extension. When code instantiates a service, then always the services from the last installed extension are used. This could only be prevented with providing different service names. But then, the extension identifiers should be different as well, because the extensions contain different services. Installing the second extension would make the first one “not working”. Therefore we would only allow to install one instance of an extension.
Regarding the combined identifier, the Extension Manager needs to compare the extension identifier, the platform and the locale. Now let's see how they must match in order to determine if one extension can replace another.
Extension Identifier
Because the extension identifier represents the 'logical extension' they must be the same for both extensions.
Platform
Regarding the platforms, there are three important points to consider. First, an extension must support the platform where it is to be installed, otherwise it cannot be installed. Second, an extension may have several target platforms. Third, there cannot be two extension installed with the same extension identifier (remember the UNO services). Taken these into account, then an extension can only replace another extension when they both support the platform where the first one is installed. When this is the case then we disregard all other target platforms. Here are some examples of two extensions, A and B, where B can replace A. We assume that A is installed on Windows and both have the same extension identifier and the same locale.
Example 1:
A supports Windows.
B supports Window, Sparc
Example 2:
A supports Windows, Linux
B supports Windows
Example 3:
A supports all platforms
B supports Windows
Example 4:
A supports Windows
B supports all platforms
In case the extension, which replaces the installed extension, has a different set of target platforms, one could inform the user about it. And of course, the user would be notified if the extension cannot be installed at all.
Locale
Earlier on we said that it would be useful to allow the installation of an extension even if it does not support the office's locale. Since we also want to be flexible and allow adding/removing and merging of locales in later version, we would allow every set of locale to replace the “installed locale”. For example, extension A is installed and is to be replaced by B. A and B have the same extensions identifier and support both the same platforms. Then it would not matter what locales B supported.
In case of a manual installation the user would choose exactly one extension to be installed. In case of the online update there could, however, be a variety of possible updates. For example, extension A is installed and there are three possible updates, B1, B2, B3. All extensions have the same extension identifier and target platforms. B1, B2, B3 have also the same version.
Example 1:
office: en-US
A: en-US
B1: en
B2: en-US
B3: en-GB
In this case B2 would be the perfect match.
Example 2:
office: de
A: en
B1: en
B2: en-US
B3: de
Here B3 would be preferred, although the locale does not match the
locale of A.
What complicates matters is that OOo can support various locales while one is active at a time. For example, the office currently uses 'en' and also supports 'de'. The extensions have these locales:
B1: en
B2: en, de
Actually B2 would cover more locales of the office and would therefore be a better replacement. Now consider this case:
Office: en (active), de, fr, en-NZ
B1: de, fr, en-NZ
B2: en
Although B1 matches a lot more of the office's locales than B2, B2 would be preferred because it matches exactly the currently used locale. Selecting B2s would probably be in the user's interest.
There can also be the case that there is no perfect match but only near matches. For example:
Office: en-US (active), de-DE, fr-FR
B1: en-GB, de-AT, fr
B2: en-NZ, de, fr
What would be the preferred update?
Regarding theses scenarios and taking into account, that users hardly ever switch the locale of the office, I suggest to choose the update according to which extension matches best the active locale of OOo. To avoid confusion, developers should either provide only one extension containing all locales or provide 'suitable' sets of locales. For example:
A: en, en-US, en-GB, de, de-DE, de-DE-hamburg
B: es, es-GT, es-MX,
That is, one should not split one language:
A: en, es-GT, de, de-DE, es-MX
B:es, en-US, en-GB, de-DE-hamburg
Today's extensions should also work in the future. Because they do not yet provide platform and locale information, we would assume that they are suitable for all platforms and support all locales.
To allow the merging of two extensions with different identifiers, we should introduce the 'alternative extension identifier'.
A platform specifier should exactly determine the platform related requirements of the components contained in an extension. This includes
operating system
used compiler
processor
Operating systems could be general names like Windows, Linux, Solaris or particular product names, such as Solaris 10, Windows Vista 32, Windos Vista 64.
The compiler part indicates the application binary interface (ABI) as well as other library dependencies, such as C and C++ runtimes, stl library, etc.. The use of a particular compiler may also require a particular bridge in OOo. The name of the compiler could also indicate if 32 or 64 bit code was produced.
The processor types could also be provided as general names, such as Sparc, x86, or particular type names, such as 'Pentium 4'.
The different parts of the platform may partly carry redundant information. For example, a compiler may only produce code for a particular processor and operating system. Some compilers can, however, produce code for different processors. This is similar with operating systems. For example, Windows only runs on x86 processors but Solaris runs on Sparc processors as well.
Operating systems, compilers, processors are developed constantly. Because one cannot see into the future, one can only describe a working constellation at the time of development. If an extension works on a particular platform is only "known to the extension itself". However, the office can make some rough guesses if an extension works. For example, OOo would deduce that an extension cannot work if
the compiler requires a C++ runtime which is not provided anymore in OOo
the extension requires Linux but the office runs on Solaris
the code of the extension is compiled for x86 but the office runs on Sparc
On the other hand, OOo would not know about compatibility problems caused by
some subtle compiler dependencies (whatever that is)
different versions within a product line of operating systems
different versions within a product line of processors.
Only the developer can find out about the latter problems. This, however, requires a huge effort, because the extension needs to be tested, whenever the platform slightly changes, for example, a new version of an operating system becomes available. The list of working platforms needed to be adjusted and new versions of the extension needed to be provided to the users.
So we can have two types of compatibility checks, where each one has its pros and cons:
Let OOo guess. An extension declares at a a very basic level the platform requirements, for example (VisualStudio 2008, Windows, x86). OOo recognizes incompatibilities as mentioned earlier. The extension does not need to be updated, because of some platform change. However, an extension may still not work after installing.
The extensions declares all working platform constellations. It uses exact product descriptions. The office only checks if the current platform of OOo corresponds to one of the platforms declared by the extension. If there is a match, then it is safe that the extension works, otherwise the extension does not work. The extension must be regularly updated to reflect recent platform developments.
The #2 method assumes that if a particular platform is not declared, then it was found to be not working and must not be installed. That is, the absence of a particular platform indicates that. In other words, we have an implied “negative list”. One could of course weaken this a little. For example, the users could be asked if they still want to install an extension, even if it does not declare explicitly that the user's platform is supported. But then, the extension should explicitly declare the “negative – list”. Only if the users platform is neither declared as working platform nor is contained in the “negative-list” then users would be asked.
By using the “negative list” and asking the user about the installation, the requirement for constantly testing new platforms and providing updates has gone (although it should be done regularly though). In this scenario it would also make sense that OOo makes its “guess checks” as well. For example, an extension declares as operating system Windows XP and there is no negative list of operating platforms. If this extension is now being installed on Linux, then the user would be asked if the installation should proceed. Obviously, that would not make sense. OOo could deduce that Windows XP is some kind of Windows and prevent the installation in the first place.
It appears that the last described solution offers a good compromise between “preventing the user from installing not working extensions” and the maintenance effort for extensions.
The supported platforms and the negative list of platforms could be declared as dependencies. For having OOo do its “guess checks” one could have these dependencies
Basic Compiler
Basic Operating System
Basic Processor
For exactly declaring the platform, we would use
Specialized Compiler
Specialized OperatingSystem
Specialized Processor
And for the negative lists we would use
Not Working Compiler
Not Working Operating System
Not Working Processor
The names given here may not be final.
If one dependency implies another, then one only needs to declare one dependency. For example, currently all Windows operating systems only run on x86 processors. Therefore it would not be necessary to specify the processor unless the extension makes use of some specific processor capabilities.
It would also be unnecessary to declare a “Basic” dependency if there is the respective “Specialized” dependency declared. The terms for compiler, operating systems and processors need to be build-in into OOo so that it can actually do a platform comparison. When introducing a new term one can also provide the corresponding “Basic” term. Then OOo could deduce automatically the “Basic” dependency from a “Specialized” dependency.
When an user upgrades OOo, then extensions may not run anymore. For example, the new version of OOo could have been build with a new compiler which makes the installed extensions unusable. Therefore OOo should check if the dependencies are still fulfilled after an upgrade. Currently the dependencies are only checked during the installation of an extension.
To indicate that an extension is suitable for all platforms one would simply not declare the dependencies.
Because the locales have no influence on whether an extension can be installed, we would not use a dependency for declaring them. Instead we could introduce some informational tag in the description.xml, which could describe a set of locales. Every locale would be represented by a locale string of the form 'language-country-variant'.
=================================================
That's for now. If you've made it until here, congratulations and thanks for your patience. If you like, you can discuss this article on
dev@extensions.openoffice.org. The subject is not simple, therefore a good idea is always welcome :)
tags: development extensions
Saturday, 15 Mar 2008
Finally it’s done. After integrating the new notes feature, another one of the most requested enhancements (168 votes) has been implemented on our way towards OOo 3.0: The Multiple Page View. This feature allows you to arrange two (or more) pages side-by-side instead of having all pages stacked top-to-bottom:
First, I’d like to thank Leonard Mada, who volunteered to take over the role of the specification owner and did a great job on evaluating user requirements and doing a competitive analysis of other word processors regarding this feature. Another big ’thank you’ goes out to everyone who provided us with input during the initial discussion of this feature, especially Andreas Schuderer, who implemented a set of JavaScript prototypes showing some possible approaches to this feature. So this is one more success story of how community members can actively take part in developing new features and improving the product.
Now, let’s have a closer look at the new user interface elements that have been introduced for this feature. First, the zoom dialog has been changed. In fact this became a ’Zoom & View Layout’ dialog:
Automatic means that as many pages are arranged side-by-side as fit into the current view. Single page gives you the view layout as it used to be up to now and finally columns let’s you set a fixed number of side-by-side pages. If you choose to have an even, fixed number of columns, you can enable the book mode. This screenshot to gives you an impression how the book mode looks like in combination with the new notes feature:
Next, there’s a new status bar control which allows you to choose between the most important view layout settings by just clicking an icon. The icons (from left to right) are single page, automatic, and 2 columns book mode. Also located in the status bar is the new zoom slider control. There are some snapping points arranged on that slider that allow you to easily set some specific zoom factors, e.g., 100% or ’fit two pages’:
So get the current developer snapshot (DEV300_m3 or later) from the one of the OpenOffice.org download mirrors and check out our new feature. As always, feedback is very much appreciated!
Friday, 11 Jan 2008
We are now short before code freeze for OpenOffice.org 2.4 and the framework team tries to fix the last important issues. I think it's time to take a look at the new major version: OpenOffice.org 3.0. We have one project regarding the OpenOffice.org user interface where your feedback is warmly welcome. We want to brush up the existing keyboard customization tab page. It's the last customization tab page which uses the old OpenOffice.org 1.x layout so it's time to exchange it with a better design. I would also guess that this tab page is the most important one regarding customization. The only prerequisite is that the new tab page uses the same style as the other tab pages (e.g. menus, toolbars and events). We don't want to irritate users with a completely different style. You can see a screen shot from the current the keyboard customization tab page below.
The user experience team supports a mailing list where you can discuss this feature and provide design proposals. They are curious for your proposals and ideas to brush up this tab page, so please provide feedback.
If you have technical questions, please use the “dev” mailing list of the OpenOffice.org Application Framework project.
Wednesday, 19 Dec 2007
During last six weeks, the PDFImport team in Hamburg experimented with Agile software development, especially using ideas of Scrum. We wanted to know,
Some of the things we did different than usually (in the hope to reflect agile development principles):
The experiment is finished for now. About the produced software see Thorsten Behrens' post.
About the "agile" way of working, I'd like to share some observations:
The team absolutely loved the combination of development and QA in space and time!
Sitting together, being able to get QA feedback on development steps within hours. They loved to be able to communicate directly, e.g. without the need of involving IssueZilla, because most issues could be resolved immediately.
Continuous testing isn't that easy. Finding ways to automate tests needs time. Often tests broke for reasons within the test or the used tools rather than for the tested code. In the first weeks there needed to be quite some time invested into the infrastructure of building and testing.
On the other hand, the continuous testing found a huge amount of defects that would have been much more costly when found and fixed later.
We found out that an agile development style has high requirements on the building infrastructure:
Some team members saw the frequent interaction with the Product Owner (in his role as customer representative) as the single most important factor in having a satisfying result at the end of the experiment. So, asking quite often, if developed features are still moving into in the right direction, seems to be a very good thing.
There were three iterations. While in the first two, many planned work had to be postponed, in the third iteration more than planned could be completed. Doing things in a new way definitley needs time to adapt.
The daily status meetings appeared not to be very useful for communication within the team, because the team communicated the whole day anyway. We kept them nonetheless, because they helped to
A complete evaluation of the "agile" experience is still on the way, but one thing can be said: The experiment was promising. We learned a lot and there seem to be at least some practices that may enhance our development style.
tags: development openoffice.org qa software
Wednesday, 18 Jul 2007
Here is my weekly update on what is hot in our development teams in calendar week (CW) 29.
IN FOCUS
OOXML Fails to Gain Approval in US
“ On Friday July 13th, INCITS V1 met via teleconference for 3 hours but failed to reach a 2/3 consensus necessary to recommend an "Approval, with comments" position on Microsoft "Office Open XML" (OOXML) document specification. “
source: http://www.robweir.com/blog/2007/07/ooxml-fails-to-gain-approval-in-us.html
WEEKLY SCHEDULE
CALC
http://sc.openoffice.org/
Started:
-
Ongoing:
OOXML import filter
ODF formula implementation
Integrate locale data from OOo community
Moving of columns and rows
Finished:
-
CHART
http://graphics.openoffice.org/chart/chart.html
Started:
-
Ongoing:
OOo 2.3 bugfixing
Finished:
CWS chart07
DATABASE
http://dba.openoffice.org/
Started:
-
Ongoing:
Report Designer: ongoing bug fixing towards 2.3
Finished:
Make HSQLDB views sub/selecting from asterisks more standard conform, fixing issue 78296 this way
IMPRESS, DRAW & GRAPHIC SYSTEM LAYER
http://graphics.openoffice.org/
http://gsl.openoffice.org/
Started:
-
Ongoing:
Mac PICT Filter enhancements for better Mac clipboard support
Professional Presenter Package => PresenterView implementation
OOXML import
Table suppport in Impress
Drawing layer primitives
Working on Aqua Port
ODF 1.2 Acessibility Features
Creating sophisticated UI for 'object move along path' effects
Finished:
-
WRITER, MATH & FRAMEWORK
http://sw.openoffice.org/
http://framework.openoffice.org/
Started:
-
Ongoing:
Writer/Math/Framework: Evaluation of requirements in Issuetracker
Writer: OOXML Import: Tokenizing of shapes
Writer: OOXML Import: Mapping of table properties
Google Summer Of Code 2007: Defining requirements for an improved "notes" functionality
Writer: Make code warning free
Writer: improved language selection; language selection by switching keyboard language (Windows only)
Framework: Vista Readiness - new file dialog
Finished:
Framework: Implementation of Custom Handler for OLE embedding in COM clients
PROGRAMMABILITY
http://api.openoffice.org/
http://extensions.openoffice.org/
http://installation.openoffice.org/
http://ucb.openoffice.org/
http://udk.openoffice.org/
http://util.openoffice.org/
Started Tasks:
Netbeans OOo API Plugin: feature implementation for version 1.1 ( details)
Extending UCB with HTTPS support
Ongoing Tasks:
Extensions infrastructure: Extendable OO.o Help System: Concept
Netbeans OOo API Plugin: bug fixes
SDK Tests: Transform manual tests to fully automatic tests
UNO API Tests: Make tests usable for every developer: Step 1: Put all currently failing testcases in the exception list of the respective CVS module
Finished:
Netbeans OOo API Plugin: Add support for “new” description.xml features (version, identifier, license, ...)
ODF / XML
http://xml.openoffice.org/
Started:
-
Ongoing:
CWS XSLTFILTER08 for XML based filter
OASIS ODF Metadata SC proposal – Examples
OASIS ODF 1.2 Specification Document
Finished:
-
ODF TOOLKIT
http://odftoolkit.openoffice.org/
Started:
Graphical document model explorer (simple tree view)
Ongoing:
ODF4J: text documents: style handling (styles.xml and automatic styles)
Restructuring of OOo packages: Separation URE / Office (Windows / Mac OS)
UNO-API for ODF Toolkit: Study Use Cases
Package Restructuring, Extension Infrastructure: Use Delay-Loaded DLLs for Windows OOo DLLs
Google Summer of Code: Bug fixing and testing for AODL
AODL: Coordination of Chart implementation by CH2000 employees
Finished:
-
VISUAL DESIGN
http://ui.openoffice.org/VisualDesign/
Started:
-
Ongoing:
Icon redesign – Galaxy project
New design for OOo extensions website
Finished:
Player buttons for Impress
ALL TEAMS
Started:
-
Ongoing:
OOo bug fixing
Patch evaluation and integration
Finished:
-
tags: development openoffice.org
Wednesday, 04 Jul 2007
Here is my weekly update on what is hot in our development teams in calendar week (CW) 27.
IN FOCUS
Sun ODF Plug in 1.0 for Microsoft Office Available Now as a Free Download
“ Microsoft Office users can now import and export to Open Document Format (ODF)
The Sun ODF Plug in for Microsoft Office gives users of Microsoft Word, Excel and Powerpoint the ability to read, edit and save to the ISO-standard Open Document Format. The ODF Plug in is available as a free download from the Sun Download Center (SDLC). Download the ODF Plug in.
The Plug in is easy to setup and use, the conversion happens transparently and the additional memory footprint is minimal. Microsoft Office users now can have seamless two-way conversion of Microsoft Office documents to and from Open Document. The ODF Plug in runs on Microsoft Windows and is available in English. More language support will be available in later releases. “
source: www.sun.com/staroffice
WEEKLY SCHEDULE
CALC
http://sc.openoffice.org/
Started:
OpenDocument formula implementation
Ongoing:
Office 12 import filter
Integrate locale data from OOo community
Moving of columns and rows
Finished:
Printing defaults / warnings
CHART
http://graphics.openoffice.org/chart/chart.html
Started:
-
Ongoing:
OOo 2.3 bugfixing
Finished:
OOo 2.3 features, 37792 - nubmer format for data lables
DATABASE
http://dba.openoffice.org/
Started:
-
Ongoing:
integration tests for reporting engine, employing confwatch
Report Designer: finalize CWS oj14
Report Designer: ongoing bug fixing towards 2.3
Finished:
CWS a11ysep: fix regression in Calc/Solaris
IMPRESS, DRAW & GRAPHIC SYSTEM LAYER
http://graphics.openoffice.org/
http://gsl.openoffice.org/
Started:
Mac PICT Filter enhancements for better Mac clipboard support
Ongoing:
Professional Presenter Package => PresenterView implementation
Office 12 XML import
Table suppport in Impress
Drawing layer primitives
Working on Aqua Port
ODF 1.2 Acessibility Features
Creating sophisticated UI for 'object move along path' effects
Finished:
Discuss SVP plugin collaboration with Caolan
Creating an improved PDF import scenario proposal
Background-Sound support for presentation
WRITER, MATH & FRAMEWORK
http://sw.openoffice.org/
http://framework.openoffice.org/
Started:
Framework: Implementation of Custom Handler for OLE embedding in COM clients
Ongoing:
Writer: OOXML Import: Tokenizing of shapes
Writer: OOXML Import: Mapping of table properties
Writer: Rectangular selection mode
Writer: Storing of soft page breaks
Writer: Make code warning free
Writer: language selection by switching keyboard language (Windows only)
Google Summer Of Code 2007: Defining requirements for an improved "notes" functionality
Google Summer Of Code 2007: RTF Generator
Finished:
Framework: Options dialog for extensions
Writer: Configuration of handling of line breaks inside justified paragraphs
Writer: Implementation of revised SmartTag API
PROGRAMMABILITY
http://api.openoffice.org/
http://extensions.openoffice.org/
http://installation.openoffice.org/
http://ucb.openoffice.org/
http://udk.openoffice.org/
http://util.openoffice.org/
Started Tasks:
-
Ongoing Tasks:
Extensions infrastructure: Extendable OO.o Help System: Concept
Netbeans OOo API Plugin: bug fixes
Netbeans OOo API Plugin: Add support for “new” description.xml features (version, identifier, license, ...)
SDK Tests: Transform manual tests to fully automatic tests
Finished:
UNO AWT Enhancements: Tree Control: Finish initial impementation, integration into OOo Dialog Editor
Online Update: Download & Install: Implementation
UCB: WebDAV Content Provider: Update neon to version 0.26.3
Prepare material for Jazoon Conference – OOo Developement (presentation, workshop)
Extensions Infrastructure: Preferences Dialogs for Extensions: Implementation
Extensions Infrastructure: “Get more extensions here...” link (==> http://extensions.services.openoffice.org) in Extension Manager
ODF / XML
http://xml.openoffice.org/
Started:
-
Ongoing:
CWS XSLTFILTER08 for XML based filter
OASIS ODF Metadata SC proposal – Examples
OASIS ODF 1.2 Spec