With previously announced milestone DEV300 m59 we are introducing language packs for Mac OS X. We are starting with the usual snapshot languages Arabic, French, German and Japanese but expect to support more languages with the next bigger release.

In the specification you can get a first impression how it will look like. It was done by our community members Christian Lohmaier and Raphael Bircher. So, thanks for one difference less between the platforms.

Please give the langpacks a special try when you test the Mac build. Issues can be filed as always in the issue tracker.

tags: langpack language mac macos openoffice.org os pack qa release snapshot

The Mac/aqua port is considered a regular port since OpenOffice.o4g 3.0. There could be done more for system integration, sure, but that is true on all other platforms, too. In fact system integration is better in some regards like e.g. we use the system spell checker on the mac (thanks again to msicotte) and have support for Apple's remote control that gets issued with most macs (thanks again ericb).

One thing still missing were Netscape plugins, an ancient leftover from times when StarOffice was also a web browser. That is long since not the case anymore, however plugins allow you to embed things like shockwave/flash animations into your documents, a feature that is useful to many of our users. Now we have these old plugins also on the mac - please do not confuse them with WebPlugins for WebKit: that doubtless would have been an even more useful addition, but is currently out of scope. Plugin support has been tested with flashplayer and QuickTime plugins (the latter was already available through "Insert->Movie and Sound", but can now also be used with "Insert->Drawing Object->Plug-In" for what it's worth).

There is just one drawback: plugins added a dependency of the outdated QuickDraw API because some plugins still rely on that. There is currently a transition for plugins to move to CoreGraphics based drawing, but out in the wild are still many plugins that haven't made that move yet. This will be one more place to take care of when the mac port moves to 64bit at some point.

This change will become available with the integration of CWS vcl100, which should be soon in DEV300m45 or DEV300m46.

tags: mac openoffice.org

A while ago I said I wanted to restructure printing in OpenOffice.org. As things usually go I was distracted by other things for a while (like e.g. getting an OOo 3.0 out of the door or some serious issues into 3.0.1). Recently however I got back to these plans and begin to see something. See here the new print dialog with preview.

The intent is to enable native print dialogs - see here the mac one:

And here's where the step backwards is: the preview of the nice aqua print panel is disabled, if you add your own controls (aka an "accessory view") to it and your application is still linked for MacOSX 10.4 (see here) - even if you use the new API mentioned which thanks to objective-C's late binding you can actually do. So it's drop either all the 10.4 users (about half of the Mac user base) or drop the preview on 10.5. Both unacceptable of course, we'll have to come up with something different; perhaps a two dialog approach (which also is less than optimal).

So when is this going to see the light ? I'm afraid not so soon. The extra controls you see in the pictures are functional, just the applications do not react on them - basically because everybody didn't have the time for implementation; Resources are stretched to the limit as they usually are. Also the controls are yet incomplete (the shown example is form impress; if you look at impress's options page you'll see there are more controls to be migrated). With feature freeze on 27th of November and half of the implementation not ready, this will not go into 3.1, but be delayed to 3.2. At least that gives us some time to come up with a better solution for the native aqua dialog.

tags: gsl mac ooo

The last major issue to be solved is the behaviour of the VCL TestTool application after OpenOffice.org crashed.
The quickstarter behaviour needs to get disabled for automated testing, which currently can not be triggered after a crash on MacOS X.
The winning issue which solves this is 86540 which will get integrated with cws gh15. Thanks to GH for getting this done.

In the meantime I also found a workaround for this: Registering a Basic macro to be executed on startup of OpenOffice.org.

Read more ...

tags: automated_tests mac

tags: accessibility mac openoffice.org

Well actually in case of an OpenOffice.org developer one should probably say "the seagull has landed". So after around 24 hours sitting around either playing sardine in a flying can or still sitting around waiting for the next flight I'm back in Hamburg. The almost unbearable suspension whether my baggage made it in the same flight reaches an all time peak as I wait for 45 Minutes until the happy end. Indiana Jones IV was lame in comparison. Then back to the parking lot where my car actually still is. Trees. San Francisco may be green as in eco, but Hamburg is green as in trees. And promptly it begins to rain. I'm home :-)

Some things changed ...

A lot of news regarding the new iPhone mostly you know already from the press. A lot of other information is not to be mentioned to a larger public (those are the rules of WWDC) and so I'll constrain myself to some basics:

