Mac OS Porter Team at WWDC 2007
- 1 Results of our visit to Apple WWDC 2007
- 2 What does this mean for the OOo Mac port ?
- 2.1 Needed: a UI layouter with style sheet capabilities
- 2.2 No multilayered TabControls
- 2.3 Group controls
- 2.4 Terminology adjustments
- 2.5 Some things to be omitted
- 2.6 Some remarks concerning the first start "assistant"
- 2.7 Installation
- 3 Some technical advice
- 4 Some impressions from WWDC2007
Results of our visit to Apple WWDC 2007
During Labs, and other occasions, we met Apple engineers, in the following domains :
- User Interface and Design
- Apple and Open Sources relations
- Address Book
What follows is what we learned from our discussions with the Apple people who told us their opinion what we should ideally do.
The most important results first:
- Apple very strongly suggests not to use Carbon anymore. Carbon is not going to be available as 64 bit version in MacOS 10.5 (Leopard) whereas the rest of the system is full 64 bit. Furthermore Carbon will not be developed anymore ; it will probably be deprecated with 10.6.
- The same is true for the ATSUI layer which gets replaced by CoreText.
- Our current UI is not acceptable to the Mac User (we knew that, but details will follow below)
- The preferred installation method is by drag and drop, not the installer package.
- One important problem to solve : language packs. Which solution ? ( several possibilities are existing )
- Java awt lib must continue to be run from main thread, like Events .. etc. Won't probably change, because not thread safe, and that's the way Mac OS X works.
- the bug from HIToolbox ( scrollbarinfo instead of hiscrollbarinfo in HIThemeDrawTrackInfo will probably not be fixed)
What does this mean for the OOo Mac port ?
We need to
- first complete Carbon version "make it work first"
- then switch to a Cocoa based implementation "improve it and optimize"
This can be done gradually as Carbon functionality can be used from Cocoa. For our UI this enables us to deliver a solution quickly with HIToolbox's themed drawing functions. Later we will have to replace this somehow using NSView implementations, since Cocoa doesn't have (and as far as we know won't ever have) equivalent drawing functionality. However on the updside this supposedly will at least give us accessibility implementation for free.
Probably not a bad idea :
- work with UX project [to be more precisely defined]
Needed: a UI layouter with style sheet capabilities
The actual UI changes will be harder to do. Two of the things with severe impacts are these:
The OK button sits in the lower right corner, the cancel button left to it and then all other buttons. An optional HelpButton follows a completely different look (it is a small icon with a questionmark basically).
- This is also the button order that should be used in GNOME. In GNOME the help button is a normal button in the bottom left corner.
Labels and fields are center aligned
Best example: our Tools->Options dialog. There is a ton of fields there, all preceded by a Label. These Labels are left aligned. On Mac the fields should be below each other and left aligned, the corresponding labels precede their fields and are right aligned.
These examples show us that we need a layouter for our controls. And more, this layouter needs to be configurable so it can move the managed controls around quite severely, a row-column approach will not suffice. Lucky for us there is currently a project underway that should implement a layouter. Hopefully we can make our needs known and profit from that. Since other platforms (like e.g. gtk) also can profit e.g. from a different button order, this is perhaps not an overly optimistic wish.
No multilayered TabControls
If there are so many Tabs in a TabDialog that they do not fit in one line, do not open a second line, but add a last small Tab with a dropdown button. The dropdown opens a menu that shows all available Tabs and a Checkmark for the current one. Selecting a new one should activate that TabPage and the Tab should move to the middle of the TabControl if possible. This certainly is something that other platforms could profit from, too. Multilined TabControls are a nuisance everywhere.
If a group of controls contain only a single item, skip the grouping alltogether. It's useless. Example: Use OOo dialogs in Tools->Options->View.
In general group controls like FixedLines should be removed; it is better to separate logical groups by adding space instead.
- In GNOME don't use lines for grouping either
There are certain terms that should be replaced on the Mac platform, e.g. "wizards" are called "assistants" here.
- Same in GNOME and KDE (or is it only in KDE4?)
Texts of RadioButtons and CheckBoxes should always begin with a verb. E.g. Tools->Options->View: "Object refresh during interaction" should rather be "Refresh objects during interaction". The formulation is clearer since it looks more like a command what should be done.
Some things to be omitted
- no icons in menus
- toolbar highlighting: can be done, but we should find something much nicer to achieve the effect.
- no focus rectangles around text
- no visible accelerators (the lines beneath a Control text that show which key to press for activation). These should be not shown per default and perhaps could be enabled by a user setting.
Some remarks concerning the first start "assistant"
- In the end, don't say "finish", say "register" or such.
- Don't start a browser, instead fill in more information (like email address) and register from the "assistant"
- Replace the four radiobuttons on the last page with registration options by a CheckBox saying "register me as an OOo user" or some such.
A small installer was suggested that would let the user choose components and languages to install, then download and install them all at once.
Notes : download everything supposes the network is available (not obvious for all users )
This would not install a packaged installation, but simply be a more advanced form of drag and drop installation in that the user does not need to download everything. After download the selected components would simply be copied to a location of user's choice.
Some technical advice
- use Quartz debug ! We paint too much ( can be verified using Quartz Debug Tool, flashing in yellow when repainting something). Actually most of this is due to our busy painting method e.g. writer's smooth scrolling feature.
- Quartz is resolution independent, however an unscaled context has a user space unit of a point. So we should handle the resolution as 72 dpi fixed.
- No XOR, but we should really have a second look at kCGBlendModeDifference