For performance and maintainability reasons, the configuration component of OpenOffice.org has recently been re-written from scratch, see the corresponding Wiki page. (The “configuration” or “registry” of OOo is where many of the per-user settings and corresponding system-wide defaults are stored, like for example settings you change via the “Tools - Options...” dialog and the “File - Recent Documents” list.) The re-write is currently inspected by the OOo QA department, and it will likely make it into the OOo 3.3 release.

The one change that people will probably notice is that the plethora of configuration files (with file extensions .xcs and .xcu) scattered across the OOo installation tree has been reduced, to just a handful of files (with new file extension .xcd). While the content and XML format of the original data files has not changed (much), the new files simply concatenate together multiple old files (mostly to reduce disk access costs during cold start). This means that if you used to fiddle with OOo’s private parts by directly modifying some .xcu file in the installation, that hack will need adoption (probably best by turning it into an OOo extension, see next). OOo extensions (i.e., .oxt files) continue to include configuration data in .xcs and .xcu files, nothing has changed there. Similarly, the per-user configuration changes in an existing OOo installation are migrated to the new format on first start.

If you would like to give this a try well before it hits the OOo 3.3 master, I made available a number of builds at ftp://qa-upload.services.openoffice.org/sb111/:

• Sub-directory 11ab4c658928 (corresponding to the Mercurial source revision of the same ID) contains OOo installation sets for x86 Linux and Windows, in US English and German.
  
• Similar to the regular OOo Dev snapshots, those installation sets are .tgz resp. .zip tarballs that can be installed in an arbitrary location (alongside an existing OOo installation; but see next item).
  
• However, unlike Dev snapshots, these installations by default re-use an existing OOo user installation from a previously installed OOo 3 (at ~/.openoffice.org/3 on Linux and at something like C:\Program Files\Application Data\OpenOffice.org\3 on Windows)—so that the user data migration is actually field-tested. ;) So, you should probably backup your existing OOo user installation before giving this a try.
• If you rather want these installations to have user installations of their own (like the regular OOo Dev snapshots), you need to edit openoffice.org3/program/bootstraprc (Linux) resp. OpenOffice.org 3\program\bootstrap.ini (Windows), changing the “UserInstallation” line to something like “UserInstallation=$ORIGIN/USER”.
  

tags:

The thinning out process for Impress 3.3 is in full progress. Please find the Project Renaissance status presentation for November/December at the OOo Wiki. The presentation provides first mock-ups of  the planned changes.

Feedback welcome.

Best regards,

tags: renaissance user-experience

• Our current build system is handling parallelization in a very cumbersome way: Both build.pl and dmake can do parallelization, but they do not know of each other, and thus a build -P4 -- -P4 might happily run 16 processes in parallel.
• Our current build system does not support full dependencies and especially not full dependencies across module borders. This can be really confusing for new developers, but even seasoned developers are bitten by doing "compatible builds" where they should not.
• All modern SCM -- and that includes Mercurial, which we are using now -- support bisectional bug-hunting. However, this is not much fun if one has to do a complete rebuild on each step. Full dependencies would allow to step forward or backwards through history doing rebuilds only of stuff that really changed. Also, the necessity to do a complete rebuild after a resync will be gone, when we have reliable full dependencies.
  
• The current build system has grown historically and documentation is spare. As a result, lots of makefiles contain amounts of cargo-cult-programming. For example there are still many makefiles that use the CXXFILES variable although that variable is unused.
• Our current source tree is not read-only. It is a lot easier for build tools and SCMs to have everything which is generated from the source outside the source tree itself.
• Our current build system starts a lot of processes: There is one makefile per directory and one dmake-process per directory, resulting in more than 2000 make processes created per build. While this is not too much of an issues on Unix-based operating systems, on Windows process creation is slow. A replacement should be able to build OOo in one process (of cause, smaller build units will be still possible: e.g. building only one library/one module or for split builds).
  

• GNU make
• a POSIX-shell (to be specific: a bash-shell in POSIX-mode, other implementations might work, but are not intended to be officially supported)

• build.pl (thereby removing one dependency on Perl, which is pretty huge)
• dmake
• mkdepend
• rscdepend

• is using only GNU make and POSIX sh (no Perl, dmake, build.pl).
• is designed to be able to build OOo with a single make process.
• calculates complete dependencies (also across module borders).
• unifies the parallelization issues.
• uses a small and easy to use domain-specific language or API to describe the work to be done in the module. See for example: The declaration on how to build a library in the writer module. The API is using object-oriented concepts, which should make it easier to understand for developers without having to fiddle deep in the internals of the build system themselves. We are even planning to use a documentation system like doxygen to generate the documentation for the build system.
  

• Generating dependencies for C/C++ and resource files
• Compiling C/C++, resource and sdi files
• Linking shared libraries and linking executables (including creating automatic dependencies on linked-against libraries and header files)
  

• Do you think we are right in investing in modernizing the build system in this way?
• Have we missed a requirement or priority, that a revamped build system should support? (Maybe we are supporting the requirement, but just did not name it here. Feel free to ask!)
• Do you have other ideas, additions? Would you support the effort?