•  The migration to 64bit that began with MacOSX 10.5 (Leopard) will continue, we should begin to think about providing a 64bit version; Apple really encourages that now. Our 64bit version cannot however be based on 10.4 (Tiger) and needs to have the remaining few carbon places removed (mainly ATSUI, HITheming is supposed to be available still, which we need to verify).
• Talking to some Apple engineers confirmed our accessibility efforts are on the right track really.
• We (msicotte, ericb and me) learned about Apple script, which mike wants to evaluate as his next project. The first thing coming to mind would have been a UNO binding like to OpenOffice.org's basic implementation, but apparently that is not the correct way. Stay tuned until we come up with a sort of plan on how to proceed.
• Some Apple engineers suggested a workaround for the Quicklook plugin problem, namely embedding a PDF file (which would of course not simply be exported, but much simpler). Whether this is really a viable solution will have to be evaluated.
• It seems ATSUI/CoreText do not do hinting or more precisely do that only in a black&white (=1bit) context. I find this rather strange, but at least it would explain the "gray baseline" feature in our text rendering.

... and some were the same

Who can guess which photo is from WWDC 2007 and which from 2008 ? Ok, the links give it away :-)

tags: mac openoffice.org

The feedback we got for the Aqua port of OpenOffice.org 3 Beta was extremely encouraging. This is very motivating. Thank you!

There was some constructive criticisms about some aspects of the port too. I'm happy to note that many of the issues are already solved in two developer's child workspaces (aquavcl07 and aquabmpfix01): keyboard handling, graphics performance and some visual details will improve considerably soon in one of the next regular development snapshots.

tags: beta development mac openoffice.org

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

After a hectic week of discussion, implementation and rewriting we now have a new initial window when you start OpenOffice.org without a document. This up to now brought up a large window (so large because it defines the size of the document that will replace it) in "battleship gray" as some call it. On most platforms you don't see this window so often, because system integration will usually leave you with an application window (Writer, Impress, Calc, ...) instead. On Mac however the so called StartModule is the norm rather than the exception. So we put a long planned overhaul of the StartModule in motion. The first plan was to use a dialog replacing the StartModule, however that would lead to questions about modality, startup and exit behavior due to the modal event loop and similar issues.

 So in the end we decided to improve the existing StartModule instead, turning it into the new StartCenter. The StartCenter contains a host of labeled buttons (natively themed where available of course) that allow the user to create a new document or open an existing one. It also shows the same menu entries as before, so additional features like the recent file list are still available.

A little toolbox marks the lower right side of the new StartCenter giving the user the possibility to enhance his OpenOffice.org experience in the Web. Replacing the "battleship gray" background by a nice gradient rounds the new look to the new nice window you can see be

Turn this	Into this
The old StartModule	The new StartCenter

 My thanks go to

• Stella for creating the new images in a short timeframe (and in rapid succession as the design evolved).
  
• Frank Loehmann for working extra time in design

and many others who made this possible in a rather short timeframe.

UPDATE: I forgot to mention that this is not integrated into the master yet, but part of CWS aquavcl05 which is now "Ready for QA". Integration into the master should be before the 3.0 Beta feature freeze on 6th of march.

tags: mac openoffice.org

This success was possible by identifiying and fixing a bug that killed application responsiveness, by identifying and avoiding unnecessary and expensive repaints and by accelerating some expensive queries which could sometimes be completely satisfied by short-circuiting to cheaper code.

Another annoying bug you might have noticed when working with the current Aqua port was that the application sometimes didn't progress until you "helped it" by e.g. moving the mouse. My fix to the event handling code will fix this problem for good.

On the performance frontier I'm confident that I can shave of another 10% of the loading/saving time of long documents soon. I'm also pondering about providing early visual feedback when loading documents. A change that would probably improve the application's perceived responsiveness considerably. The current behaviour, which is to load a document completely before showing just one page, doesn't fit into the 21st century.

What else is cooking here? When editing text in our Aqua port you might have noticed the problem of "dancing characters", which is being attacked. The Aqua port has some important PDF export issues. All of our ports currently have problems when PDF exporting text with unicodes outside of the base plane. Supporting PS-OpenType subsetting is also on my TODO list. There are some outstanding insights and patches for BiDi and complex text layout, which need to be integrated carefully, so that all use cases are covered. And then there is the huge mountain of "normal" bug reports that require developer attention...

tags: mac openoffice.org