tags: openoffice.org unicode

OOo-Dev3.0 Developer Snapshot build BEA300_m1 (BEA300 is the release branch for OpenOffice.org 3.0 Beta) which installs as OOo-Dev 3.0 has been uploaded to the mirror network.

The rename of the product name to OOo-Dev allows the installation of the OpenOffice.org snapshot parallel to an OpenOffice.org  'final' (released) version. For this version some language packs have been uploaded and they should install into the OOo-Dev installation.

Attention: Due to a bug (issue 88445) the installation of language packs will fail. The issue has been fixed in CWS native148. An integration of this fix will happen in BEA300_m2.

If you find severe issues within this build please file them to OpenOffice.org's bug tracking system IssueTracker.

Please use the following link
http://download.openoffice.org/680/index.html

If the Bouncer links that I've placed into the download page do not work for you then you might want to use the 'non JavaScript' page
http://download.openoffice.org/680/index-nojs.html

Or you may take one of the mirror servers listed at http://distribution.openoffice.org/mirrors/
and take the files from the ../developer/BEA300_m1 directory.

MD5SUMS:
http://download.openoffice.org/680/md5sums.html

tags: openoffice.org qa release snapshot

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

We've created a new master workspace (MWS) called BEA300. 

What does BEA stand for? No, it is not the name of program manager's girl friend. BEA300 simply is an acronym for Beta release of OOo 3.0 . In other words, while current development code line DEV300 is heading towards OOo 3.0 final without respite, we separated a branch to stabilize the code base for OOo 3.0 beta (branch name: mws_bea300). Only selected childworkspaces will be integrated to that master workspace, containing issues regarded as beta stopper by release status meeting. For details of the schedule please see OOo Wiki.

tags: openoffice.org release

tags:

OOo-Dev3.0 Developer Snapshot (build DEV300_m10) which installs as OOo-Dev 3.0 has been uploaded to the mirror network.

The rename of the product name to OOo-Dev allows the installation of the OpenOffice.org snapshot parallel to an OpenOffice.org  'final' (released) version. For this version some language packs have been uploaded and they should install into the OOo-Dev installation.

Attention: Due to a bug (issue 88445) the installation of language packs will fail. The issue has been fixed in CWS native148. An integration of this fix will happen within one of the next builds.

If you find severe issues within this build please file them to OpenOffice.org's bug tracking system IssueTracker.

Please use the following link
http://download.openoffice.org/680/index.html

If the Bouncer links that I've placed into the download page do not work for you then you might want to use the 'non JavaScript' page
http://download.openoffice.org/680/index-nojs.html

Or you may take one of the mirror servers listed at http://distribution.openoffice.org/mirrors/
and take the files from the ../developer/DEV300_m10 directory.

MD5SUMS:
http://download.openoffice.org/680/md5sums.html

tags: openoffice.org qa release snapshot

OOo-Dev3.0 Developer Snapshot (build DEV300_m9) which installs as OOo-Dev 3.0 has been uploaded to the mirror network.

The rename of the product name to OOo-Dev allows the installation of the OpenOffice.org snapshot parallel to an OpenOffice.org  'final' (released) version. For this version some language packs have been uploaded and they should install into the OOo-Dev installation.

If you find severe issues within this build please file them to OpenOffice.org's bug tracking system IssueTracker.

Please use the following link
http://download.openoffice.org/680/index.html

If the Bouncer links that I've placed into the download page do not work for you then you might want to use the 'non JavaScript' page
http://download.openoffice.org/680/index-nojs.html

Or you may take one of the mirror servers listed at http://distribution.openoffice.org/mirrors/
and take the files from the ../developer/DEV300_m9 directory.

MD5SUMS:
http://download.openoffice.org/680/md5sums.html

tags: openoffice.org qa release snapshot

Roughly a year ago Sun joined the Macport community. The goal we - meaning the  macporter team which Sun was now part of - set ourselves was that the Aquaport should be on par with the other OpenOffice.org platforms by the time of OOo 3.0 beta -which is now almost upon us. Being on par would have meant that the feature set of OpenOffice.org works as on the other platforms, but no extra system integration would have been done.

So did we reach that goal ? Mostly yes. There are some things that do not work yet:

• Printing Documents with multiple paper formats (e.g. Insert->Envelope). This is mostly due to the fact that the Cocoa print system does not allow that, we'll do that by splitting one print job into several jobs.
• No SDK yet. This was broken by the recent three layer office change and does not work yet.
• No Netscape plugins.
• No language packs. Currently the languages have to come with the office installation.

Most of these issues will be addressed until 3.0 Final.

In contrast to this we have achieved a lot of system integration tasks in addition to the necessary basics (in no particular order):

• Native file picker
• Native print dialog
• Quicktime integration
• System dictionary integration
• Spotlight integration
• Mac special font handling (what hdu likes to call "fancy ligatures")
• lots of smaller things like the black dot in the close button or using the system's recent items menu

tags: mac openoffice.org

Beginning with the DEV300 – OpenOffice.org 3.0 – codeline Sun QA Automation has started implementing a number of enhancements to the automated VCL Testtool scripts. The primary goal of these changes was - and is -  to gain speed while not sacrificing reliability and to reduce the maintenance overhead.