Since this a rather broad topic, I also would like to invite you to discuss a possible move to GNU make and its implications on the mailing list dev@tools.openoffice.org.

Best Regards,

Bjoern Michaelsen

tags: build gullfoss linux make openoffice.org parallelization scalability

Developer Snapshot build OOo-Dev OOO320_m7 which installs as OOo-DEV 3.2.0 has been uploaded.

The previously report issue is now fixed in this milestone: i107239 (Java GUI installer doesn't work).

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/next

Release Notes:
http://development.openoffice.org/releases/OOO320_m7_snapshot.html

MD5 checksums:
http://download.openoffice.org/next/md5sums/OOO320_m7_md5sums.txt

tags: openoffice.org qa release snapshot

I know some of you read the title and thought “Oh cool! I'm dying for a new user interface (UI). When will it finally be ready?” At the same time, some of you thought “Nooooooo! I like the UI already, even if there are a few little things here and there that annoy me. I wish they would stop this talk of a new UI.”

Before you read the more important stuff below this, let's just take a quick look at three basic questions.

1) Is there going to be a new UI for OpenOffice.org?
Yes. Improvements in interaction design (usability) will result in changes for the user interface. Good interaction design considers how fast you can do tasks which occur quite frequently and how easy you can figure out things you've never done before. BTW, "New UI" isn't a very exact term. We could just as easily say "revised UI" or "updated UI".

2) When will it be done?
Slowly but surely; over a long time; bit by bit. We will only change things if there is a good reason. And gathering and analyzing data (the "reason") takes time, as does designing improvements.

3) What is the goal of Project Renaissance?
To know and to understand our users as they are, and to help them accomplish what they want to, by providing efficient access to valuable functionality through a desirable user interface.

That said, the following is an elaboration on those three points and an attempt to clarify any incorrect interpretations of Project Renaissance.

There is a great deal to do within the scope of Project Renaissance, and since the OOo community regularly comes out with a new version of the OpenOffice.org office suite, each version is an opportunity to improve the interaction design. Slowly but surely. This usually involves UI changes, but sometimes may only result in performance or other intangible changes not visible on the UI. A motto for Project Renaissance is "form follows function".

In keeping with the goal of providing efficient access to valuable functionality, experience thus far has lead us to focus first on solving some fundamental problems so we can build on those solutions in later stages of Project Renaissance. One of the fundamental problems now in focus is reducing the complexity of the very large number of graphic elements on the UI. This is a big problem and so it will take time and many steps to work on it. Improvements will be noticeable here and there as we go.

We've always said that Renaissance is a long-term project. Unfortunately, many people got the wrong impression from the really real-looking prototypes (probably because our developers are really good at coding). Fortunately or unfortunately, depending on your preference, those prototypes were exploratory---just ideas we were trying out, not the real solutions. What they, and the design idea collection before them, did, was supply us with a lot of feedback that is invaluable in the continued unfolding of the Renaissance work. "Unfolding" describes not only the work but also what happens whenever we start to work on an improvement.

For an excellent explanation, I would like to quote UX Architect, Matthias Müller-Prove:

"Most, if not all UI problems get larger during the time you are working on them. To a certain extent this is natural because you get more deeply involved and gain a better understanding of the issue. You discuss the topic with colleagues and incorporate their point of view into the design. You discover new aspects that somehow match your topic. [...] The challenge is to keep the chunks of UI problems you address manageable. At the same time you have to keep an eye on the overall structure of the product."

If you have a minute, you really should read the entire text on The White Water Lily Effect.

So, fully aware of the challenge to keep the UI problems we address manageable, our current focus is the task-oriented optimization of interaction in Impress, due to be out in version OOo 3.3. More unfolding of Project Renaissance will continue, bit by bit, step by step. This is one of the first bits to reach the implementation stage.

To get a better idea of what "task-oriented optimization of interaction in Impress" means, to see which issues are in this "manageable chunk" so far, and to follow how the work is progressing, see the new pages in the OOo Renaissance wiki.

Best regards,
The Renaissance Team

tags: impress renaissance user-experience

Developer Snapshot build OOo-Dev DEV300_m66 which still installs as OOo-DEV 3.2 (see i107355) is available for download.

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/next

Release Notes:
http://development.openoffice.org/releases/DEV300_m66_snapshot.html

MD5 checksums:
http://download.openoffice.org/next/md5sums/DEV300_m66_md5sums.txt

tags: openoffice.org qa release snapshot

Developer Snapshot build OOo-Dev OOO320_m6 which installs as OOo-DEV 3.2.0 has been uploaded.

ATTENTION:
Due to P1 issue http://qa.openoffice.org/issues/show_bug.cgi?id=107239 the Java based installer will not work on all platforms where it is used. This issue will be fixed within the next milestone OOO320_m7.

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/next

Release Notes:
http://development.openoffice.org/releases/OOO320_m6_snapshot.html

MD5 checksums:
http://download.openoffice.org/next/md5sums/OOO320_m6_md5sums.txt

