ericb's place

WWDC 07 Part 2

From WWDC07, the big marketing announce was "64 bits ready", and developers will pay the price of what Apple Marketing decided ...

Even if a lot of applications won't see any improvement, people will ask to have applications "64 bits ready", else nothing

Carbon won't be 64bits. At least the part of the API we use in current Aqua port. Indeed, current Aqua port of OpenOffice.org uses HIToolbox ( HITheme, Appearance ..etc). the main effort is concentrated into vcl module.

For salframe, we use Carbon WindowRef and a lot of Carbon things. About events, we use CarbonEvents, and because of the old model used by OpenOffice.org, we use WaitNextEvent() and all. A big issue was to find a way to use RunApplicationEventLoop(). We asked our RAEL() implementation to be expertised, and things looks ok, from Apple engineers point of view.

Some other parts will be 64 bits anyway (Carbon Events should be 64 bits without last minute change).

The immediate consequence is Mac OS X port must start to think Carbon replacement using Cocoa.

As good example, Damien started soem Cocoa cursors implementation. We'll document generously, as starting point. About something different, it's question of replace HIView using NSView too. We'll see.

But not now : Indeed, 64 bits Intel on Mac OS X port is a new port. It means we need to rewrite a new bridge, using Apple 64bits ABI for Intel procs, and a lot of changes like for Linux AMD64 port ... and we first will complete Aqua port ( without X11), and provide a working Mac application

Could be a 2 years or more plan.

Where in the code ?

- for everything graphical- probably for text ( using CoreText instead of ATSUI, but hard discussions are in progress, and nobody knows, e.g. since Core Text cannot yet do everything ATSUI does ... ). Why change from ATSUI : not well integrated with other frameworks, preformance is difficult to optimize, not available for 64 bits.
- new bridge
- co-lateral changes ( sal probably )
- svx
- framework maybe

Current Mac OS X port plan is :

1) Make it work first : provide a Mac application, not using X11, and having everything working.

Means :
1.1 integrate aquavcl01
1.2 integrate aquafilepicker01
+ see recent changelog

1.3) provide regular builds of Aqua version

1.4) start QA for aqua as soon as possible ( see FOSDEM presentation )

Yet missing in aquavcl01 :
- drag and drop ( Tino already started )
- native printing ( Yvan Barthelemy and Philipp Lohmann )
- native spellchecker ( nobody afaik )
- Mac Address Book ( Omer Bar Or + Florian Heckl )
- Aqua Look ( Ismael Merzaq , Eric Bachard )

Spotlight plugin integration is delayed, because of - Mox will confirm- legal issues. See : Violation of external policy for NeoLight source code

To be confirmed :
- complete Mac OS X shortcuts

Later :
- implement native sound player (using QTKit)
- Implement Image acquisition
- use the Mac OS X key chain for document signing
Problematic : ALT key , and accelerators (will be discussed during next meeting)

2) Start Cocoa implementation, using e.g. aquavcl02 cws

To help us, Pierre Chatelier, C++ and Cocoa expert, contacted me recently, to announce he translated his C++ -> Cocoa guide (english and french versions available) .

This is a very interesting document, and I'd suggest to all mac porters to discover it.

3) Redesign our UI

We had an appointment in User Interface labs, and we found a lot of issues with our interface.

- the wizard at first launch needs a lot of work
- we don't respect a lot of elementary rules a real Mac application should
- (a lot to be discussed)

-> Todo : invite UX people to debate a lot of issues. From last year, I remember John told me "a menu should propose what you need NOW", not a bunch of useless things, the user doesn't even understand the role.

-> 20% visible / 80% hidden (means for specialist )

-> from general to specific

Last but not least: not quit OpenOffice.org when closing the last window ...


Consequence : deep changes are probably mandatory in OpenOffice.org source code. Maybe this is the first time we ask to go as far ...

The good point is all ports will benefit such changes, not only the Mac port.

Some answers from WWDC to the questions about code :

1) Timers: Current code is obsolete, and compatibility with Leopard won't probably exist. Pavel wrote a patch using recent code ( see issue 75228).
Seems to work fine, excepted a thread issue (crash not easy to be reproduced, and I never could repoduce it btw)
Directly discussed the point with Philipp, who commited the code. Two instant crashes seems to have vanished since ( issues 77547 and 78129 )

2) Questions from pavel
Does Apple have a plan to enable UI drawing from threads different from the first one?
Does Apple have a plan to allow java to be run from other threads as well?
For both, the answer is no : what I have understood from Apple engineers is : they have to be in the main thread, because they are not thread safe, and things won't change because this is one Mac OS X foundation to work like that.

3) fix all our busy paint places
One more time discussed with Philipp : problems comes from Windows "model" we use to paint. Work in progress.

4) was HIThemeTabDrawInfo question ( or Ismael )
Version must be 1 ( old was 0 ).
Pb displaying the tabs : we have to ask in common part which tab is the first one, and which one is the last one, to paint borders properly.
Todo : add code in common part + implement
Other tip : use kHIThemeTabKindNormal only (other are not advised) [ possible cases are kHIThemeTabPositionFirst, kHIThemeTabPositionLast, kHIThemeTabPositionMiddle, kHIThemeTabPositionOnly ]

5) About XCode and dot in the binary name
Apple engineers confirmed this is a bug -> we have to file an issue

P.S. : they were very interested reading our wiki pages about XCode use.

6) I had a question about HIThemeScrollbarTrackDrawInfo, using ScrollbarInfo instead of HScrollbarInfo ( I need to retrieve ThumbREct in the srollbar).

Unfortunaly, this issue will never be fixed :-/

We forgot to ask about printing, but Philipp told me he had enough infos. I'll trust him :-)

Libellés : aqua, development

publié par ericb @ mercredi, juin 20, 2007