Based on the work of Thorsten Bosbach (TBO), Gregor Hartmann (GH) and Joerg Sievers (JSI) I've been working on

• Introducing the WaitSlot() command
• Replacing the filter lists by API calls
• Replacing the global Load/Save routines by UI-less functions

Today I'm talking about the new functions for saving and loading files.

Searching for ways to speed up our test scripts we quickly identified the loading/saving routines to be some of the primary time wasters - so we took a close look at the functions provided in <testtool>/global/tools/inc/t_files.inc.

What we found was that these functions have a number of drawbacks such as

• the use of localized filter names (which is something we really want to get rid off)
• the long path through the file dialogs - open the dialog, set names, paths, filters, options - which costs some five seconds per call
• the german function names that pose a challenge to each test script developer

Thorsten Bosbach pointed out that there exists another way of loading/saving the files directly by just using the FileOpen or FileSaveAs commands and pass them some additional parameters. As soon as these commands (slots) find any parameters they skip the UI part and execute directly. Here's a sample (Pseudo code, the names of the controls might be incorrect):

Classic code

FileSaveAs

Kontext "SpeichernDlg"

if ( SpeichernDlg.exists( 2 ) ) then

DateiName.setText( "/home/tester/.openoffice.org/user/work/myfile" )

DateiTyp.select( "ODT Text Document (.odt)" )

AutomatischeDateinamesErweiterung.check()

MitPasswortSpeichern.check()

Speichern.click()

sleep( 5 )

endif

New implementation

FileSaveAs( "URL", "file:////home/tester/.openoffice.org/user/work/myfile.odt", "Password", "MySecretPassword", "FilterName", "writer8", "Overwrite", TRUE )

The new implementation requires a few changes to the test script code. Most notably you cannot use the localized filternames anymore - you have to use the filters as they are required by the API (find a complete list below .../global/input/filters/api_filters.txt). Furthermore you do not have the option to automatically append a suffix which matches the filter you've selected. Here you have the option to generate a full filename by retrieving the suffix from the API (or use hGetSuffix( ... )) or to omit the suffix entirely and let the filter detection do the job for you. The latter is important when e.g. loading templates or samples where you have no idea what type of document you are dealing with. Filenames have to be passed in URL notation.

There exist a number of additional parameters to FileSaveAs(...)/FileOpen(...), such as "SynchronMode" (True/false), "AsTemplate" (True/False), "ReadOnly" (True/False), "FilterOptions" (options) and some more. However, they are not needed yet and thus are not used.

For the ease of use and compatibility considerations I've written the new functions to take the same number and order of parameters as their ancestors but still the interfaces are not guaranteed to be identical (namely the filtername, as discussed above).

You can still feed the functions with the filenames in the classic way, the conversion to platform specific file URLs is done within the new functions.

So finally you get the list of functions, their replacements, compatibility and implementation status:

These functions can be found below .../global/tools/int/t_files.inc and are automatically included when you have the LoadIncludeFiles code chunk in you .bas file.

Please note that the new functions introduce another change.

The Office loads files asynchronously. This means that we have no 100% reliable way to determine whether a document is loaded or not. Or more precisely: We know exactly when it is loaded but we have no idea when the application has really finished rendering the document. This is very important to understand: The office may not yet be ready to recieve further instructions in the instant the functions return.

There exist two functions "IsItLoaded" and "IsItSaved" that try to determine whether the office is ready or not but these are problematic and really waste a lot of time. A replacement has been provided, called hFileWait(). The new function makes use of the WaitSlot() command encapsulated in a loop which can recognize a few special conditions, such as the Macro Security warning coming up. This function appears to work reliably so far, but some real life experience is missing.

Please note that there is no timeline for the integrations/activation of the functions marked incomplete yet, this depends entirely on my workload, currently the 3.0 Beta has priority. The completed/compatible ones are already secretly called when you use the old functions. Your log contains a QAErrorLog encouraging you to swith to the new functions each time you call the old ones.

If you need more samples you may take a look at .../framework/first/inc/topten.inc which is the first test case to fully implement the new functions. And the result is significant: The test runtime decreased from 13:30 minutes to 7:30 on an average performing machine (that is a VirtualBoxed Fedora 8 on an Athlon64 X2/6000).

So once again i ask all test script coders to test these functions and give me feedback - in good or bad. I'm open for new ideas, like to hear your proposals for enhancements. Is it too complicated? Do you need more information?

tags: automated_tests

After travelling through Brasil and Venezuela I am finally back to the ice cold Hamburg. Vacation are over and the OOo 3.0 Beta is pretty near. Don't received a lot community translation for it ( uploaded 30 instsets from cws localisation28 ) , I guess you are working on the OOo 3.0 final one.

I created installationsets for the languages:
ar be-BY bg bn ca da de el es et fr gl hu it ja ko ku lt mk nl oc pt-BR ru sl sv tr uk vi zh-CN zh-TW

There are still some l10n errors in the Beta:
-Issue i88325 The string File->New->Template and Document is always in English. The translations are there but the code don't show them. Pointed Carsten to it.
-Issue i88387 Two Buttons in the new calc solver are always English ( "Shrink!" ) , did not yet found out why this happend. Seems to be an processing issue, the translation got overwritten in the database.

Good we found them now and not in the hectic OOo 3.0 final time!

-Ivo-

tags: openoffice.org