tags: openoffice.org qa release snapshot

As Christoph Noack opened a time capsule, let me do the same. Mine goes back 2 months to Sept 17/18/19 when specially invited members of the German-language OpenOffice.org community came to Hamburg. The visitors pictured above, plus me and Marcus Lange from Sun who joined the photo, were (l to r): Marcus Lange, Florian Effenberger, Daniel Stoni, Christian Lohmaier, Elizabeth Matthis (aka Liz), Thomas Hackert Uwe Altmann (not pictured: Gerald Geib, Volker Merschmann)

It was so wonderful to meet face to face people otherwise only known from email and to be able to thank them for their dedication and support. They each traveled here at their own cost (from far corners of Germany and even from Switzerland), which further shows their enthusiasm and dedication to our thriving open source product. On Thursday evening, those who were already in Hamburg met at a pub (Max&Consorten) for a first get-together. Afterward, most of us concluded the evening with a round of beers and more talk at my home---which I jokingly called "Motel Matthis".

Friday started out with a heartfelt word of welcome and thanks from Michael Bemmer, Senior Director of StarOffice/OpenOffice.org Engineering, and unfolded with a series of talks and snacks, including lunch and several smaller group meetings about special topics, until concluding at approximately 5:30 PM.

There were entertaining and informative talks by Stefan Taxhet on OOo in general, Gerd Weiss on infrastructure---including a personal tour of the server rooms to underline some of his points about the hardware, Andreas Bartel on Renaissance and Uwe Fischer on documentation, as well as tours of the engineering facility and opportunities to say hello to many of the OOo developers in real life.

At the end of the very busy but fun day, those of us who still had time went out to eat together at an Italian restaurant (maybe this was to get in the mood for the OOoCon in Italy!) and, several courageous visitors even spent a second night at Motel Matthis! This time Uwe made sure we had enough beer to let us talk long into the night. Thanks, Uwe!

Some comments I received after the visit are:

thackert: "It was interesting to become acquainted with some people I'd only known the mail address or nick of, and to hear really interesting talks as well to "sightsee" SUN. All in all a nice trip and - the best of all - a really nice stay at "Motel Matthis" with a perfect hostess (Liz!)"

floeff: "Thank you very much to everyone who made this visit in Hamburg possible! I'd never been at Sun Hamburg before, and it was a really nice day meeting old and new friends, getting insight on how the OpenOffice.org development works, and after all, we also had a lot of fun and a real great time. Liz is a wonderful hostess and we all enjoyed some very special days in a community that more and more becomes a real family."

VolkerMe: "Thank you again for such a nice day, which was very much too short for me. The opportunity to have personal talks with the engineers at SUN was so interesting, I wasn't able to discuss everything, so I hope I can come back another time. And although it has been said so often: Thanks Liz for hosting the meeting, for the well-prepared accommodation and for being our always smiling guide!

Saturday came too quickly and I had to say goodbye to my delightful guests. I hope to organize another visit to thank additional and like-wise dedicated community members in 2010.

Kind regards,
Liz

tags: community user-experience

The current setup of websites for downloading OpenOffice.org installation sets provides builds for several languages and operating systems. But nowadays a lot more are built. Unfortunately they are not that easy to find as they are on mirror servers. The most users do not know this or how to come to these mirrors.

Furthermore there was no comfortable way to download language packs (currently for 96 languages !).

Another reason is that many native language teams have only a small staff or do not have the time to test all available Release Candidate (RC) builds on all platforms for their language. However, these are very close to a final release but have not got the latest tests. But why not offering these to the users with a hint to be carefully when using?

To improve this situation and to deliver more choice we have created a new download website layout.

Main Download Page

http://download.openoffice.org

This website was enhanced to download easily the build you want. Of course the well-known (green) One-Click download remains the same easy way to get your favorite version. The same for the orange button for Developer Snapshots. The new thing is the yellow button that will guide you to the website for Release Candidates.

Full Installations and Language Packs

The improvements were done here to provide all available stable builds:

http://download.openoffice.org/other.html

The first table provides all full installation sets as stable release of the current OpenOffice.org version. The second table provides all stable language packs.

BTW:
A language pack contains only resource files for a specific language and platform to show, e.g., menus, dialogs and error messages in your language. If translated it may contain also the help content. It's a comfortable way to get several languages without to install the applications double and triple. After installation change the languages via menu "Tools - Options - Language Settings - Languages - User Interface".

Release Candidates

http://download.openoffice.org/all_rc.html

Some days ago the 100 millionth download of an OpenOffice.org build was announced. We hope to increase this impressive number with the new download websites.

Happy downloading. :-)

tags: beta build candidate download languagepack openoffice.org qa release snapshot

Developer Snapshot build OOo-Dev OOO320_m5 which installs as OOo-DEV 3.2.0 has been uploaded.

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/next

Release Notes:
http://development.openoffice.org/releases/OOO320_m5_snapshot.html

MD5 checksums:
http://download.openoffice.org/next/md5sums/OOO320_m5_md5sums.txt

tags: openoffice.org qa release snapshot