Apache OpenOffice Wiki - User contributions [en]

User:Ericb

2007-05-14T08:23:58Z

Plipli: /* Our Objectives at the WWDC 2007 */

==Public Documentation License Notice==

The contents of this Documentation (excepted Native Port Roadmap),are subject to the Public Documentation License Version 1.0 (the "License"); you may only use this Documentation if you comply with the terms of this License. A copy of the License is available at http://www.openoffice.org/licenses/PDL.html.
The Original Documentation is "Mac OS X native port". The Initial Writer of the Original Documentation is (JCA) Eric Bachard (C) 2005-2006. All Rights Reserved. (Initial Writer contact(s): ericb@openoffice.org.)

=='''Mac OS X Native port'''==

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">
'''The first Mac OS X native port objective is make OpenOffice.org run without X11 use, to make it a real Mac application.'''

'''The second one is respect Aqua Human interface Guidelines'''

''' This is a long term work, and every help and/or contributions, like donations** are welcome.'''
</div>

**see http://contributing.openoffice.org/index.html

=='''Native Port Roadmap'''==

==='''2006'''===

* June 2006: work in progress

- Basis: frame, instances, threads, drawing, painting, resizing (Stephan Schaefer, Tino Rachui)

Done:
implement threads
create, manage instance
create, manage windows (including parents)
create, manage events
create manage drawing, resizing
create, add menus (Pavel Janik)
toggle window fullscreen (Pierre de Filippis)
make font server work (Stephan Schaefer)

* Current status font support (Stephan Schaefer, 2006/07/28): the following features are basically working now
** font selection
** font size
** simple font attributes (bold, italic)

Next step: document first part, and propose design

- native filepicker (Pavel Janik, Florian Heckl)

- native printing implementation (Oliver?)

- native font implementation (Eric Bachard)

* September 2006:

- first proofs of concept: fonts, filepicker .. (more?)
- show the results (OOoCon 2006?)

==='''2007'''===

* January 2007: first alpha implementation

=='''Strategy for native port'''==

'''Possible Actions''':

Identify us:

#Complete the arrays below
#Update photos on frapr.com?

Share the work:

#Divide the work between little Teams
#Update Todo list regularly -> needs some love these days ... [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s]

Help:

#Teach tools between us
#Do a debug party on IRC
#write documentation

Meet us:

#IRC
#Mac Meeting (like nov2005 in Hamburg?)

Inform:

#Update website regularly
#Blogs

'''WHO''':

Mac Team:

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
|Developer \ skills || build || write code || code review || debug/trace (higher is better) || contribute to documentation ||
|-
|ericb|| x || x || || 1 || x ||
|-
|pjanik|| || || || || ||
|-
|ssa|| || || || || ||
|-
|maho|| || || || || ||
|-
|tinor|| || || || || ||
|-
|schmidtm|| || || || || ||
|-
|ebischoff|| || || || || ||
|-
|obr|| || || || || ||
|-
|cl|| || || || || ||
|-
|aliscafo|| || || || || ||
|-
|fheckl|| || || || || ||
|-
|Fridrich|| || || || || ||
|-
|plipli|| || x || || || x ||
|-
|}

'''Other resources''':

fonts: ?

events: ?

QA: James McKenzie leads QA for the Mac OS X port of OpenOffice.org and is looking for volunteers to spread this effort over several people and needs people from all over the world to test various languages.

graphical: ?

Communication: ?

'''WHAT''': Status of most important tasks

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
| Task || Names|| Urgency (1=higher)|| Work in Progress || Done || Code review || Debug || Integration ||
|-
|Get rid of X11||done || 1 || x || x || || || ||
|-
|Bundle|| || 1 || x || || || || | ||
|-
|Drawing|| || 1 || x || || || || || ||
|-
|Fonts||plipli || 1 || x || || || || || ||
|-
|Events management|| || 2 || x || || || || || ||
|-
|Controls (see list) ||ericb, aliscafo || 2 || x || || || || || ||
|-
|Native FilePicker||Florian Heckl, Pavel Janik || 3 || x || x || || || || ||
|-
|Native Printing||Yvan Barthelemy || 3 || x || || || || || ||
|-
|Native SpellChecker|| || 4 || || || || || || ||
|-
|Player||Mox Soini || 4 || x || || || || || ||
|}

Other tasks:

Help for writing bug lists, status of bugs ..etc

Write howto use gdb, leaks, other tools

'''WHEN''':

From Christian Lippka (last meeting, 25th of august 2006):
Aug 26 00:21:38 ChristianL
from my point of view what is missing for point 1:
text layout, complete font support, keyboard support,
fixing repaint issues, having aqua install and run out of the box

'''September 2006'''

Present the current state of the project at the 2006 OpenOffice conference in Lyon and Paris

'''Late 2006'''

fix OpenOffice.org launch
fix drawing (repainting)
Implement missing methods and fix most important bugs (mainly the one leading to crash) in:
ATS
Salgraphics
Salinstance

'''January or February 2007'''

make Java work (works partially)
make intensive debug
present something working as alpha

'''June 2007 '''

Implementation of:
native filepicker
native printing

== '''Become a Domain Developer for Mac OS X port''' ==

People regularly contributing to Mac OS x port with regular and quality patches are, after proposal, invited to become a [[DomainDeveloper]].

The purpose of this document is to clearly define all the steps to become a [[DomainDeveloper]].

Preliminary : step 1 in [[Commit_Rights]] must be completed and checked, and you must be in the list of [[http://www.openoffice.org/FAQs/faq-licensing.html#jca1 JCA Licensed people]]

=== Steps for ssh2 key to be uploaded ===

==== Create the key ====

Everything is described here : [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

==== Upload the key ====

You must create an issue, like described below :

'''Assign it to "ssh2key" in the "www" component'''

Sub Component : openoffice.org cvs

Title : CVS Commit access request

Add louis ( Louis Suarez Potts) or st ( Stefan Taxhet ) on CC

Upload your ssh2 public key respecting the process ( Attach a DSA key, not an RSA )

A project lead will confirm your request

Then the support will upload your key

Once done the issue is set to Fixed , and the next step has to be verified before '''you''' close it.

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75291 Upload SSH2 Key for Etsushi Kato]]

==== Verify it works ====

You now can try to connect via tunnel, and follow instructions given [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

If something goes wrong, ask for help to support, with a maximum of details, to solve the problem.

Once it works, the issue can be closed, and you can e.g. test downloading a module from tunnel repository :

First create a tunnel with the command:
<pre>
ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org
</pre>

Then in a new window:

<pre>
export CVSROOT=":pserver:your_login@localhost:/cvs"

cvs login ( enter )

(your password )

mkdir TEST

cd TEST

cvs -z4 co -r SRC680_m205 vcl

cd vcl

cat CVS/Root -> should indicate : your local repository
</pre>

=== Ask for CVS access for all modules required ===

Two steps : create an issue is mandatory because the concerned project is tools, and because people can have only ssh2 key without being [[DomainDeveloper]].

==== Create an issue ====

You must create an issue, described below :

Component : tools

Sub Component : www

Title : CVS access to all modules required

Assigned to mh + CC for ericb and/or pjanik

Present yourself quickly, and ask the access

A project lead will confirm

An admin will confirm this is ok, and set the issue to Fixed

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75494 CVS Access all modules for Etsushi Kato]]

==== Verify ====

Create the tunnel :

open a terminal and type :

ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org

once logged in, open a new terminal, and do ( for example ):
<pre>
cd $OOO_SRC_ROOT/

source MacOSXPPCEnv.Set.sh { source MacOSXX86Env.Set.sh for Mac Intel }

cd vcl ( for example )

IMPORTANT : be sure vcl has been checked from tunnel, not from anoncvs ( cat CVS/Root will give you the answer )

export CWS_WORK_STAMP=aquavcl01 # Only needed for working with [[EIS]], can change for a different CWS ;)

cd aqua/source/gdi

add your changes to your_file.cxx, then commit :

cvs commit -m "#i75689# bla bla ... the reason of the modification(s)" your_file.cxx # The #i75689# is an issue number in the tracker

cvs update

If nothing is wrong, cvs update should not return M for your_file.cxx, means the commit is successfull.
</pre>
In case of problem, use the issue until it is fixed

<big>'''Welcome aboard :)'''</big>

== '''Mac OS X porter Team at WWDC 2007''' ==

=== What is WWDC 2007 ? ===

See [http://developer.apple.com/wwdc/ Apple WWDC 2007]

====Labs Agenda====

It is extremely important to organize us for Labs.

The rule is extremely simple : bring your laptop, your code, and ask :)

{| border="1" cellpadding="10"
| Days
|monday<br>June 11
|tuesday<br>June 12
|wednesday<br>June 13
|thursday<br>June 14
|friday <br>June 15
|-
|Labs
|<br>Afternoon
|Morning<br>Afternoon
|Morning<br>Afternoon
|Morning<br>Afternoon
|Morning<br>Afternoon
|}

===='''Interesting Labs'''====

The complete list : [http://developer.apple.com/wwdc/tracks/macosx.html Mac OS X Essentials]

*Core Text Lab
Receive one-on-one technical assistance and troubleshooting advice from the Core Text engineering team. Learn how to use the advanced font handling and blazingly fast Unicode layout capabilities of Core Text. Bring your laptop, your code, and your questions.

*HIToolbox Lab
Work on tuning and debugging HIToolbox code in your Carbon application. Receive one-on-one technical assistance and troubleshooting advice from the High Level Toolbox engineering team, Apple DTS engineers, and technology evangelists. Bring your laptop, your code, and your questions.

=== Our Objectives at the WWDC 2007 ===

'''1) Connection OOo Mac team / Apple engineers'''

-Goal 1.1 : "Get infos, contacts, human to human conversation :-)"

-> Present our current work, methods and team to Apple people :

-> Meet them during WWDC : give us/them a face, keep contacts

-> Get their impression about what we have already done and what is still ToDo

'''2) Improve from Apple's engineers expertise'''

-Goal 2.1 : "Give MacOS X users the OOo suite they deserve"

=> As mac platform and apple's product fans, we are proud to bring the quality and power of OOo to mac users community

=> Make OOo uses all the power of Mac OSX, including upcoming Leopard !

-Goal 2.2 : "OO.org Mac port has to be as Apple HIG compliant as possible"

=> Define what is expected for User Interface of OpenOffice.org suite with people from Apple UI project

- FYI : Last year, Apple UI project proposed ericb to help us, once our native menus will be working.
This is now done.

'''3) Get code guidelines, tips, samples'''

-Goal 3.1 : "Ask for code review and find code snippets"

- HIView
- Printing
- Drag and Drop
- as muc has possible

=> More than 1000 Apple engineers are present, and can answer our questions regarding the code, during the whole week

-Goal 3.2 : "Attend key Labs and Sessions to get full overview of Tiger/Leopard/Core's and useful code"

- Core*
- Tiger / Leopard

'''4) Social Contacts / Team emulation'''

-> Discuss and meet new developers and / or american people working for Mac OS X port (like Michael Sicotte, Vijay Venkatraman , other.. )
-> Share ideas, tips, conviviality !

'''5) Visibility'''

OpenOffice.org Native Mac port has to be recognized as the professionnal office suite for Mac users it is !

=== Who ? ===

* Sébastien Plisson
* Eric Bachard

=== Todo list ===

Please add topics, technical questions you would see asked by attendees to Apple engineers during WWDC

====Suggestions for current issues to be fixed ====

Timers : Current code is obsolete, and compatibility with Leopard won't probably exist. Pavel wrote a patch using recent code. Seems to work fine, excepted a thread issue ( crash not easy to be reproduced )

Salframe :

Looot of things :

*Find infos/code sample about parenting

*Code review for HIFrameWork implementation

*Menus : every window creates it's own menu. Redesign it ?

*adapt native widget framework

Events : code review, tips

ATS : code review, ATS issues

Mike Sicotte:
I understood that implementing printing in aqua OOo was a topic that we didn't get accepted into Google SOC - so remains on the ToDo list. I notice that there are three Sessions specfically related to printing at WWDC:
Leveraging the Common Unix Printing System (CUPS)
Printing with Style in Mac OS X
Printing Lab
If this is judged to be a good use of time at WWDC I would be willing to spend some time to help further develop the questions to be addressed with the Apple engineers.

ericb->Mike Sicotte

Good idea. You are welcome :)

==== Travel ====

*describe the schedule of the travel

ericb :
<pre>
Mulhouse -> Paris -> SF : 9th of June SF scheduled arrival : 7:13 pm
SF -> Paris -> Mulhouse : 16th of June ( arrival 17th ) SF departure for the return : 3:00 pm

Hotel : King Georges ( close to Union Square )

Airport to Hotel transportation : not included
</pre>

sebastien (aka plipli) :
<pre>
Paris->SF : 3rd June
SF->Paris : 15th June in the evening

Hotel : to be coompleted
</pre>

==== Misc ====

*don't forget sector adaptator for laptop : US connectors are '''different'''

*don't forget Cameras ( and chargers)

*Prepare 50 to 100 business cards : the most simple is to use the model I can provide on demand , and print them with special paper ( pre-cut )

== '''Mac OS X porter Team at OOoCon 2007''' ==

=== Who ? ===

* Shaun McDonald
* Eric Bachard
* (list to be completed)

=== What ? ===

The conference is over 3 days. Presentations should last around 45 minutes. http://www.openoffice.org/servlets/ReadMsg?list=announce&msgNo=320 Papers have to be submitted by 1st June to be considered.

Ideas :

Mike Sicotte: Perhaps the results of the Google SOC could be a presentation.

*create a complete topic for Mac port (one stream for a day or half day)
*How to improve ooo usability though the use of floating palettes instead of modal dialogs

- several presentations / BOF

Eric Bachard : Aqua OpenOffice.org ( conf / 1 hour )

Others ?

*reserve rooms together ? Better rent a house?

* [FIXME]

=='''2nd Mac porters meeting'''==

This section has been moved to [[2nd Mac porters meeting]]

=='''IRC Mac port meetings'''==

This section has been moved to [[MacOSXPortMeetings]].

== '''Mac OS X (X11) Quality Assurance'''==

This section has been moved to [[Mac OS X ( X11) Quality Assurance]]

== '''Mac OS X Implementing HIView and Carbon events'''==

This section has been moved to [[Mac OS X Implementing HIView ]]

== '''Debug OpenOffice.org using XCode '''==

[[ MacOSX Debug OpenOffice.org using XCode]]

=='''Description of the Native Port problem'''==

=== How does OpenOffice.org work on Mac OS X? ===

Currently, on Mac OS X, OpenOffice.org uses X11, as "client": X11 is a graphical server, coming from Unix world, and able to run under Linux, *BSD, Solaris, Mac OS X.

- X11 is run as an application, managed like other Apple applications.
- All unix like applications are managed by X11, and from Aqua environment, only X11 is seen as only one applicatiion,
even if other Unix/Linux (e.g.) applications are runing.

OpenOffice.org asks X11 to display a window, waits for X11 acknowledgment, and OpenOffice.org displays the window. All transactions use the network, locally or not. the same mechanism is used for everything to be displayed.

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=== Issues and known problems ===

All events are managed by OpenOffice.org and X11, using the Xlib

Only .ttf fonts type is currently available. Note: '''system fonts are available '''

The rendering is made by X11, not by Mac OS X rendering engine.

X11 and all its clients are seen as one application only: drag and drop protocol does not work because of that (solution: Pasteboard Manager)

==== Other links ====

http://wiki.services.openoffice.org/wiki/List_of_OpenOffice.org_Mac_OS_X_issues_and_problems#

http://wiki.services.openoffice.org/wiki/Printing_problems_with_OpenOffice.org_2.0_for_Mac_OS_X#Reporting_printing_problems

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

== What do we have to do?==

* (in progress) : Implement direct access to Apple graphical engine, using Apple API: Quartz2D/CoreGraphics (and replacing Xlib use)

like: instantiate, manage events and threads for a graphical instance + all needed objects, drawing: manage all drawing cases

* (in progress) : Implement native events management, using CarbonEventManager (replacing Xlib management)

* (in progress) : Implement native font use, using Apple Type Server and ATSUI (for Unicode Imagery) (replacing X11 management)

Work in progress: [[Mac OS X Porting - Native Fonts]]

* Implement native sound, using QuickTime (replacing Java Media Framework): [[Mac OS X Porting - Native Audio and Video]]

* Implement native Drag and drop, Implementing Pasteboard Manager: [[Mac OS X Porting - Native Drag and drop]]

* (done experimental) Implement Native Filepicker

* Implement Native Printing: current uses cups, but native printing is mandatory: [[Mac OS X Porting - Native_Printing]]

* Implement Apple Spellchecker

--[[User:Plipli|Plipli]] 09:27, 25 March 2007 (CEST)

=='''Where is located the code to be modified?'''==

Most of the changes are located in vcl (Visual Class Layer), for everything graphical, events, fonts, rendering and printing.

Other, for sound and movies will be in avmedia (where the player is implemented in OpenOffice.org sources).

For drag and drop, dtrans is concerned (Pasteboard Manager implementation)

[FIXME]: Filepicker? Apple Spellchecker?

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=='''How will the new implementation be tested?==

Currently, all openOffice.org code can be compiled without using the Xlib. but of course, a lot of features are missing,

and the final package simply won't work

In vcl module", a '''toy''' called svdem is built at buildtime. This binary is linked to libvcl* and so all new stuff can be tested.

e.g. : draw anti-aliased lines works well.

Everything implemented in aqua vcl code will be included in libvclplug_aqua, and svdem source code will contain a specific part to proceed tests.

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">

'''The magic is: when all needed features will work with svdem, it will work in the new version of OpenOffice.org !!'''

</div>

[FIXME]: add more complete list of features to implement and test.

== AquaVCL 01 cws ==

[[http://qa.openoffice.org/issues/buglist.cgi?keywords=aqua Top 10 of Aqua issues]]

[[Aquavcl01 tasks]]

===Changelog ===

====Work in progresss : alpha 0.7 ====

Sun decided to officialy supports the Mac OS x port ( 3rd May )

Welcome to Philipp Lohmann and Herbert Duerr , who joined the Team ( 3rd May )

resync m211 ( 1st May )

[Top 10 of issues] modify Bundle tree (issue 73693) : change committed 28th April ( ericb)

Google SoC : welcome to Ismael Merzaq and Omer BarOr , our two selected candidates : ismael will work on aqua look ( NWF), and Omer will work on Mac OS X Address Book Integration.

resync : m208 ( 11th April )

(exp / not commited ) Ismael proposed a patch for Utility Windows more Aqua compliant + SetMin/MaxSize() ( 9th April )

Native menus are defaults (ericb) ( 8th April )

Frederic Barbaise (alias boulifb) joined the port ( 3rd April )

Work on saltimer.cxx started mikesic ( 27th March )

Pavel commited Michael patch for invert and drawAlphaRect() (27th March )

Started 27th March

==== alpha 0.6 ====

Damien started to work on drawEPS()

plipli and ericb work on refresh

Michael Sicotte proposed to investigate in timers, and continue [[http://www.openoffice.org/issues/show_bug.cgi?id=75228 Pavel's work]] : objective is to replace obsolete code. ( 23th March)

[experimental] plipli proposed a patch for a new salframe implementation, using HIView + optionally compositing (21th March )

[commit scheduled] Michael Sicotte proposed a complete patch for invert() ( SAL_INVERT SAL_INVERT_50 and SAL_INVERT_TRACKFRAME ) (20th March )

Tino proposed to work on code cleanup in salatsuifontutils.cxx, removing obsolete code

ismael and michael work on invert() + drawAlphaRect()

Started (19th March ) :

==== alpha 0.5====

Top 10 Summary : 7 issues over 10 are fixed or very close to be :

'''time to code review, tracing, and search for memory leaks'''

[done] Unicode input in salframe ( ekato ) ( 19th March )

[experimental, works partially] beginning of HIView + HIComboxes works (text still missing) (ericb + plipli) ( 14th March )

[done] replace NewRgn() in salframe (ericb (11th March )

[experimental, but very interesting] Improved native windows ( ismael ) ( 7th March )

====alpha 0.4====

'''[Informative]''' build runs with Leopard 9A377a ( fheckl ) ( 7th March )

Refresh screen issues (plipli) (4th to 10th March )

'''[informative]''' plipli announced progress with refresh screen issues ( 28th February )

[experimental, not yet commited] Proxy configuration from system ( pjanik) ( 28th February )

[done] highlighted native button ( pjanik) ( 27th February )

Native File Picker works ( fheckl / pjanik ) ( 23th February )

====alpha 0.3====

Cursor does appear -> invert() + setting a setBlinkTime value in UpdateSettings() (pjanik /ericb )

[done] mirroring negative images (ismael) + DrawAlphaBitmap() + CreateWithMask()

pjanik patch for Focus Events

[done] scrolling works ( pjanik ) (17th February )

[done ] carret works ( plipli) (17th February )

[done] checkbuttons fix for checkmarks (ericb) ( 17th February )

'''[Informative]''' Pavel Janik propose to solve offScreen buffer using HIView ( 17th February )

[experimental, never commited] patch for macosxrc.txt use + UpdateSettings() use in salframe.cxx ( ericb ( 16th February )

Michael Sicotte joined the Team ( 15th February )

invert() : first try (ericb) ( 13th february )

====alpha 0.2====

[12th February 2007 ]

[done] calc does not start : bug identified by tino , first workaround (ericb) [[http://www.openoffice.org/issues/show_bug.cgi?id=73691 issue 73691]]

[done] bitmaps in native popup menus (ismael)

[done] replace obsolete code for HandleWindowPaintEvent(), newRgn() .. etc (ericb) (12th February)

correct salatslayout patch (plipli) ( 11th February)

'''[Informative]''' Michel Renon proposed a summary about his work on fonts issues

[patch] Pavel fixed several menu crashes (09th February )

'''[Informative]''' : Pavel posted a mail about several crashes origin

patch for radioboxes and checkboxes ( ericb ) (9th February)

first complete patch for salatslayout.cxx ( plipli) ( 9th February )

[done] most important crashes fixed ( pjanik) ( 09th february )

Modified baseline for 2.2. : Mac OS X10.4 -> Aqua will be 10.4 and 10.5 compatible only ( ericb)

first try with multi line sallayout (plipli ) ( 08th February )

Damien Duportal joined the Team ( 7th February )

[done] scrollbar changes (ericb ) ( 4th February )

====alpha 0.1====

create Top 10 of issues before alpha 3rd February 2007 : See : [[http://porting.openoffice.org/mac/news/2007/20070203toptenbeforealpha.html Top 10 of issues]]

[experimental, not commited] patch for TPT() implementation (ericb) ( 2nd February 2007 )

Pavel Janik proposed to implement TransformProcessType() ( 2nd February 2007 )

[not commited] implement UpdateSettings() (ericb)

Pavel Janik resynchronized aquavel01 cws with m202 ( 2nd February 2007 )

====alpha 0.03====

Michel Renon joined the Team (1st February )

[done] fix checkbuttons and radiobuttons issues: offsets, redrawing of the check marks ( ericb)

[done] fix scrollbar buttons (implement correct methods to retrieve dimensions)

[done] implement mapfiles for Mac OS X (Stephan Bergmann, Daniel Boelzle, Tino Rachui , Pavel Janik)

====alpha 0.02====

[done] modify libsalsystools.dylib to be correctly loaded with the bundle (ericb, + pjanik)

[done] add mouse drag events ( pjanik )

====alpha 0.01====

[done] add new feature for Aqua windows, to allow QuickTime player use( mox )

[done] replace obsolete code in salframe.cxx with (ericb)

[done] fix correct size for main window (GetOptimaWindowSize() ) (ericb)

[done] fix alpha channel in pixmaps (ismael)

====alpha 0.0====

[done] pushbutton where not correctly drawn (ericb)

[done] fix missing mouse events (pjanik)

[done] fix nRepeat in text entry (ssa)

2nd Mac porters Meeting

===Work in progress ===

URGENT :

Top of issues causing crashes : event issue when tips is enabled causes crashes ( well known window / handler / window desctructor / event loop bug )

Salatsuifontutils : replace old code, track leaks : tino

[done] Bitmaps : ( isma87)

[running] Crashes : (tino, pjanik, ericb, isma87, plipli )

[???] Drag and drop : (vijay)

[???] Printing (ybart)

Florian Heckl proposed a subject for Google Summer of Code about native printing

Drawing/ windowing ( plipli / ericb ) -> mainly refresh

[done] Implement cursor

[started] Native Controls (ericb)

[work in progress] partial multiline sallayout (plipli )

To do :

(started, Oliver) - modify the tree to make the bundle start without hack ( issue fixed during buildtime)

(started, Florian Heckl) verify Native FilePicker implementation ( works , tested in Hamburg )

[done] Ismael Merzaq) implement blit functions in salgdi ( important fix: probably apha version to be tested once done)

[done] Sebastien Plisson- update the missing functions list ( fonts ... ask hdu & cl

[started] ericb, Mox Soini, Sebastien Plisson, Tino Rachui, Pavel janik continue to replace obsolete code

fix crashes with menus (started : tino )

== '''Sort of documentation about VCL around Native Mac OS X port''' ==

Do we really need to understand how it works? ;-)

vcl content:

ls -laR | wc -l
1750

-> Uff 1750 files to analyse :-/

Our purpose is to describe the vcl organisation. The content of vcl is so important, that at the begining, the content will looks a bit confused. e.g. class names ..etc have nothing to do, only description with words and sense, but this will need some time before we can understand everything.

How analyse with more efficiency? After some months to anlalyse '''"horizontaly"''', it appears that list all the content of a directory is not the solution. Of course, we learned a lot, but we now have to complete with '''"orthogonal"''' method (compared to the previous one). The first method wasn't obviously not the good/best way to describe vcl.

[FIXME] a different approach (will ask confirmation to Philipp Lohman), could be a description of how it work in runtime. First define what an instance is, a frame, and what exactly is concerned by such "objects".

With that, we can write a list of different objects all using the same scheme: empty boxes (means pure virtual methods and classes in generic libvvcl), really implemented in the specific part, and finally, the API "encapsulated".

The most difficult is to see where the API is used. But for all the parts, this is the same.

Finally, '''what is important is the design of vcl'''. Which '''patterns''' are used? What are the dependencies, how works the stack for the events, how works the scheduler, the timers too is very important, even fundamental for Aqua implementation. Will have a look at gsl mailing list, and other resources. Probably everything is already (randomly) written somewhere.

=== VCL organisation ===

Thank's to Philipp Lohmann for this short, but precise description:

Basically vcl is divided in the system dependent and the system independent part. The interface between these two is mostly the Sal interface (every interface name Sal*: SalInstance, SalFrame, SalGraphics, SalPrinter, etc.).

SalInstance is a factory that can create all the other abstracted interfaces of the system dependent part. It also provides the main loop SalInstance::Yield()

SalFrame abstracts any kind of system window.

SalVirtualDevice abstracts an offscreen window (e.g. a Pixmap on X11)

SalPrinter and SalInfoPrinter abstract the system print queues where SalInfoPrinter is for querying and SalPrinter for actual printing.

SalGraphics is an interface produced by either SalFrame, SalVirtualDevice or SalPrinter which is used for actual drawing operations (text, bitmaps, vector graphics)

SalSound is for sound playing.

SalBitmap provides memory for bitmap graphics as well as methods converting this memory to a system handle (e.g. a Pixmap on X11).

SalOpenGL provides OpenGL functionality if available.

SalTimer is an interface for periodically triggering the event queue (to timer implementation).

SalI18NImeStatus handles how the status window of an Input Method Editor (IME) should display (this is mainly X11 specific).

SalSystem has some system specific methods that did not belong anywhere else:-)

Of all these there interfaces is at least one implementation per system (Windows, X11 or Mac). The Unix implementation also has a plugin concept to allow for integration of different native toolkits (currently gtk and Qt) which became necessary for the implementation of Native Widget Framework (NWF) to display controls like their normal desktop counterparts.

Basically the independent part (what is beneath vcl/source directory) has generic methods for drawing, window handling and stuff which it brings into a suitable form and then delegates to the system specific implementation (located beneath vcl/win for Windows and vcl/unx for the X11 platforms).

[[User:Ericb|Ericb]] 16:12, 1 July 2006 (CEST)

===Sub-directories description ===

==== '''Organisation of vcl directories''' ====

[[Image:aquavcl_organisation_complete_02.jpg]]

==== '''Directories in vcl. Short description''' ====

''' aqua ''': The name Aqua means Apple look and feel, and is well known as [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html Aqua Human Interface Guidelines]. This look and feel means Mac OS X. The work was begun by (probably) P. luby, Dan Williams Herbert Duerr (most of fonts stuff) and Ed Peterlin. Currently in ruin, this directory does contain a lot of ideas to investigate. The most important part of needed changes for native version (3.0) will be done inside aqua dir inc: does contain all vcl relative includes [PART1]

''' prj ''': Does contain build.lst and d.lst build.lst give us dependencies: probably a lot for vcl, build 98th module over ~148. Everything graphical depends in vcl.

''' qa ''' does contain all quality assurancy stuff

'''source''': the most important:-) This directory contains common sources for all architectures and OS. Mainly: Windows, Unix: Linux , Mac OS X (X11), Solaris, including generic, kde and gtk plugins, and Aqua (Mac OS X without X11, work currently in progress).

Depending on the OS and the architecture, binaries are built or not.

''' test ''': This directory does contain all the needed stuff for tests. As example, in qa/testdocuments, you'll find three documents (one writer, one calc and one impress) for tests purpose.
Other available tests are about memcheck and persistent window state.

''' unx ''': this directory does contain all unixes stuff. We have to understand what is inside to implement aqua port. For example, a lot of classes/strutures and objects use Xlib calls we have to replace with Carbon/Cocoa call (at least at first time) for Mac OS X native port.

''' win ''': Doing Mac OS X native port, I first believed this directory was not interesting for us, but I was wrong: OpenOffice.org roots are inside this directory, and a lot of comments and resources are inside. Mainly interesting if Carbon is used.

'''workben''': Does contain a toy called "svdem". svdem is a binary, used for new implementations. For example, actual aqua development uses svdem intensively, to verify all important properties we need:

- display a window first (al least ...:))

- close cleanly this window

- display a point

- trace a line

- trace an area

- superpose two areas doing some important graphical operations, (like xor),

- display a character

- display a menu.

- intercept events correctly.

[FIXME] add more tests

[[User:Ericb|Ericb]] 13:21, 3 June 2006 (CEST)

=='''Naming convention''' ==

* Class names start with upper case letters, to improve readability.

* Implemented Class names are derived from the virtual classes but can of course take arbitrary names.
To increase readability, it's recommended to closely follow the base class name.

* '''Impl prefix: means Implementation details'''. The concerned class or method or function is not used outside of this module, so no external code (or other libraries) can see it.

'''[[ Events types using Carbon API (Mac OS X): ]]''' A lot of events have to be managed in runtime. Here is a short description

- do not freeze because bad event loops

- event types implementation: currently, they are defined in vcl/aqua/inc/aquavclevents.hxx

Apart: exact sense of hedabu? -> [FIXME] as far as I understood it: it is like "copy" to deliver software into the solver, with extra magic. The header files for example are manipulated so paths need not be exact. "headabu" is supposed to disappear little by little.

== '''What do we have to build in vcl?'''==

Two libraries, corresponding ressources (localized) and a toy so called « svdem »

'''Common part''':

in grey on right. The result will be a non architecture dependant library, built in all cases: for instance, libvcl680mxi.dylib on Mac Intel.

'''Specific part " a plugin " ''':

Light yellow: aqua part will only concern Mac OS X (non X11) the name will probably be libvcl_aqua680mxi.dylib

As you can see, win means windows part, in blue

For Unix build (Linux, Solaris or current Mac OS X X11), in purple.

Result will be:

libvclplug_PLUGIN680mxi.DLLSUFFIX , where PLUGIN can be iether gen (generic) or gtk (using gtk+) or kde (using qt), and DLLSUFFIX can be either .so (linux) or .dylib (Mac OS X) ...etc (I'm not sure for other cases).

Example: libvcl680mxi.dylib and libvclplug_aqua680mxi.dylib

'''In runtime''', libvclplug_aqua will be linked to libvcl680. the first one will contain the real implementation (respecting the API, e.g. Carbon) while the generic libvcl will only contain pure virtual methods ...etc like "empty boxes".

=== Current Aqua content ===

A more complete description of aqua (Mac OS X / no X11 specific): [[Image:Vcl_aqua_organisation_02_tree.jpg]]

==EXISTING objects to build in aqua==

===Sal APP "everything application"===

[FIXME] add all objects descriptions

==== saldata ====

* '''Defined in plugin exclusively''' (i.e. for headers)

Unix: unx/source/app/saldata.cxx (header in unx/inc)

'''Aqua: aqua/source/app/saldata.cxx (header in win/inc)'''

Windows: win/source/app/saldata.cxx (header in aqua/inc)

* Role: saldata contains various kind of data used by the implementation for the concerned platform. '''It is a bunch of global data collections reserved for the platform'''

It is just completely platform dependent, and nobody except this plugin can see it.

'''Saldata is something like a "second sal", but providing an abstraction regarding windowing and graphics''', while SAL module provides an abstraction more Operating System oriented)

e.g. : have a look at XRequest array in vcl/unx/source/app/saldata.cxx => all calls are for Xlib (X11). Ok, useless there, but interesting:-)

[FIXME]: use Windows implementation could be a good starting point. Nothing is the same, but the current aquavcl cws uses similar objects, and it works very correctly.

saldatax.cxx uses classes SalInstance, SalObject, SalFrame, SalVirtualDevice, SalPrinter and fontList.

Current list of possible objects who can be instantiated/released:

structure SalData: does contain pointers on all kind of objects from other classes used in saldata.

inline functions: [FIXME]: complete the description

- SetSalData:
- GetSalData:
- GetAppSalData:

==== salinst ====

=> implemented in vcl/aqua/source/app/salinst.cxx

Role:

* get environment, mutexes, instantiate AquaSalInstance (Ctor, Dtor),

* instantiates/releases a lot of other objects using Get() / CreateObject() / DestroyObject() methods.

Current list of possible objects who can be instantiated/released:

* VirtualDevice [FIXME]: exact role?

*Printer

- GetDefaultPrinter/ CreatePrinter() / DestroyPrinter - what a name ;-) -

- InfoPrinter (Get/Create/Delete)

- PrinterQueue (DeletePrinterQueueInfo / GetPrinterQueueInfo / GetPrinterQueueState)

* System (Create / Delete) [FIXME]: what means system here?

* Events:

AquaSalInstance::SetEventCallback()

AquaSalInstance::SetErrorEvenCallback()

AquaSalInstance::GetConnectionIdentifier()

* Menu / MenuItem:

AquaSalInstance::CreateMenu() / same for DestroyMenu()

AquaSalInstance::CreateMenuItem / same DestroyMenuItem()

* Sound:

AquaSalInstance::CreateSalSound() => object to a pointer of SalSound type

Note: AquaSalInstance::DestroySalSound is not implemented (?)

* Timer: CreateTimer() /

AquaSalInstance:: DestroyTimer() is not yet implemented (?)

Class MacImeStatus: inherits of SalI18NImeStatus

-> only there to see if there is a window to toggle into menubar [FIXME]??

AquaSalInstance::CreateI18NImeStatus(): instantiates MacImeStatus

'''For futher informations, see: ''' '''[[Content of salinst.cxx]]'''

([[User:Ericb|Ericb]] 16:11, 20 May 2006 (CEST) )

==== salmain ====

Role: if possible, runs the standard vcl application code SVMain()

([[User:Ericb|Ericb]] 16:15, 20 May 2006 (CEST))

==== salsound ====

==== salsys ====

==== saltimer ====

==== saltimer ====

The main problem with SalTimer is the code we use is obsolete. To remove this deprecated code, sevarl work have been tried

1) Pavel Janik, in issue 75228

works, but a serious problem is remaining (a thread issue, nothing anybody explained yet)

2) eric bacahrd ( code will be attached soon )

3) Michael Sicotte, who proposed to work on that, and continue Pavel implementation.

SalTimer description

AquaSalTimerproc

AquaSalTimer::Start()

AquaSalTimer::Stop()

AquaSalTimer::Restart()

AquaSalTimer::Installtask() // yet needed ?

=== Sal GDI (everything Graphical Display Interface) ===

====salgdinativewidgets====

[[native controls]]

==== salatslayout ====

==> implemented in vcl/aqua/source/gdi/salatslayout.cxx

- Handle text layouting :

* Use ATSUI (ATSUCreateTextLayoutFromPtr) to layout the text unicode char buffer
* Use ATSUI (ATSU..) to get informations about glyphs
* Populate different arrays (mpGlyph2Chars, mpChars2Glyph, mpCharsWidths, mpGlyphAdvances)
that are used in various methods.

==== salatsuiutils ====

==== salfontutils ====

==== salmathutils ====

==== sal bmp ====

==== salvd ====

==== salpixmaputils====

==== salprn ====

====salrectangle====

==== salvd ====

=== Sal Window===

==== salframe ====
Documentation in progress, from damiend :
[[User:Damiend|Damiend page]]

====salobj====

== TO BE IMPLEMENTED (missing in Aqua)==

===Audio===

====audioconvert====
(obsolete?)

====devaudio====
(obsolete?)

====native sound====

====salimpsound====

====vsound====

===i18n===

===keysymnames===

===saldisp===

===sm===

[FIXME]: is session manager usefull?

=='''Native Controls'''==

====Scrollbar====

'''Works as expected'''. The most important work is done

See : [[Mac_OS_X_Porting_-_Native_Controls#ScrollBar]]

====DrawThemeButton() documentation====

'''Started'''

See : [[Mac_OS_X_Porting_-_Native_Controls#ComboBox]]

Started
<pre>
DrawThemeButton
Draws a button.

OSStatus DrawThemeButton (
const Rect * inBounds,
ThemeButtonKind inKind,
const ThemeButtonDrawInfo * inNewInfo,
const ThemeButtonDrawInfo * inPrevInfo,
ThemeEraseUPP inEraseProc,
ThemeButtonDrawUPP inLabelProc,
UInt32 inUserData
);
Parameters
inBounds
A pointer to a structure of type Rect. Pass a rectangle specifying the boundary of the button, in local coordinates.

inKind
A value of type ThemeButtonKind. Pass a constant specifying the type of button to draw.
See “Theme Buttons” for descriptions of possible values.

inNewInfo
A pointer to a structure of type ThemeButtonDrawInfo. Before calling DrawThemeButton,
set the structure to contain the new state, value, and adornment for the button.
DrawThemeButton uses the information passed in the inNewInfo and inPrevInfo parameters
to apply transitional animation or sound effects as the button state changes, if such are
specified under the current theme.

inPrevInfo
A pointer to a structure of type ThemeButtonDrawInfo. If the button state is changing,
set the structure to contain the previous state, value, and adornment for the button,
to allow DrawThemeButton to apply any transitional effects. If the button state is not
changing, you can pass NULL.

inEraseProc
A value of type ThemeEraseUPP. If you have a custom background, use this parameter to pass
a universal function pointer to an application-defined function such as that described in
ThemeEraseProcPtr. DrawThemeButton calls this function to erase the background before drawing
the button. If you pass NULL, DrawThemeButton's default behavior is to erase the background
for you.

inLabelProc
A value of type ThemeButtonDrawUPP. If you pass a universal function pointer to an
application-defined function such as that described in ThemeButtonDrawProcPtr, DrawThemeButton
calls that function to draw the label of the button. If you pass NULL, no label is drawn.

inUserData
An unsigned 32-bit integer. Provide any data to be passed in to the callback functions specified in
the inLabelProc and inEraseProc parameters. Pass NULL if you do not wish to provide any data.

Return Value
A result code. See “Appearance Manager Result Codes”.

Discussion
The DrawThemeButton function draws a theme-compliant button. If a ThemeEraseProcPtr is
specified in the inEraseProc parameter, DrawThemeButton uses that function to erase the
background of the button before drawing the button. After the button is drawn, if a
ThemeButtonDrawProcPtr is specified in the inLabelProc parameter, DrawThemeButton calls
that function to draw the button’s label.

Note that DrawThemeButton also draws any appearance adornments for the button and that these
can extend beyond the button’s basic bounding rectangle, as specified in the inBounds parameter,
and may be of variable shape. You may therefore wish to call the function
GetThemeButtonBackgroundBounds to obtain the actual rectangle containing the pixels belonging
to a button under the current theme.

Version Notes
This function is available with Appearance Manager 1.1 and later.

Availability
Available in CarbonLib 1.0 and later when Appearance 1.1 or later is present.
Available in Mac OS X 10.0 and later.
Declared In
Appearance.h
</pre>

====HIComboBoxCreate() documentation====

<pre>
HIComboBoxCreate
Creates a combo box control.

OSStatus HIComboBoxCreate (
const HIRect* boundsRect,
CFStringRef text,
const ControlFontStyleRec* style,
CFArrayRef list,
OptionBits inAttributes,
HIViewRef* outComboBox
);
Parameters
boundsRect
The bounding box of the control.

text
The default text in the editable portion of the control. Can be NULL.

style
The font style of the both editable text and the text in the disclosure list. Can be NULL.

list
The default values available in the disclosure list. Can be NULL.

inAttributes
The default attributes of the combo box. For possible values, see “Combo Box Attributes”.

outComboBox
On exit, a pointer to a reference for the new control.

Discussion
The combo box can be used in compositing mode, as well as traditional Control Manager mode.
When created, this view is invisible. To see the view, you must show the view by calling HIViewSetVisible.
</pre>

== What is used for Linux, Windows, Mac OS X ...build ? ==

'''[[Description of the dependencies]]'''

'''[[Windows]]'''

'''[[MacOS X]]'''

'''[[Linux]]'''

'''[[Solaris]]'''

== Content of Aqua ==

'''[[Click here to see the complete list]]'''

'''Content of vcl/inc'''

Notes:

1) Where to find includes

<foo/bar.hxx> means you can find bar.hxx in the foo module. The new style file is foo/inc/foo/bar.hxx, old style is foo/inc/bar.hxx and sometimes the file is somewhere else in the tree or generated. The deliver process copies/generates the file into solver at solver/680/build_type/inc/foo. Good for fixing broken builds. ;-)

2)
suffix .h (for C calls or first version?) or .hxx (C++)

'''A) Family of includes''':

Looking more closely at the list brings to the fore (expression from dictionary ;-) ) that include names are
informatives. Most of the time, the name gives the function/role.
What is interesting is the files with name begining with "sal". sal means System Abstraction Layer + include's function (or explicit name).

Partial list, for example:

salatype.hxx

salbmp.hxx

salctrlhandle.hxx

salctype.hxx

salframe.hxx

salgdi.hxx

salgeom.hxx

sallayout.hxx (main header for fonts services)
...
salmenu
salnativewidgets
...etc

Other important families are "sv" and "uno" or "win" (window) prefixed. sal family will be analysed apart.

'''B) Includes of includes'''

Some includes are more important than other. To prove this, just have a look is sufficient: some are always needed, and some more rarely.

To verify, a simple test to do in vcl/inc:

egrep -H "#include" ./* | wc -l gives me 681 lines ! And some of them are the same...

To know more, the precedent command line can be modified to make appear the numerous call
to the same includes files.

egrep -H "#include" ./* | cut -d"#" -f2 | sort > liste.txt

The content of liste.txt is explicit: dllapi.h, sv.h and some other are very important, while some other includes are only one or two times used. We can see too that vos includes are numerous, even if vos is deprecated**

**see http://wiki.services.openoffice.org/wiki/Source_code_directories

I'm nearly sure that a complete analysis of just this result will give us a lot of information.

I propose to change the order of analysis starting with dllapi.h and sv.h.

[to be continued]

'''B1) "sal" includes family'''

[[salinst.hxx]] This seems to be the main include file

[[salatype.hxx]]

[[salctrlhandle.hxx]]

[[salctype.hxx]]

[[salframe.hxx]]

[[salgdi.hxx]]

[[salgeom.hxx]]

'''[[ sallayout.hxx ]]''' <-- see Native Fonts implementation

[[salgtype.hxx]]

[[vcl/inc/salobj.hxx]]

'''B2) Classicals includes'''

file: abstdlg.hxx [ means abstract dialog ]

This includes does contain the following classes definitions:

[FIXME] : choose a precise presentation template for classes

VclAbstractDialog,

VclAbstractTerminateDialog,

VclAbstractRefreshableDialog,

VclAbstractDialogFactory,

uses <tools/solar.h> , <tools/string.hxx> +

"dllapi.h"

Note : dllapi.h is very interesting because when we have to find (for example) a library suffix, SAL_DLLEXTENSSION can replace all suffixes (every OS's and archs). Just including sal/config.h does it !

Classes:

Window -> what? [FIXME]
ResId -> what?

Does contain the prototype of VclAbstractDialog, inherit of VCL_DLLPUBLIC

file: dllapi.h [ dll for dynamic linked library ]
Uses: <sal/config.h> and >sal/types/h>
includes: VCL_DLLPUBLIC macro

file: accel.h [ means accelerator ]

Classes:

Accelerator
{
}
ImplAccelEntry
{
public members:

Names

mnId
maKeyCode
mpAccel
mpAutoAccel
mbEnabled
}

function / returns / parameters

ImplGetKeyCode / void / KeyFuncType eFunc, ref rCode1 , ref rCode2, ref rCode3

file: accel.hxx

Uses: <sv.h> , "dllapi.h" ,<tools/resid.hxx>, <<tools/rc.hxx>

Classes:

ImplAccelData;
ImplAccelEntry;

== Important Links ==
'''[[Progressive implementation]]'''

'''Native Font server Implementation''' '''[[Mac OS X Porting - Native Fonts]]'''

'''Native Sound Implementation''': [[Mac OS X Porting - Native Audio and Video]]

'''Native Printing Implementation''': [[Mac OS X Porting - Native_Printing]]

'''Drag and Drop implementation''': [[Mac OS X Porting - Native Drag and drop]]

'''Data Acquisition''' : [[Mac OS X Porting - Data Acquisition]]

This work is part of http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s

[to be continued:-) ]

== Keyboard comparizon between OpenOffice.org / Mac OS X application ==

[FIXME] redo a cleanest array

{| style="vertical-align:top; text-align:centered; background-color:#F0F0F0;"
|- style="background-color:#99CCFF; font-weight:bold;"
| Modifier||+ key || Result || TextEdit returns
|-
|ALT|| a||æ ||æ
|-
|ALT||b||ß ||ß
|-
|ALT||c||© ||©
|-
|ALT||d||∂ ||∂
|-
|ALT||e||ê ||ê
|-
|ALT||f||ƒ ||ƒ
|-
|ALT||g ||ﬁ ||ﬁ
|-
|ALT||h ||Ì ||Ì
|-
|ALT||i ||î ||î
|-
|ALT||j ||Ï ||Ï
|-
|ALT||k ||È ||È
|-
|ALT||l ||¬ ||¬
|-
|ALT||m ||µ ||µ
|-
|ALT||n ||~ ||~
|-
|ALT||o ||œ ||œ
|-
|ALT||p ||π ||π
|-
|ALT||q ||‡ ||‡
|-
|ALT||r ||® ||®
|-
|ALT||s ||Ò ||Ò
|-
|ALT||t ||† ||†
|-
|ALT||u ||º ||º
|-
|ALT||v ||◊ ||◊
|-
|ALT||w ||‹ ||‹
|-
|ALT||x ||≈ ||≈
|-
|ALT||y ||Ú ||Ú
|-
|ALT||z ||Â ||Â
|-
|ALT||A ||Æ ||Æ
|-
|ALT||B ||∫ ||∫
|-
|ALT||C ||¢ ||¢
|-
|ALT||D||∆||∆
|-
|ALT||F ||· ||·
|-
|ALT||G ||ﬂ ||ﬂ
|-
|ALT||H ||Î ||Î
|-
|ALT||I ||Î ||Î
|-
|ALT||J ||Í ||Í
|-
|ALT||K ||Ë ||Ë
|-
|ALT||L || <pre>|</pre> ||<pre>|</pre>
|-
|ALT||M ||Ó ||Ó
|-
|ALT||N ||ı ||ı
|-
|ALT||O ||Œ ||Œ
|-
|ALT||P ||∏ ||∏
|-
|ALT||Q ||Ω ||Ω
|-
|ALT||R ||‚ ||‚
|-
|ALT||S ||∑ ||∑
|-
|ALT||T ||™ ||™
|-
|ALT||U ||ª ||ª
|-
|ALT||V ||√ ||√
|-
|ALT||W ||› ||›
|-
|ALT||X ||⁄ ||⁄
|-
|ALT||Y ||Ÿ ||Ÿ
|-
|ALT||Z ||Å ||Å
|-
|ALT||$ ||€ ||€
|-
|ALT||` ||@ ||@
|-
|ALT||£ ||# ||#
|-
|ALT||* ||¥ ||¥
|}

Sous réserve d'erreur ou omission [[User:Ericb|Ericb]] 00:05, 14 January 2007 (CET)

--[[User:Ericb|Ericb]] 15:00, 22 Jul 2005 (EDT)

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

User:PliPli

2007-05-08T10:09:58Z

Plipli:

== Developer Infos ==

Name: Sebastien PLISSON

IRC Nickname: plipli

blog: [http://splisson.blogspot.com splisson at OOo]

User:Ismael

2007-05-08T10:08:29Z

Plipli:

== Developper infos ==

Name: Ismael MERZAQ

IRC Nickname: Ismael_

blog: [http://lebasket.free.fr/blog http://lebasket.free.fr/blog]

== Current work ==

I have implemented key accelerators in native menus (like Cmd+N for new document instead of ctrl+N in the X11 version). This was my first contribution to native port and also to OOo.
I also worked on graphics for the native port: i have corrected a bug on image mask to have correct images in the menu, I implemented functions in AquaSalGraphic too (drawAlphaImage() for example).
After graphic functions, i worked on improving native windows and dialogs, and implementing missing functions of salframe.cxx (in vcl/aqua/source/window).

I will also continue the implementation of native controls for the Google Summer of Code 2007.

== Introduction ==

The purpose of this page is to be a place for documentations on my work to help people who would continue my work or use it, or simply want to understand what i do.
And, moreover, writing documentation is an important part of coding.

== Apple Documentation and References ==

Apple Carbon/Quartz reference
*about menus: [http://developer.apple.com/documentation/Carbon/Reference/Menu_Manager/index.html]
*about images (CGImage): [http://developer.apple.com/documentation/GraphicsImaging/Reference/CGImage/index.html]
*about graphic contexts (CGContexts): [http://developer.apple.com/documentation/GraphicsImaging/Reference/CGContext/index.html]

== Native windows ==

see [[Mac_OS_X_Porting_salframe]]

== Image masks ==

=== Short intro ===

As i explained it on my blog, i have continued the work Pavel Janick did on image masks. At the beginning, my work was to correct a bug concerning images in menus. I firstly thought i would have to concentrate on AquaSalMenu::SetItemImage but the problem wasn't on this function. So my work mainly concerned AquaSalBitmap::CreateMask and AquaSalBitmap::CreateWithMask functions (both located in vcl/aqua/source/gdi/salbmp.cxx). The problem came from the CreateMask function which didn't work as expected. Indeed, it created a mask with random values and so images in the menus had some pixels transparent and some others not, making the image not looking as it should.
[[Image:AquaImageMenuBug.png]]

In the CreateMask function, the image mask is created from a RawMemorySharedArray (defined in the basebmp namespace, see in bitmapdevice.hxx. The RawMemorySharedArray uses the boost library (typedef boost::shared_array< sal_uInt8 > RawMemorySharedArray;)). Depending on the number of bits per component (colors+alpha), pixels have different values which are added to a RawMemorySharedArray. Then a CGDataprovider is created with the data of the RawMemorySharedArray (CGDataProviderRef xDataProvider( CGDataProviderCreateWithData(NULL, aMaskBuffer.get(), nHeight * nWidth, NULL) ); where aMaskBuffer is defined as basebmp::RawMemorySharedArray aMaskBuffer( new sal_uInt8[ nWidth * nHeight ] );). And finally, the image mask is created from this CGDataProvider (xMask = CGImageMaskCreate(nWidth, nHeight, 8, 8, nWidth, xDataProvider, NULL, true );).

[[Image:imageAndMasks.png]]

''Image and its mask (seen in Icon Composer)''

=== The possible causes of the bug ===

So the problem may come from the RawMemorySharedArray, it may also come from the creation of the CGDataProvider from it, or from the creation of the imagemask from the cgdataprovider. What is sure is that the problem comes from the CreateMask function in salbmp.cxx, but i haven't been able to fix it. So i decided to do it by another way.

=== So, how did i do? ===

Instead of creating an image mask from the alpha of the original image, i created a CGImage from the alpha mask (passed as argument of the function as an AquaSalBitmap&), and i masked the original image with it, using context.

Here's the part of code which masks the image:
<pre>CGContextSaveGState(mxGraphicContext);

CGContextBeginTransparencyLayer(mxGraphicContext, NULL);
CGContextClipToMask(mxGraphicContext, CGRectMake( nX, nY, nDX, nDY), xMask);
CGContextDrawImage(mxGraphicContext, CGRectMake( nX, nY, nDX, nDY), xImage );
xMaskedImage=CGBitmapContextCreateImage(mxGraphicContext);
CGContextEndTransparencyLayer(mxGraphicContext);

CGContextRestoreGState(mxGraphicContext);
</pre>
We firstly save the context. Then we call CGContextBeginTransparencyLayer(mxGraphicContext, NULL) to have transparency else the transparent regions are black. Then we use the function CGContextClipToMask(mxGraphicContext, CGRectMake( nX, nY, nDX, nDY), xMask). Here's what the [http://developer.apple.com/documentation/GraphicsImaging/Reference/CGContext/Reference/reference.html#//apple_ref/c/func/CGContextClipToMask AppleDoc] says about it:
<pre>CGContextClipToMask
Maps a mask into the specified rectangle and intersects it with the current clipping
area of the graphics context.

void CGContextClipToMask(
CGContextRef c,
CGRect rect,
CGImageRef mask
);
[...]
mask
An image or an image mask.
[...]
Discussion
If the mask parameter is an image mask, then Quartz clips in a manner identical to the
behavior seen with the function CGContextDrawImage—the mask indicates an area to be left
unchanged when drawing. The source samples of the image mask determine which points of
the clipping area are changed, acting as an "inverse alpha" value. If the value of a source
sample in the image mask is S, then the corresponding point in the current clipping area is
multiplied by an alpha value of (1–S). For example, if S is 1 then the point in the clipping
area becomes transparent. If S is 0, the point in the clipping area is unchanged.
</pre>
Then we draw the image on the context (which has been masked) with CGContextDrawImage(mxGraphicContext, CGRectMake( nX, nY, nDX, nDY), xImage ). And we create the CGImage from this context with xMaskedImage=CGBitmapContextCreateImage(mxGraphicContext). Finally we restore the context (CGContextRestoreGState(mxGraphicContext);)

But this is not enough. Indeed, in the function CGContextClipToMask, the mask is a CGImage not the AquaSalBitmap of the arguments (CGImageRef AquaSalBitmap::CreateWithMask( const AquaSalBitmap& rMask, sal_uInt32 nX, sal_uInt32 nY, sal_uInt32 nDX, sal_uInt32 nDY )). So we have to transform the AquaSalBitmap rMask in CGImage. This is done thanks to the CreateCroppedImage function (CGImageRef AquaSalBitmap::CreateCroppedImage( int nX, int nY, int nWidth, int nHeight);) But the AquaSalBitmap rMask can't be a const, so we have 2 possibilities: remove the const in the declaration of the function, or copy the aquasalbitmap. The first solution can't be used because salgdi.cxx and other files need to have it defined with the const mask. So i used the second solution: copying the AquaSalBitmap (rMaskNew.Create( rMask ) creates a copy of rMask).

But there was still a problem.
The image mask should be inverted, i.e. the black pixels should become white and the white pixels should become black.

[[Image:AquaMenuImagesWithNotInvertedMask.jpg]]

''Without inverting the mask, the parts which should be painted are transparent and those which should be transparent are painted.''

So i looked for a function to do that in the OOo API. The AquaSalGraphics class provide one but it is not yet implemented. And as its implementation is, in my opinion, difficult and need some time, i didn't implement it yet and so I inverted the image mask using contexts in the function which need it. Instead of inverting the AquaSalBitmap with the OOo API, i inverted the CGImage with the Quartz API. But this solution should stay a temporary solution and, in my opinion, should be replaced as soon as possible by the one using OOo API, mainly for the clarity of code.
Here's the code which invert the image thanks to context:
<pre>
rMaskNew.CreateContext();
CGContextTranslateCTM (rMaskNew.mxGraphicContext, 0, mnHeight);
CGContextScaleCTM (rMaskNew.mxGraphicContext, 1.0, -1.0);
CGContextSetGrayFillColor(rMaskNew.mxGraphicContext, 1.0, 1.0);
CGContextFillRect(rMaskNew.mxGraphicContext, CGRectMake( nX, nY, nDX, nDY));
CGContextSetBlendMode(rMaskNew.mxGraphicContext, kCGBlendModeDifference);
CGContextDrawImage(rMaskNew.mxGraphicContext, CGRectMake( nX, nY, nDX, nDY), xMask);
xMask=CGBitmapContextCreateImage(rMaskNew.mxGraphicContext);
</pre>

== Key accelerators ==

=== Short introduction: presenting the basis ===

The function which interests us is <pre>void AquaSalMenu::SetAccelerator( unsigned nPos, SalMenuItem* pSalMenuItem, const KeyCode& rKeyCode, const XubString& rKeyName ) </pre>

* nPos is the menu item index, but nPos is 0 to n based whereas the carbon API we use for ooo macport is from 1 to n+1 e.g. for the first element nPos=0, and his carbon index will be 1

*SalMenuItem* pSalMenuItem is a pointer to the menu item we want to add key accelerator

*const KeyCode& rKeyCode is the keycode of the accelerator. We can get the keycode with ''rKeyCode.GetCode()'' and the key modifier(s) (like cmd, shift, ... for Mac OS) with ''rKeyCode.GetAllModifier()''

*const XubString& rKeyName is not used for the MacOs port

=== Implementation ===

We will use the ''SetMenuItemModifiers'' function to chose the modifier(s) of the key accelerator like cmd, shift, alt... and we'll set the key accelerator with two different function depending of the situation: the ''SetMenuItemCommandKey'' function for visible key accelerator (like for the N of Cmd+N) and the ''SetMenuItemKeyGlyph'' function for non visible characters (like for F1, F2,... or space).

=== Setting the key accelerator ===
The difficulty is that the OOo keycodes are different of the ASCII keycodes used in Carbon.
For example: A is 65 in ASCII but in OOo it's 512 (defined in Key.hdl)
So we have to translate from ooo codes to ascii, but the order of the characters are not exactly the same as ASCII so we translate only by intervals. We obtain this code:
<pre>
if ((ncode>=KEY_A) && (ncode<=KEY_Z)) {
nresultcode=ncode-KEY_A+'A';
}
else if ((ncode>=KEY_0) && (ncode<=KEY_9)) {
nresultcode=ncode-KEY_0+'0';
}
</pre>

We do the same thing for non visible characters but instead of using the ascii code of the given character we use its carbon value.
<pre>
else if((ncode>=KEY_F1) && (ncode<=KEY_F12)) {
nresultcode=kMenuF1Glyph+ncode-KEY_F1; // kMenuFnGlyph=kMenuF1Glyph+n only for n<13 then it should be processed for each case
}
else if((ncode>=KEY_F13) && (ncode<=KEY_F15)) {
nresultcode=kMenuF13Glyph+ncode-KEY_F13; //kMenuF13Glyph=0x87 and kMenuF12Glyph=0x7A
}
else if(ncode==KEY_SPACE) {
nresultcode=kMenuSpaceGlyph;
}
</pre>

Then we only have to add the accelator to the menu:
*For the non visible characters: The syntax of ''SetMenuItemKeyGlyph'' is:
<pre>
OSErr SetMenuItemKeyGlyph (
MenuRef inMenu,
SInt16 inItem,
SInt16 inGlyph
);
</pre>

so we use it like this:
<pre>
SetMenuItemKeyGlyph (
mrMenuRef, //is the reference to the menu
nPos+1, // for the reason of using nPos+1 instead of nPos see the short intro
nresultcode
);
</pre>

*For visible characters: The syntax of ''SetMenuItemCommandKey'' is:
<pre>
OSStatus SetMenuItemCommandKey (
MenuRef inMenu,
MenuItemIndex inItem,
Boolean inSetVirtualKey,
UInt16 inKey
);
</pre>

so we use it like this:
<pre>
SetMenuItemCommandKey (
mrMenuRef,
nPos+1,
0,
nresultcode
);
</pre>

=== Key accelerators definitions in OpenOffice.org for MacOS X ===

See [[Mac OS X Porting - Keyboard Shortcuts]].

--[[User:Ismael|Ismael]] 16:43, 19 April 2007 (CEST)

[[Category:MacOSX]]
[[Category:Porting]]
[[Category:Aqua]]

User:PliPli

2007-05-08T10:06:05Z

Plipli:

== Developer Infos ==

Name: Sebastien PLISSON

IRC Nickname: plipli

blog: [http://splisson.blogspot.com]

User:Ismael

2007-05-08T10:05:30Z

Plipli: /* Developper infos */

== Developper infos ==

Name: Ismael MERZAQ

IRC Nickname: Ismael_

blog: [http://splisson.blogspot.com/]

== Current work ==

I have implemented key accelerators in native menus (like Cmd+N for new document instead of ctrl+N in the X11 version). This was my first contribution to native port and also to OOo.
I also worked on graphics for the native port: i have corrected a bug on image mask to have correct images in the menu, I implemented functions in AquaSalGraphic too (drawAlphaImage() for example).
After graphic functions, i worked on improving native windows and dialogs, and implementing missing functions of salframe.cxx (in vcl/aqua/source/window).

I will also continue the implementation of native controls for the Google Summer of Code 2007.

== Introduction ==

The purpose of this page is to be a place for documentations on my work to help people who would continue my work or use it, or simply want to understand what i do.
And, moreover, writing documentation is an important part of coding.

== Apple Documentation and References ==

Apple Carbon/Quartz reference
*about menus: [http://developer.apple.com/documentation/Carbon/Reference/Menu_Manager/index.html]
*about images (CGImage): [http://developer.apple.com/documentation/GraphicsImaging/Reference/CGImage/index.html]
*about graphic contexts (CGContexts): [http://developer.apple.com/documentation/GraphicsImaging/Reference/CGContext/index.html]

== Native windows ==

see [[Mac_OS_X_Porting_salframe]]

== Image masks ==

=== Short intro ===

As i explained it on my blog, i have continued the work Pavel Janick did on image masks. At the beginning, my work was to correct a bug concerning images in menus. I firstly thought i would have to concentrate on AquaSalMenu::SetItemImage but the problem wasn't on this function. So my work mainly concerned AquaSalBitmap::CreateMask and AquaSalBitmap::CreateWithMask functions (both located in vcl/aqua/source/gdi/salbmp.cxx). The problem came from the CreateMask function which didn't work as expected. Indeed, it created a mask with random values and so images in the menus had some pixels transparent and some others not, making the image not looking as it should.
[[Image:AquaImageMenuBug.png]]

In the CreateMask function, the image mask is created from a RawMemorySharedArray (defined in the basebmp namespace, see in bitmapdevice.hxx. The RawMemorySharedArray uses the boost library (typedef boost::shared_array< sal_uInt8 > RawMemorySharedArray;)). Depending on the number of bits per component (colors+alpha), pixels have different values which are added to a RawMemorySharedArray. Then a CGDataprovider is created with the data of the RawMemorySharedArray (CGDataProviderRef xDataProvider( CGDataProviderCreateWithData(NULL, aMaskBuffer.get(), nHeight * nWidth, NULL) ); where aMaskBuffer is defined as basebmp::RawMemorySharedArray aMaskBuffer( new sal_uInt8[ nWidth * nHeight ] );). And finally, the image mask is created from this CGDataProvider (xMask = CGImageMaskCreate(nWidth, nHeight, 8, 8, nWidth, xDataProvider, NULL, true );).

[[Image:imageAndMasks.png]]

''Image and its mask (seen in Icon Composer)''

=== The possible causes of the bug ===

So the problem may come from the RawMemorySharedArray, it may also come from the creation of the CGDataProvider from it, or from the creation of the imagemask from the cgdataprovider. What is sure is that the problem comes from the CreateMask function in salbmp.cxx, but i haven't been able to fix it. So i decided to do it by another way.

=== So, how did i do? ===

Instead of creating an image mask from the alpha of the original image, i created a CGImage from the alpha mask (passed as argument of the function as an AquaSalBitmap&), and i masked the original image with it, using context.

Here's the part of code which masks the image:
<pre>CGContextSaveGState(mxGraphicContext);

CGContextBeginTransparencyLayer(mxGraphicContext, NULL);
CGContextClipToMask(mxGraphicContext, CGRectMake( nX, nY, nDX, nDY), xMask);
CGContextDrawImage(mxGraphicContext, CGRectMake( nX, nY, nDX, nDY), xImage );
xMaskedImage=CGBitmapContextCreateImage(mxGraphicContext);
CGContextEndTransparencyLayer(mxGraphicContext);

CGContextRestoreGState(mxGraphicContext);
</pre>
We firstly save the context. Then we call CGContextBeginTransparencyLayer(mxGraphicContext, NULL) to have transparency else the transparent regions are black. Then we use the function CGContextClipToMask(mxGraphicContext, CGRectMake( nX, nY, nDX, nDY), xMask). Here's what the [http://developer.apple.com/documentation/GraphicsImaging/Reference/CGContext/Reference/reference.html#//apple_ref/c/func/CGContextClipToMask AppleDoc] says about it:
<pre>CGContextClipToMask
Maps a mask into the specified rectangle and intersects it with the current clipping
area of the graphics context.

void CGContextClipToMask(
CGContextRef c,
CGRect rect,
CGImageRef mask
);
[...]
mask
An image or an image mask.
[...]
Discussion
If the mask parameter is an image mask, then Quartz clips in a manner identical to the
behavior seen with the function CGContextDrawImage—the mask indicates an area to be left
unchanged when drawing. The source samples of the image mask determine which points of
the clipping area are changed, acting as an "inverse alpha" value. If the value of a source
sample in the image mask is S, then the corresponding point in the current clipping area is
multiplied by an alpha value of (1–S). For example, if S is 1 then the point in the clipping
area becomes transparent. If S is 0, the point in the clipping area is unchanged.
</pre>
Then we draw the image on the context (which has been masked) with CGContextDrawImage(mxGraphicContext, CGRectMake( nX, nY, nDX, nDY), xImage ). And we create the CGImage from this context with xMaskedImage=CGBitmapContextCreateImage(mxGraphicContext). Finally we restore the context (CGContextRestoreGState(mxGraphicContext);)

But this is not enough. Indeed, in the function CGContextClipToMask, the mask is a CGImage not the AquaSalBitmap of the arguments (CGImageRef AquaSalBitmap::CreateWithMask( const AquaSalBitmap& rMask, sal_uInt32 nX, sal_uInt32 nY, sal_uInt32 nDX, sal_uInt32 nDY )). So we have to transform the AquaSalBitmap rMask in CGImage. This is done thanks to the CreateCroppedImage function (CGImageRef AquaSalBitmap::CreateCroppedImage( int nX, int nY, int nWidth, int nHeight);) But the AquaSalBitmap rMask can't be a const, so we have 2 possibilities: remove the const in the declaration of the function, or copy the aquasalbitmap. The first solution can't be used because salgdi.cxx and other files need to have it defined with the const mask. So i used the second solution: copying the AquaSalBitmap (rMaskNew.Create( rMask ) creates a copy of rMask).

But there was still a problem.
The image mask should be inverted, i.e. the black pixels should become white and the white pixels should become black.

[[Image:AquaMenuImagesWithNotInvertedMask.jpg]]

''Without inverting the mask, the parts which should be painted are transparent and those which should be transparent are painted.''

So i looked for a function to do that in the OOo API. The AquaSalGraphics class provide one but it is not yet implemented. And as its implementation is, in my opinion, difficult and need some time, i didn't implement it yet and so I inverted the image mask using contexts in the function which need it. Instead of inverting the AquaSalBitmap with the OOo API, i inverted the CGImage with the Quartz API. But this solution should stay a temporary solution and, in my opinion, should be replaced as soon as possible by the one using OOo API, mainly for the clarity of code.
Here's the code which invert the image thanks to context:
<pre>
rMaskNew.CreateContext();
CGContextTranslateCTM (rMaskNew.mxGraphicContext, 0, mnHeight);
CGContextScaleCTM (rMaskNew.mxGraphicContext, 1.0, -1.0);
CGContextSetGrayFillColor(rMaskNew.mxGraphicContext, 1.0, 1.0);
CGContextFillRect(rMaskNew.mxGraphicContext, CGRectMake( nX, nY, nDX, nDY));
CGContextSetBlendMode(rMaskNew.mxGraphicContext, kCGBlendModeDifference);
CGContextDrawImage(rMaskNew.mxGraphicContext, CGRectMake( nX, nY, nDX, nDY), xMask);
xMask=CGBitmapContextCreateImage(rMaskNew.mxGraphicContext);
</pre>

== Key accelerators ==

=== Short introduction: presenting the basis ===

The function which interests us is <pre>void AquaSalMenu::SetAccelerator( unsigned nPos, SalMenuItem* pSalMenuItem, const KeyCode& rKeyCode, const XubString& rKeyName ) </pre>

* nPos is the menu item index, but nPos is 0 to n based whereas the carbon API we use for ooo macport is from 1 to n+1 e.g. for the first element nPos=0, and his carbon index will be 1

*SalMenuItem* pSalMenuItem is a pointer to the menu item we want to add key accelerator

*const KeyCode& rKeyCode is the keycode of the accelerator. We can get the keycode with ''rKeyCode.GetCode()'' and the key modifier(s) (like cmd, shift, ... for Mac OS) with ''rKeyCode.GetAllModifier()''

*const XubString& rKeyName is not used for the MacOs port

=== Implementation ===

We will use the ''SetMenuItemModifiers'' function to chose the modifier(s) of the key accelerator like cmd, shift, alt... and we'll set the key accelerator with two different function depending of the situation: the ''SetMenuItemCommandKey'' function for visible key accelerator (like for the N of Cmd+N) and the ''SetMenuItemKeyGlyph'' function for non visible characters (like for F1, F2,... or space).

=== Setting the key accelerator ===
The difficulty is that the OOo keycodes are different of the ASCII keycodes used in Carbon.
For example: A is 65 in ASCII but in OOo it's 512 (defined in Key.hdl)
So we have to translate from ooo codes to ascii, but the order of the characters are not exactly the same as ASCII so we translate only by intervals. We obtain this code:
<pre>
if ((ncode>=KEY_A) && (ncode<=KEY_Z)) {
nresultcode=ncode-KEY_A+'A';
}
else if ((ncode>=KEY_0) && (ncode<=KEY_9)) {
nresultcode=ncode-KEY_0+'0';
}
</pre>

We do the same thing for non visible characters but instead of using the ascii code of the given character we use its carbon value.
<pre>
else if((ncode>=KEY_F1) && (ncode<=KEY_F12)) {
nresultcode=kMenuF1Glyph+ncode-KEY_F1; // kMenuFnGlyph=kMenuF1Glyph+n only for n<13 then it should be processed for each case
}
else if((ncode>=KEY_F13) && (ncode<=KEY_F15)) {
nresultcode=kMenuF13Glyph+ncode-KEY_F13; //kMenuF13Glyph=0x87 and kMenuF12Glyph=0x7A
}
else if(ncode==KEY_SPACE) {
nresultcode=kMenuSpaceGlyph;
}
</pre>

Then we only have to add the accelator to the menu:
*For the non visible characters: The syntax of ''SetMenuItemKeyGlyph'' is:
<pre>
OSErr SetMenuItemKeyGlyph (
MenuRef inMenu,
SInt16 inItem,
SInt16 inGlyph
);
</pre>

so we use it like this:
<pre>
SetMenuItemKeyGlyph (
mrMenuRef, //is the reference to the menu
nPos+1, // for the reason of using nPos+1 instead of nPos see the short intro
nresultcode
);
</pre>

*For visible characters: The syntax of ''SetMenuItemCommandKey'' is:
<pre>
OSStatus SetMenuItemCommandKey (
MenuRef inMenu,
MenuItemIndex inItem,
Boolean inSetVirtualKey,
UInt16 inKey
);
</pre>

so we use it like this:
<pre>
SetMenuItemCommandKey (
mrMenuRef,
nPos+1,
0,
nresultcode
);
</pre>

=== Key accelerators definitions in OpenOffice.org for MacOS X ===

See [[Mac OS X Porting - Keyboard Shortcuts]].

--[[User:Ismael|Ismael]] 16:43, 19 April 2007 (CEST)

[[Category:MacOSX]]
[[Category:Porting]]
[[Category:Aqua]]

Documentation/Building Guide/Building on MacOSX

2007-05-08T10:02:00Z

Plipli: /* '''External links''' */

<big>'''This document tries to wrap-up the build process for [[OpenOffice.org]] on Mac OS X using the native windowing-toolkit of the platform named Aqua.''' </big>

To give a kickstart in the coding involved to get VCL ported to Carbon, please have a look at the excellent Pierre de Filippis [[Intro To Mac Porting]].

We use the bash shell in all examples, since to our belief users of the C-shell are smart enough to figure out the differences anyway. If you want to dig deeper into the build process, please have a look at the description of the build environment here: [http://tools.openoffice.org/build_env.html OpenOffice.org Build Environment].

== '''Prerequisites''' ==

This document was derived from the description of the X11 build thanksworthy provided by Eric Hoch in this document: [[MacOSXBuildInstructions]].

'''Here we would like to outline the things you need to build the Aqua Version''' (besides the OS).

=== <div align="left" style="color:red; font-size:18px">'''Mandatory'''</div>===

==== Xcode ====

This is the only mandatory part to be installed to build Aqua version of OpenOffice.org.

Current verified working version is XCode 2.4.1

If you really cannot use XCode 2.4.1 nor XCode 2.4:

Xcode 2.2, 2.3 are known to work for Aqua development. If any earlier versions work as well, please add them here.

==== X11SDK (soon optional) ====

A dependency for Mozilla plugin needs some prototype defined in some Xlib.h header.

Please note, this dependency is not needed in runtime, but only at buildtime.

X11SDK.pkg archive is located in your Tiger's DVD, and has to be installed in the case of you're using Mozilla prebuild archives

<pre>This issue should be fixed soon.</pre>

=== <div align="left" style="color:blue; font-size:18px">''' Strongly recommended'''</div>===

==== ccache ====
If you intend to build several times OpenOffice, you probably can benefit of ccache. ccache will speed up your future builds. The first time you make a build with ccache you won't notice it, but then the build will go up to five times faster.

You can install it using fink. It is simply named "ccache".

If you don't use fink, you can download it and build it yourself using the source provided at http://ccache.samba.org/

Then, in order to use it, you need to change the following environment variables '''using bash, and just before doing configure command line''':

<pre>
export CC="ccache gcc"
export CXX="ccache g++"
</pre>

<div align="left" style="color:grey; font-size:18px">[[AquaBuild/Some Background | '''Some Background (what is aquavcl01, EIS) (click me to know more) ''']]</div><br><br>

== '''Getting the code (checkout, merge and patch the puppy)''' ==

aquavcl01 cws does use SRC680 master workspace, and is regularly resynchronized with recent milestones.

'''The current milestone as of now (May 3rd 2007) is m211'''

All these milestone numbers below highly depend on the given point-in-time. You can find the current milestone of each cws in the EIS database.

You also need to bear in mind that you have to access to the CVS-Server's default port (2401). If a firewall stop's you here you have to setup a CVS-Tunnel.

==== Create a directory for a given milestone, setup CVS access: ====
<code>[bash,N]
mkdir src680-m211
cd src680-m211

export CVSROOT=:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs
cvs login
(password is 'anoncvs' ) + Enter
</code>

==== checkout milestone m211 (1,5 GB): ====
<code>[bash,N]
cvs -z3 co -r SRC680_m211 OpenOffice2
</code>
Once done, you'll obtain milestone 211. this not exactly what we want, because all changes concerning aquavcl01 Child workspace are not included. To complete, we need to check aquavcl01 changes.

==== checkout Aquavcl01 (50 MB): ====

1) First possibility: create a dedicated tree (cool backup)

To check aquavcl01 Child workspace, the most simple is to create aquavcl01 directory, and go inside this dir
<code>[bash,N]
mkdir aquavcl01-src

cd aquavcl01-src
</code>
(assuming you already did cvs login, and typing all the command line below in one line)

<code>[bash,N]

cvs -z3 co -r cws_src680_aquavcl01 canvas dtrans extensions fpicker \
freetype instsetoo_native padmin psprint sal scp2 sfx2 sj2 solenv toolkit vcl
</code>

All the modules listed above will be present at the end ( everyone represents a new directory ) and they are the ones we modified to create the native version.

To verify nothing's wrong, all are tagged "aquavcl01" (see all CVS/Tag files in the tree) and all you have to do is either rename or delete the one located in src680-m211 and replace them with the one located in aquavcl01-src.

e.g. : canvas in src680-m211 will become canvas_m211 , and then, cp canvas from aquavcl01-src into src-m211

This applies for all the modules listed above.

2) Second possibility: use a little script to extract changes: extract_aquavcl01.sh

This shell script, located in src680-m211 will contain:
<code>[bash,N]
#!/bin/bash
list="canvas dtrans extensions fpicker freetype instsetoo_native padmin psprint sal scp2 sfx2 sj2 solenv toolkit vcl"
for i in $list ; do
mv $i $i-m211
cvs -z3 co -r cws_src680_aquavcl01 $i
done
</code>

Then chmod +x extract_aquavcl01.sh

and run it:

./extract_aquavcl01.sh

When finished, and if no problem occurs, you should have a complete tree.

=== One-Time preparations and scripts ===

OpenOffice building gets configured by the popular open-source configuration-management package 'autoconf'. So you can do your beloved './configure' command, but in our case this is done in the 'config_office' subdirectory. To save the configure parameters and use them with different milestones I used to link-in my shellscript to fire up the ./configure line.

My directory-structure looks like this:

bin/
src680-m182/
src680-m196/
...

Now I go to the 'config_office' subdir and link in my startscript:
<code>[bash,N]
cd src680-m211/config_office/
ln -s ../../bin/build.sh
</code>
And this is how 'build.sh' (to be written) looks like :

<code>[bash,N]
#!/bin/sh
export BASE=`pwd|sed 's/\/config_office//'`
export OOVERSION=`echo $BASE|sed 's/^\/.*\///'`
echo Building from : $BASE
echo OpenOffice Version: $OOVERSION
./configure \
--with-lang="de en-US" \
--with-jdk-home=/Library/Java/Home/ \
--with-epm=internal \
--disable-mozab \
--disable-odk \
--disable-pasf \
--disable-gtk \
--disable-mozilla \
--with-build-version=$OOVERSION-`date +%d-%m-%y` \
--disable-fontconfig \
--disable-neon \
--without-nas
</code>

--disable-odk : disables SDK build, and will avoid you to download some windows dll which is not needed for aqua-build.

--disable-pasf : pasf stands for Portable Audio System file. As we want to use system library rather than portable ones, we disabled this. However, at this time not all functionality will be available with pasf disabled. You might willing to use --with-pasf if you want working audio in your build.

--without-nas : nas stands for Network Audio System, it uses X11, if you want to use it in your build, just remove this flag. You will need to install the X11 package provided in your CDs/DVD Mac OS X installation. X11 SDK from xCode tools is not required for build this.

This is allowedly a pretty much limited setup for now, but it will progressively change, with the progress we'll do with Aqua port.

== '''List of Patches requiring testing before for integration''' ==

All patches that developers have that need testing or peer review should be added here.

<br><div align="left" style="color:grey; font-size:18px">[[AquaBuild/Native FilePicker | '''Native FilePicker (click me to know more) ''']]</div><br><br>

Soon : new salframe implementation ( using HIFramework )
<br>

== '''Known build issues '''==

Since latest resync, no build issues have been reported.

== '''Doing the build (about 4,5 GB)''' ==

Fine, now we have a (hopefully) working 'build.sh' in the config_office subdir. We need to run it beforehand:

cd src680-m222/config_office/
./build.sh

This will setup the necessary includefiles and create a couple of files in the '''parent''' directory (bootstrap, MacOSXPPCEnv.Set.sh, MacOSXPPCEnv.Set). If you are using the sh, ksh or bash you only need to take care for 'MacOSXPPCEnv.Set.sh'.

Now we need to get back to our base-directory, run the bootstrap script, source our Enviroment (MacOSXPPCEnv.Set.sh) and finally start the build-process:

On PowerPC:

cd ..
./bootstrap
source MacOSXPPCEnv.Set.sh
cd instsetoo_native
build --all -P2

Or (on Mac Intel):

cd ..
./bootstrap
source MacOSXX86Env.Set.sh
cd instsetoo_native
build --all -P4

The main purpose of the '''boostrap''' script is to build (if necessary) the dmake utility used. Dmake once was a unix make-clone made by wticorp but got incorporated into OpenOffice since it was orphaned. For more information about dmake, it's history and manpage have a look here: http://tools.openoffice.org/dmake/index.html

Sourcing MacOSXPPCEnv.Set.sh is very important not only for building but also for '''running''' svdem later on. Here all the Environment-Variables for the Build will be set up. For a detailed description see [[Environment_Variables]]. Please note that on Intel machines, 'MacOSXPPCEnv.Set' should be substituted with 'MacOSXX86Env.Set'.

This Build process takes on my box (Dual 1.8 GHz G5, 1.5GB RAM) roughly 10 hours, and 3 to 6 hours on Mac Intel. Be patient.

== '''Installing, preparing and running OpenOffice.org''' ==

===''' Find the Bundle''' ===

Once the build completed, the Final product ( en-US version ) is named : OpenOffice.org-2.3.0_en-US.dmg ( for version 2.3.0 e.g.)

And is located in instsetoo_native/unxmacxi.pro/OpenOffice/install/en-US directory ( replace en-US with your locale )

[[Image:Bundle_location.jpg]]

<br><br>

=== '''Run the soffice.bin''' ===

In one line :

<big>'''Double click the .dmg , drag the OpenOffice.org icon in the folder you want, and double click to run it !!'''</big>

Note : soffice.bin leads XCode to not work (because of the dot in the name). The issue has been reported to xcode-users list.

We're nearly through, let's fire-off the binary:

But a lot has to be done, and if you want to trace (using gdb e.g.), just do:

cd <INSTALL_DIR>/OpenOffice.org\ 2.3.app/Contents/MacOS

and run:

gdb --args soffice.bin

(add any breakpoint you want)

r to run OpenOffice.org

=== Use vcl menubar and / or vcl menus ===

Native menus are defaults. If you want to use vcl menus, do:

<pre>
AQUA_NATIVE_MENUS=FALSE ./soffice.bin
</pre>

Note: options to not recover is -norestore , and to bypass the user informations to fill in, use -nofirststartwizard

AQUA_NATIVE_MENUS=FALSE ./soffice.bin -nofirststartwizard -norestore

Notice the enviroment variable here. AQUA_NATIVE_MENUS is experimental stuff created by Pavel, SAL_NO_NWF was created some times ago, and is located in vcl/source/window/window.cxx . At the moment we have:

{| border="1" cellpadding="15" cellspacing="0"
|-
! Variable || Function
|-
| SAL_NO_NWF=TRUE || disable native controls code
|-
| AQUA_NATIVE_MENUS=FALSE || disable native menus code
|}

Both changes are marked with comments in the source code, and when we remove them in the future, native controls and native menus will be enabled by default.

== '''Debug and contribute ''' ==

<div align="left" style="color:blue; font-size:18px">'''See [[MacOSX_Debug_OpenOffice.org_using_XCode]]'''</div><br><br>

<div align="left" style="color:blue; font-size:18px">You want to debug using Xemacs ?</div><br>

Michael Sicotte wrote a very usefull blog entry about : '''[http://www.mikesicotte.com/2007/02/21/debugging-ooo-with-xemacs-and-gdb debugging OOo with XEmacs and GDB on Mac OS X]'''

== '''External links''' ==

# [http://www.openoffice.org/issues/query.cgi Bug Database]
# Mailinglist: [http://porting.openoffice.org/servlets/ProjectMailingListList mac@porting.openoffice.org] (subscribe is mandatory )
# IRC Meeting-Logs (#ooo_macport@freenode.org): [[Previous_Mac_Meeting_logs]] [[MacOSXPortMeetings]]
# TX20: http://eric.bachard.free.fr/UTBM_TX20/reports/Carbon_vcl.pdf
# OpenOffice Source Directory Structure: http://wiki.services.openoffice.org/wiki/Source_code_directories
# Pavels Patch Wiki: http://blog.janik.cz/
# Eric Bachard Wiki: http://wiki.services.openoffice.org/wiki/User:Ericb
# Sebastien Plisson Wiki: http://splisson.blogspot.com/
# Christian Lippka Wiki: http://wiki.services.openoffice.org/wiki/User:CL
# Carbon: http://developer.apple.com/carbon
# EIS: http://eis.services.openoffice.org/EIS2/servlet/Logon
# Runtime Configuration: http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/index.html
# OpenOffice Domain Developer http://wiki.services.openoffice.org/wiki/DomainDeveloper

== '''Screenshots''' ==

# Eric Bachard screenshots (some are from Stephan Schaefer) http://eric.bachard.free.fr/mac/aquavcl/screenshots/
# Most recent: http://eric.bachard.free.fr/mac/aquavcl/screenshots/aqua_menus_05_nov_06/
# Pavel Janik screenshots http://blog.janik.cz/images/MacOSX/2006-08-10
# Important screenshot (eventloop issue): http://blog.janik.cz/images/MacOSX/ => See: OOoMenus-separator-and-disabled_entries.png
# Aqua look (the begining):
http://eric.bachard.free.fr/mac/aquavcl/screenshots/mars2007/combobox_search_and_replace02_14mars07.jpg

More menus: http://eric.bachard.free.fr/mac/aquavcl/screenshots/aqua_menus_05_nov_06/index.html

[[Category:MacOSX]]
[[Category:Porting]]
[[Category:Development]]
[[Category:Aqua]]

User:Ericb

2007-04-25T20:19:13Z

Plipli: /* Misc */

==Public Documentation License Notice==

The contents of this Documentation (excepted Native Port Roadmap),are subject to the Public Documentation License Version 1.0 (the "License"); you may only use this Documentation if you comply with the terms of this License. A copy of the License is available at http://www.openoffice.org/licenses/PDL.html.
The Original Documentation is "Mac OS X native port". The Initial Writer of the Original Documentation is (JCA) Eric Bachard (C) 2005-2006. All Rights Reserved. (Initial Writer contact(s): ericb@openoffice.org.)

=='''Mac OS X Native port'''==

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">
'''The first Mac OS X native port objective is make OpenOffice.org run without X11 use, to make it a real Mac application.'''

'''The second one is respect Aqua Human interface Guidelines'''

''' This is a long term work, and every help and/or contributions, like donations** are welcome.'''
</div>

**see http://contributing.openoffice.org/index.html

=='''Native Port Roadmap'''==

==='''2006'''===

* June 2006: work in progress

- Basis: frame, instances, threads, drawing, painting, resizing (Stephan Schaefer, Tino Rachui)

Done:
implement threads
create, manage instance
create, manage windows (including parents)
create, manage events
create manage drawing, resizing
create, add menus (Pavel Janik)
toggle window fullscreen (Pierre de Filippis)
make font server work (Stephan Schaefer)

* Current status font support (Stephan Schaefer, 2006/07/28): the following features are basically working now
** font selection
** font size
** simple font attributes (bold, italic)

Next step: document first part, and propose design

- native filepicker (Pavel Janik, Florian Heckl)

- native printing implementation (Oliver?)

- native font implementation (Eric Bachard)

* September 2006:

- first proofs of concept: fonts, filepicker .. (more?)
- show the results (OOoCon 2006?)

==='''2007'''===

* January 2007: first alpha implementation

=='''Strategy for native port'''==

'''Possible Actions''':

Identify us:

#Complete the arrays below
#Update photos on frapr.com?

Share the work:

#Divide the work between little Teams
#Update Todo list regularly -> needs some love these days ... [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s]

Help:

#Teach tools between us
#Do a debug party on IRC
#write documentation

Meet us:

#IRC
#Mac Meeting (like nov2005 in Hamburg?)

Inform:

#Update website regularly
#Blogs

'''WHO''':

Mac Team:

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
|Developer \ skills || build || write code || code review || debug/trace (higher is better) || contribute to documentation ||
|-
|ericb|| x || x || || 1 || x ||
|-
|pjanik|| || || || || ||
|-
|ssa|| || || || || ||
|-
|maho|| || || || || ||
|-
|tinor|| || || || || ||
|-
|schmidtm|| || || || || ||
|-
|ebischoff|| || || || || ||
|-
|obr|| || || || || ||
|-
|cl|| || || || || ||
|-
|aliscafo|| || || || || ||
|-
|fheckl|| || || || || ||
|-
|Fridrich|| || || || || ||
|-
|plipli|| || x || || || x ||
|-
|}

'''Other resources''':

fonts: ?

events: ?

QA: James McKenzie leads QA for the Mac OS X port of OpenOffice.org and is looking for volunteers to spread this effort over several people and needs people from all over the world to test various languages.

graphical: ?

Communication: ?

'''WHAT''': Status of most important tasks

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
| Task || Names|| Urgency (1=higher)|| Work in Progress || Done || Code review || Debug || Integration ||
|-
|Get rid of X11||done || 1 || x || x || || || ||
|-
|Bundle|| || 1 || x || || || || | ||
|-
|Drawing|| || 1 || x || || || || || ||
|-
|Fonts||plipli || 1 || x || || || || || ||
|-
|Events management|| || 2 || x || || || || || ||
|-
|Controls (see list) ||ericb, aliscafo || 2 || x || || || || || ||
|-
|Native FilePicker||Florian Heckl, Pavel Janik || 3 || x || x || || || || ||
|-
|Native Printing||Yvan Barthelemy || 3 || x || || || || || ||
|-
|Native SpellChecker|| || 4 || || || || || || ||
|-
|Player||Mox Soini || 4 || x || || || || || ||
|}

Other tasks:

Help for writing bug lists, status of bugs ..etc

Write howto use gdb, leaks, other tools

'''WHEN''':

From Christian Lippka (last meeting, 25th of august 2006):
Aug 26 00:21:38 ChristianL
from my point of view what is missing for point 1:
text layout, complete font support, keyboard support,
fixing repaint issues, having aqua install and run out of the box

'''September 2006'''

Present the current state of the project at the 2006 OpenOffice conference in Lyon and Paris

'''Late 2006'''

fix OpenOffice.org launch
fix drawing (repainting)
Implement missing methods and fix most important bugs (mainly the one leading to crash) in:
ATS
Salgraphics
Salinstance

'''January or February 2007'''

make Java work (works partially)
make intensive debug
present something working as alpha

'''June 2007 '''

Implementation of:
native filepicker
native printing

== '''Become a Domain Developer for Mac OS X port''' ==

People regularly contributing to Mac OS x port with regular and quality patches are, after proposal, invited to become a [[DomainDeveloper]].

The purpose of this document is to clearly define all the steps to become a [[DomainDeveloper]].

Preliminary : step 1 in [[Commit_Rights]] must be completed and checked, and you must be in the list of [[http://www.openoffice.org/FAQs/faq-licensing.html#jca1 JCA Licensed people]]

=== Steps for ssh2 key to be uploaded ===

==== Create the key ====

Everything is described here : [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

==== Upload the key ====

You must create an issue, like described below :

Component : www

Sub Component : openoffice.org cvs

Title : CVS Commit access request

Add louis ( Louis Suarez Potts) or st ( Stefan Taxhet ) on CC

Upload your ssh2 public key respecting the process ( Attach a DSA key, not an RSA )

A project lead will confirm your request

Then the support will upload your key

Once done the issue is set to Fixed , and the next step has to be verified before '''you''' close it.

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75291 Upload SSH2 Key for Etsushi Kato]]

==== Verify it works ====

You now can try to connect via tunnel, and follow instructions given [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

If something goes wrong, ask for help to support, with a maximum of details, to solve the problem.

Once it works, the issue can be closed, and you can e.g. test downloading a module from tunnel repository :

First create a tunnel with the command:
<pre>
ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org
</pre>

Then in a new window:

<pre>
export CVSROOT=":pserver:your_login@localhost:/cvs"

cvs login ( enter )

(your password )

mkdir TEST

cd TEST

cvs -z4 co -r SRC680_m205 vcl

cd vcl

cat CVS/Root -> should indicate : your local repository
</pre>

=== Ask for CVS access for all modules required ===

Two steps : create an issue is mandatory because the concerned project is tools, and because people can have only ssh2 key without being [[DomainDeveloper]].

==== Create an issue ====

You must create an issue, described below :

Component : tools

Sub Component : www

Title : CVS access to all modules required

Assigned to mh + CC for ericb and/or pjanik

Present yourself quickly, and ask the access

A project lead will confirm

An admin will confirm this is ok, and set the issue to Fixed

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75494 CVS Access all modules for Etsushi Kato]]

==== Verify ====

Create the tunnel :

open a terminal and type :

ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org

once logged in, open a new terminal, and do ( for example ):
<pre>
cd $OOO_SRC_ROOT/

source MacOSXPPCEnv.Set.sh { source MacOSXX86Env.Set.sh for Mac Intel }

cd vcl ( for example )

IMPORTANT : be sure vcl has been checked from tunnel, not from anoncvs ( cat CVS/Root will give you the answer )

export CWS_WORK_STAMP=aquavcl01 # Only needed for working with [[EIS]], can change for a different CWS ;)

cd aqua/source/gdi

add your changes to your_file.cxx, then commit :

cvs commit -m "#i75689# bla bla ... the reason of the modification(s)" your_file.cxx # The #i75689# is an issue number in the tracker

cvs update

If nothing is wrong, cvs update should not return M for your_file.cxx, means the commit is successfull.
</pre>
In case of problem, use the issue until it is fixed

<big>'''Welcome aboard :)'''</big>

== '''Mac OS X porter Team at WWDC 2007''' ==

=== What is WWDC 2007 ? ===

See [http://developer.apple.com/wwdc/ Apple WWDC 2007]

====Labs Agenda====

It is extremely important to organize us for Labs.

The rule is extremely simple : bring your laptop, your code, and ask :)

{| border="1" cellpadding="10"
| Days
|monday<br>June 11
|tuesday<br>June 12
|wednesday<br>June 13
|thursday<br>June 14
|friday <br>June 15
|-
|Labs
|<br>Afternoon
|Morning<br>Afternoon
|Morning<br>Afternoon
|Morning<br>Afternoon
|Morning<br>Afternoon
|}

===='''Interesting Labs'''====

The complete list : [http://developer.apple.com/wwdc/tracks/macosx.html Mac OS X Essentials]

*Core Text Lab
Receive one-on-one technical assistance and troubleshooting advice from the Core Text engineering team. Learn how to use the advanced font handling and blazingly fast Unicode layout capabilities of Core Text. Bring your laptop, your code, and your questions.

*HIToolbox Lab
Work on tuning and debugging HIToolbox code in your Carbon application. Receive one-on-one technical assistance and troubleshooting advice from the High Level Toolbox engineering team, Apple DTS engineers, and technology evangelists. Bring your laptop, your code, and your questions.

=== Our Objectives at the WWDC 2007 ===

1) Contacts with Apple's teams :

* Present our current work, methods and team to Apple people, easy to meet only during WWDC ( Apple people can give us a face, and keep the contact )

=> There is information difficult to find or ask by email, or IRC or whatever web : direct contact saves a lot of time, and is a very efficient way to progress with code

* Get their impression about what we have already done and what is still ToDo

2) Mac Team's goals on Aqua OOo -> Apple's Expertise :

* "Give MacOS X users the OOo suite they deserve" :

=> As mac platform and apple's product fans, we are proud to bring the quality and power of OOo to mac users community
=> Make OOo uses all the power of Mac OSX, including upcoming Leopard !

* "OOo to be as Apple HIG compliant as possible" :

=> Define what is expected for User Interface with people from Apple UI project

- FYI : Last year, Apple UI project proposed ericb to help us, once our native menus will be working.

This is now done, and meet them cannot be a bad idea :)

3) Get code guidelines, tips, samples :

=> Ask for code review and find code snippets for :

- HIView
- Printing
- Drag and Drop
+ more if possible

=> More than 1000 Apple engineers are present, and can answer our questions regarding the code, during the whole week

During WWDC2006 we found all the relevant informations for RunApplicationEventLoop() to be implemented . Without this code, we wouldn't have something working at all, because this event loop is the key for everything in OpenOffice.org on Mac OS X ( without X11 ).

4) Social Contract : Discuss and meet new developers and / or american people working for Mac OS X port (like Michael Sicotte, Vijay Venkatraman , other.. )

5) Visibility : make OpenOffice.org project visible in an ocean of other software. This is extremely important because it shows that OpenOffice.org project is alive for Mac OS X platform.

=== Who ? ===

* Sébastien Plisson
* Eric Bachard
* ???

=== Todo list ===

Please add topics, technical questions you would see asked by attendees to Apple engineers during WWDC

====Suggestions for current issues to be fixed ====

Timers :

Current code is obsolete, and compatibility with Leopard won't probably exist.

Pavel wrote a patch using recent code. Seems to work fine, excepted a thread issue ( never crashed because of that yet , but this is probably correct)

Salframe :

Looot of things :

*Find infos/code sample about parenting

*Code review for HIFrameWork implementation

*adapt native widget framework

Events : code review, tips

ATS : code review, ATS issues

Mike Sicotte:
I understood that implementing printing in aqua OOo was a topic that we didn't get accepted into Google SOC - so remains on the ToDo list. I notice that there are three Sessions specfically related to printing at WWDC:
Leveraging the Common Unix Printing System (CUPS)
Printing with Style in Mac OS X
Printing Lab
If this is judged to be a good use of time at WWDC I would be willing to spend some time to help further develop the questions to be addressed with the Apple engineers.

ericb->Mike Sicotte

Good idea. You are welcome :)

==== Misc ====

*describe the schedule of the travel

ericb :
<pre>
Mulhouse -> Paris -> SF : 9th of June SF scheduled arrival : 7:13 pm
SF -> Paris -> Mulhouse : 16th of June ( arrival 17th ) SF departure for the return : 3:00 pm

Hotel : King Georges ( close to Union Square )

Airport to Hotel transportation : not included
</pre>

sebastien (aka plipli) :
<pre>
Paris->SF : 3rd June
SF->Paris : 15th June in the evening

Hotel : to be coompleted
</pre>

third attendee :

[to be completed]

*Prepare 50 to 100 business cards :

the most simple is to use the model I can provide on demand , and print them with special paper ( pre-cut )

== '''Mac OS X porter Team at OOoCon 2007''' ==

=== Who ? ===

* Shaun McDonald
* Eric Bachard
* (list to be completed)

=== What ? ===

The conference is over 3 days. Presentations should last around 45 minutes. http://www.openoffice.org/servlets/ReadMsg?list=announce&msgNo=320 Papers have to be submitted by 1st June to be considered.

Ideas :

Mike Sicotte: Perhaps the results of the Google SOC could be a presentation.

*create a complete topic for Mac port (one stream for a day or half day)
*How to improve ooo usability though the use of floating palettes instead of modal dialogs

- several presentations / BOF

Eric Bachard : Aqua OpenOffice.org ( conf / 1 hour )

Others ?

*reserve rooms together ? Better rent a house?

* [FIXME]

=='''2nd Mac porters meeting'''==

This section has been moved to [[2nd Mac porters meeting]]

=='''IRC Mac port meetings'''==

This section has been moved to [[MacOSXPortMeetings]].

== '''Mac OS X (X11) Quality Assurance'''==

This section has been moved to [[Mac OS X ( X11) Quality Assurance]]

== '''Mac OS X Implementing HIView and Carbon events'''==

This section has been moved to [[Mac OS X Implementing HIView ]]

== '''Debug OpenOffice.org using XCode '''==

[[ MacOSX Debug OpenOffice.org using XCode]]

=='''Description of the Native Port problem'''==

=== How does OpenOffice.org work on Mac OS X? ===

Currently, on Mac OS X, OpenOffice.org uses X11, as "client": X11 is a graphical server, coming from Unix world, and able to run under Linux, *BSD, Solaris, Mac OS X.

- X11 is run as an application, managed like other Apple applications.
- All unix like applications are managed by X11, and from Aqua environment, only X11 is seen as only one applicatiion,
even if other Unix/Linux (e.g.) applications are runing.

OpenOffice.org asks X11 to display a window, waits for X11 acknowledgment, and OpenOffice.org displays the window. All transactions use the network, locally or not. the same mechanism is used for everything to be displayed.

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=== Issues and known problems ===

All events are managed by OpenOffice.org and X11, using the Xlib

Only .ttf fonts type is currently available. Note: '''system fonts are available '''

The rendering is made by X11, not by Mac OS X rendering engine.

X11 and all its clients are seen as one application only: drag and drop protocol does not work because of that (solution: Pasteboard Manager)

==== Other links ====

http://wiki.services.openoffice.org/wiki/List_of_OpenOffice.org_Mac_OS_X_issues_and_problems#

http://wiki.services.openoffice.org/wiki/Printing_problems_with_OpenOffice.org_2.0_for_Mac_OS_X#Reporting_printing_problems

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

== What do we have to do?==

* (in progress) : Implement direct access to Apple graphical engine, using Apple API: Quartz2D/CoreGraphics (and replacing Xlib use)

like: instantiate, manage events and threads for a graphical instance + all needed objects, drawing: manage all drawing cases

* (in progress) : Implement native events management, using CarbonEventManager (replacing Xlib management)

* (in progress) : Implement native font use, using Apple Type Server and ATSUI (for Unicode Imagery) (replacing X11 management)

Work in progress: [[Mac OS X Porting - Native Fonts]]

* Implement native sound, using QuickTime (replacing Java Media Framework): [[Mac OS X Porting - Native Audio and Video]]

* Implement native Drag and drop, Implementing Pasteboard Manager: [[Mac OS X Porting - Native Drag and drop]]

* (done experimental) Implement Native Filepicker

* Implement Native Printing: current uses cups, but native printing is mandatory: [[Mac OS X Porting - Native_Printing]]

* Implement Apple Spellchecker

--[[User:Plipli|Plipli]] 09:27, 25 March 2007 (CEST)

=='''Where is located the code to be modified?'''==

Most of the changes are located in vcl (Visual Class Layer), for everything graphical, events, fonts, rendering and printing.

Other, for sound and movies will be in avmedia (where the player is implemented in OpenOffice.org sources).

For drag and drop, dtrans is concerned (Pasteboard Manager implementation)

[FIXME]: Filepicker? Apple Spellchecker?

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=='''How will the new implementation be tested?==

Currently, all openOffice.org code can be compiled without using the Xlib. but of course, a lot of features are missing,

and the final package simply won't work

In vcl module", a '''toy''' called svdem is built at buildtime. This binary is linked to libvcl* and so all new stuff can be tested.

e.g. : draw anti-aliased lines works well.

Everything implemented in aqua vcl code will be included in libvclplug_aqua, and svdem source code will contain a specific part to proceed tests.

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">

'''The magic is: when all needed features will work with svdem, it will work in the new version of OpenOffice.org !!'''

</div>

[FIXME]: add more complete list of features to implement and test.

== AquaVCL 01 cws ==

[[http://qa.openoffice.org/issues/buglist.cgi?keywords=aqua Top 10 of Aqua issues]]

[[Aquavcl01 tasks]]

===Changelog ===

====Work in progresss : alpha 0.6 ====

Started (19th March ) :

Michael Sicotte proposed to investigate in timers, and continue [[http://www.openoffice.org/issues/show_bug.cgi?id=75228 Pavel's work]] : objective is to replace obsolete code. ( 23th March)

[experimental] plipli proposed a patch for a new salframe implementation, using HIView + optionally compositing (21th March )

[commit scheduled] Michael Sicotte proposed a complete patch for invert() ( SAL_INVERT SAL_INVERT_50 and SAL_INVERT_TRACKFRAME ) (20th March )

Tino proposed to work on code cleanup in salatsuifontutils.cxx, removing obsolete code

ismael and michael work on invert() + drawAlphaRect()

Damien started to work on drawEPS()

plipli and ericb work on refresh

==== alpha 0.5====

Top 10 Summary : 7 issues over 10 are fixed or very close to be :

'''time to code review, tracing, and search for memory leaks'''

[done] Unicode input in salframe ( ekato ) ( 19th March )

[experimental, works partially] beginning of HIView + HIComboxes works (text still missing) (ericb + plipli) ( 14th March )

[done] replace NewRgn() in salframe (ericb (11th March )

[experimental, but very interesting] Improved native windows ( ismael ) ( 7th March )

====alpha 0.4====

'''[Informative]''' build runs with Leopard 9A377a ( fheckl ) ( 7th March )

Refresh screen issues (plipli) (4th to 10th March )

'''[informative]''' plipli announced progress with refresh screen issues ( 28th February )

[experimental, not yet commited] Proxy configuration from system ( pjanik) ( 28th February )

[done] highlighted native button ( pjanik) ( 27th February )

Native File Picker works ( fheckl / pjanik ) ( 23th February )

====alpha 0.3====

Cursor does appear -> invert() + setting a setBlinkTime value in UpdateSettings() (pjanik /ericb )

[done] mirroring negative images (ismael) + DrawAlphaBitmap() + CreateWithMask()

pjanik patch for Focus Events

[done] scrolling works ( pjanik ) (17th February )

[done ] carret works ( plipli) (17th February )

[done] checkbuttons fix for checkmarks (ericb) ( 17th February )

'''[Informative]''' Pavel Janik propose to solve offScreen buffer using HIView ( 17th February )

[experimental, never commited] patch for macosxrc.txt use + UpdateSettings() use in salframe.cxx ( ericb ( 16th February )

Michael Sicotte joined the Team ( 15th February )

invert() : first try (ericb) ( 13th february )

====alpha 0.2====

[12th February 2007 ]

[done] calc does not start : bug identified by tino , first workaround (ericb) [[http://www.openoffice.org/issues/show_bug.cgi?id=73691 issue 73691]]

[done] bitmaps in native popup menus (ismael)

[done] replace obsolete code for HandleWindowPaintEvent(), newRgn() .. etc (ericb) (12th February)

correct salatslayout patch (plipli) ( 11th February)

'''[Informative]''' Michel Renon proposed a summary about his work on fonts issues

[patch] Pavel fixed several menu crashes (09th February )

'''[Informative]''' : Pavel posted a mail about several crashes origin

patch for radioboxes and checkboxes ( ericb ) (9th February)

first complete patch for salatslayout.cxx ( plipli) ( 9th February )

[done] most important crashes fixed ( pjanik) ( 09th february )

Modified baseline for 2.2. : Mac OS X10.4 -> Aqua will be 10.4 and 10.5 compatible only ( ericb)

first try with multi line sallayout (plipli ) ( 08th February )

Damien Duportal joined the Team ( 7th February )

[done] scrollbar changes (ericb ) ( 4th February )

====alpha 0.1====

create Top 10 of issues before alpha 3rd February 2007 : See : [[http://porting.openoffice.org/mac/news/2007/20070203toptenbeforealpha.html Top 10 of issues]]

[experimental, not commited] patch for TPT() implementation (ericb) ( 2nd February 2007 )

Pavel Janik proposed to implement TransformProcessType() ( 2nd February 2007 )

[not commited] implement UpdateSettings() (ericb)

Pavel Janik resynchronized aquavel01 cws with m202 ( 2nd February 2007 )

====alpha 0.03====

Michel Renon joined the Team (1st February )

[done] fix checkbuttons and radiobuttons issues: offsets, redrawing of the check marks ( ericb)

[done] fix scrollbar buttons (implement correct methods to retrieve dimensions)

[done] implement mapfiles for Mac OS X (Stephan Bergmann, Daniel Boelzle, Tino Rachui , Pavel Janik)

====alpha 0.02====

[done] modify libsalsystools.dylib to be correctly loaded with the bundle (ericb, + pjanik)

[done] add mouse drag events ( pjanik )

====alpha 0.01====

[done] add new feature for Aqua windows, to allow QuickTime player use( mox )

[done] replace obsolete code in salframe.cxx with (ericb)

[done] fix correct size for main window (GetOptimaWindowSize() ) (ericb)

[done] fix alpha channel in pixmaps (ismael)

====alpha 0.0====

[done] pushbutton where not correctly drawn (ericb)

[done] fix missing mouse events (pjanik)

[done] fix nRepeat in text entry (ssa)

2nd Mac porters Meeting

===Work in progress ===

URGENT :

Top of issues causing crashes : event issue when tips is enabled causes crashes ( well known window / handler / window desctructor / event loop bug )

Salatsuifontutils : replace old code, track leaks : tino

[done] Bitmaps : ( isma87)

[running] Crashes : (tino, pjanik, ericb, isma87, plipli )

[???] Drag and drop : (vijay)

[???] Printing (ybart)

Florian Heckl proposed a subject for Google Summer of Code about native printing

Drawing/ windowing ( plipli / ericb ) -> mainly refresh

[done] Implement cursor

[started] Native Controls (ericb)

[work in progress] partial multiline sallayout (plipli )

To do :

(started, Oliver) - modify the tree to make the bundle start without hack ( issue fixed during buildtime)

(started, Florian Heckl) verify Native FilePicker implementation ( works , tested in Hamburg )

[done] Ismael Merzaq) implement blit functions in salgdi ( important fix: probably apha version to be tested once done)

[done] Sebastien Plisson- update the missing functions list ( fonts ... ask hdu & cl

[started] ericb, Mox Soini, Sebastien Plisson, Tino Rachui, Pavel janik continue to replace obsolete code

fix crashes with menus (started : tino )

== '''Sort of documentation about VCL around Native Mac OS X port''' ==

Do we really need to understand how it works? ;-)

vcl content:

ls -laR | wc -l
1750

-> Uff 1750 files to analyse :-/

Our purpose is to describe the vcl organisation. The content of vcl is so important, that at the begining, the content will looks a bit confused. e.g. class names ..etc have nothing to do, only description with words and sense, but this will need some time before we can understand everything.

How analyse with more efficiency? After some months to anlalyse '''"horizontaly"''', it appears that list all the content of a directory is not the solution. Of course, we learned a lot, but we now have to complete with '''"orthogonal"''' method (compared to the previous one). The first method wasn't obviously not the good/best way to describe vcl.

[FIXME] a different approach (will ask confirmation to Philipp Lohman), could be a description of how it work in runtime. First define what an instance is, a frame, and what exactly is concerned by such "objects".

With that, we can write a list of different objects all using the same scheme: empty boxes (means pure virtual methods and classes in generic libvvcl), really implemented in the specific part, and finally, the API "encapsulated".

The most difficult is to see where the API is used. But for all the parts, this is the same.

Finally, '''what is important is the design of vcl'''. Which '''patterns''' are used? What are the dependencies, how works the stack for the events, how works the scheduler, the timers too is very important, even fundamental for Aqua implementation. Will have a look at gsl mailing list, and other resources. Probably everything is already (randomly) written somewhere.

=== VCL organisation ===

Thank's to Philipp Lohmann for this short, but precise description:

Basically vcl is divided in the system dependent and the system independent part. The interface between these two is mostly the Sal interface (every interface name Sal*: SalInstance, SalFrame, SalGraphics, SalPrinter, etc.).

SalInstance is a factory that can create all the other abstracted interfaces of the system dependent part. It also provides the main loop SalInstance::Yield()

SalFrame abstracts any kind of system window.

SalVirtualDevice abstracts an offscreen window (e.g. a Pixmap on X11)

SalPrinter and SalInfoPrinter abstract the system print queues where SalInfoPrinter is for querying and SalPrinter for actual printing.

SalGraphics is an interface produced by either SalFrame, SalVirtualDevice or SalPrinter which is used for actual drawing operations (text, bitmaps, vector graphics)

SalSound is for sound playing.

SalBitmap provides memory for bitmap graphics as well as methods converting this memory to a system handle (e.g. a Pixmap on X11).

SalOpenGL provides OpenGL functionality if available.

SalTimer is an interface for periodically triggering the event queue (to timer implementation).

SalI18NImeStatus handles how the status window of an Input Method Editor (IME) should display (this is mainly X11 specific).

SalSystem has some system specific methods that did not belong anywhere else:-)

Of all these there interfaces is at least one implementation per system (Windows, X11 or Mac). The Unix implementation also has a plugin concept to allow for integration of different native toolkits (currently gtk and Qt) which became necessary for the implementation of Native Widget Framework (NWF) to display controls like their normal desktop counterparts.

Basically the independent part (what is beneath vcl/source directory) has generic methods for drawing, window handling and stuff which it brings into a suitable form and then delegates to the system specific implementation (located beneath vcl/win for Windows and vcl/unx for the X11 platforms).

[[User:Ericb|Ericb]] 16:12, 1 July 2006 (CEST)

===Sub-directories description ===

==== '''Organisation of vcl directories''' ====

[[Image:aquavcl_organisation_complete_02.jpg]]

==== '''Directories in vcl. Short description''' ====

''' aqua ''': The name Aqua means Apple look and feel, and is well known as [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html Aqua Human Interface Guidelines]. This look and feel means Mac OS X. The work was begun by (probably) P. luby, Dan Williams Herbert Duerr (most of fonts stuff) and Ed Peterlin. Currently in ruin, this directory does contain a lot of ideas to investigate. The most important part of needed changes for native version (3.0) will be done inside aqua dir inc: does contain all vcl relative includes [PART1]

''' prj ''': Does contain build.lst and d.lst build.lst give us dependencies: probably a lot for vcl, build 98th module over ~148. Everything graphical depends in vcl.

''' qa ''' does contain all quality assurancy stuff

'''source''': the most important:-) This directory contains common sources for all architectures and OS. Mainly: Windows, Unix: Linux , Mac OS X (X11), Solaris, including generic, kde and gtk plugins, and Aqua (Mac OS X without X11, work currently in progress).

Depending on the OS and the architecture, binaries are built or not.

''' test ''': This directory does contain all the needed stuff for tests. As example, in qa/testdocuments, you'll find three documents (one writer, one calc and one impress) for tests purpose.
Other available tests are about memcheck and persistent window state.

''' unx ''': this directory does contain all unixes stuff. We have to understand what is inside to implement aqua port. For example, a lot of classes/strutures and objects use Xlib calls we have to replace with Carbon/Cocoa call (at least at first time) for Mac OS X native port.

''' win ''': Doing Mac OS X native port, I first believed this directory was not interesting for us, but I was wrong: OpenOffice.org roots are inside this directory, and a lot of comments and resources are inside. Mainly interesting if Carbon is used.

'''workben''': Does contain a toy called "svdem". svdem is a binary, used for new implementations. For example, actual aqua development uses svdem intensively, to verify all important properties we need:

- display a window first (al least ...:))

- close cleanly this window

- display a point

- trace a line

- trace an area

- superpose two areas doing some important graphical operations, (like xor),

- display a character

- display a menu.

- intercept events correctly.

[FIXME] add more tests

[[User:Ericb|Ericb]] 13:21, 3 June 2006 (CEST)

=='''Naming convention''' ==

* Class names start with upper case letters, to improve readability.

* Implemented Class names are derived from the virtual classes but can of course take arbitrary names.
To increase readability, it's recommended to closely follow the base class name.

* '''Impl prefix: means Implementation details'''. The concerned class or method or function is not used outside of this module, so no external code (or other libraries) can see it.

'''[[ Events types using Carbon API (Mac OS X): ]]''' A lot of events have to be managed in runtime. Here is a short description

- do not freeze because bad event loops

- event types implementation: currently, they are defined in vcl/aqua/inc/aquavclevents.hxx

Apart: exact sense of hedabu? -> [FIXME] as far as I understood it: it is like "copy" to deliver software into the solver, with extra magic. The header files for example are manipulated so paths need not be exact. "headabu" is supposed to disappear little by little.

== '''What do we have to build in vcl?'''==

Two libraries, corresponding ressources (localized) and a toy so called « svdem »

'''Common part''':

in grey on right. The result will be a non architecture dependant library, built in all cases: for instance, libvcl680mxi.dylib on Mac Intel.

'''Specific part " a plugin " ''':

Light yellow: aqua part will only concern Mac OS X (non X11) the name will probably be libvcl_aqua680mxi.dylib

As you can see, win means windows part, in blue

For Unix build (Linux, Solaris or current Mac OS X X11), in purple.

Result will be:

libvclplug_PLUGIN680mxi.DLLSUFFIX , where PLUGIN can be iether gen (generic) or gtk (using gtk+) or kde (using qt), and DLLSUFFIX can be either .so (linux) or .dylib (Mac OS X) ...etc (I'm not sure for other cases).

Example: libvcl680mxi.dylib and libvclplug_aqua680mxi.dylib

'''In runtime''', libvclplug_aqua will be linked to libvcl680. the first one will contain the real implementation (respecting the API, e.g. Carbon) while the generic libvcl will only contain pure virtual methods ...etc like "empty boxes".

=== Current Aqua content ===

A more complete description of aqua (Mac OS X / no X11 specific): [[Image:Vcl_aqua_organisation_02_tree.jpg]]

==EXISTING objects to build in aqua==

===Sal APP "everything application"===

[FIXME] add all objects descriptions

==== saldata ====

* '''Defined in plugin exclusively''' (i.e. for headers)

Unix: unx/source/app/saldata.cxx (header in unx/inc)

'''Aqua: aqua/source/app/saldata.cxx (header in win/inc)'''

Windows: win/source/app/saldata.cxx (header in aqua/inc)

* Role: saldata contains various kind of data used by the implementation for the concerned platform. '''It is a bunch of global data collections reserved for the platform'''

It is just completely platform dependent, and nobody except this plugin can see it.

'''Saldata is something like a "second sal", but providing an abstraction regarding windowing and graphics''', while SAL module provides an abstraction more Operating System oriented)

e.g. : have a look at XRequest array in vcl/unx/source/app/saldata.cxx => all calls are for Xlib (X11). Ok, useless there, but interesting:-)

[FIXME]: use Windows implementation could be a good starting point. Nothing is the same, but the current aquavcl cws uses similar objects, and it works very correctly.

saldatax.cxx uses classes SalInstance, SalObject, SalFrame, SalVirtualDevice, SalPrinter and fontList.

Current list of possible objects who can be instantiated/released:

structure SalData: does contain pointers on all kind of objects from other classes used in saldata.

inline functions: [FIXME]: complete the description

- SetSalData:
- GetSalData:
- GetAppSalData:

==== salinst ====

=> implemented in vcl/aqua/source/app/salinst.cxx

Role:

* get environment, mutexes, instantiate AquaSalInstance (Ctor, Dtor),

* instantiates/releases a lot of other objects using Get() / CreateObject() / DestroyObject() methods.

Current list of possible objects who can be instantiated/released:

* VirtualDevice [FIXME]: exact role?

*Printer

- GetDefaultPrinter/ CreatePrinter() / DestroyPrinter - what a name ;-) -

- InfoPrinter (Get/Create/Delete)

- PrinterQueue (DeletePrinterQueueInfo / GetPrinterQueueInfo / GetPrinterQueueState)

* System (Create / Delete) [FIXME]: what means system here?

* Events:

AquaSalInstance::SetEventCallback()

AquaSalInstance::SetErrorEvenCallback()

AquaSalInstance::GetConnectionIdentifier()

* Menu / MenuItem:

AquaSalInstance::CreateMenu() / same for DestroyMenu()

AquaSalInstance::CreateMenuItem / same DestroyMenuItem()

* Sound:

AquaSalInstance::CreateSalSound() => object to a pointer of SalSound type

Note: AquaSalInstance::DestroySalSound is not implemented (?)

* Timer: CreateTimer() /

AquaSalInstance:: DestroyTimer() is not yet implemented (?)

Class MacImeStatus: inherits of SalI18NImeStatus

-> only there to see if there is a window to toggle into menubar [FIXME]??

AquaSalInstance::CreateI18NImeStatus(): instantiates MacImeStatus

'''For futher informations, see: ''' '''[[Content of salinst.cxx]]'''

([[User:Ericb|Ericb]] 16:11, 20 May 2006 (CEST) )

==== salmain ====

Role: if possible, runs the standard vcl application code SVMain()

([[User:Ericb|Ericb]] 16:15, 20 May 2006 (CEST))

==== salsound ====

==== salsys ====

==== saltimer ====

==== saltimer ====

The main problem with SalTimer is the code we use is obsolete. To remove this deprecated code, sevarl work have been tried

1) Pavel Janik, in issue 75228

works, but a serious problem is remaining (a thread issue, nothing anybody explained yet)

2) eric bacahrd ( code will be attached soon )

3) Michael Sicotte, who proposed to work on that, and continue Pavel implementation.

SalTimer description

AquaSalTimerproc

AquaSalTimer::Start()

AquaSalTimer::Stop()

AquaSalTimer::Restart()

AquaSalTimer::Installtask() // yet needed ?

=== Sal GDI (everything Graphical Display Interface) ===

====salgdinativewidgets====

[[native controls]]

==== salatslayout ====

==> implemented in vcl/aqua/source/gdi/salatslayout.cxx

- Handle text layouting :

* Use ATSUI (ATSUCreateTextLayoutFromPtr) to layout the text unicode char buffer
* Use ATSUI (ATSU..) to get informations about glyphs
* Populate different arrays (mpGlyph2Chars, mpChars2Glyph, mpCharsWidths, mpGlyphAdvances)
that are used in various methods.

==== salatsuiutils ====

==== salfontutils ====

==== salmathutils ====

==== sal bmp ====

==== salvd ====

==== salpixmaputils====

==== salprn ====

====salrectangle====

==== salvd ====

=== Sal Window===

==== salframe ====
Documentation in progress, from damiend :
[[User:Damiend|Damiend page]]

====salobj====

== TO BE IMPLEMENTED (missing in Aqua)==

===Audio===

====audioconvert====
(obsolete?)

====devaudio====
(obsolete?)

====native sound====

====salimpsound====

====vsound====

===i18n===

===keysymnames===

===saldisp===

===sm===

[FIXME]: is session manager usefull?

=='''Native Controls'''==

====Scrollbar====

'''Works as expected'''. The most important work is done

See : [[Mac_OS_X_Porting_-_Native_Controls#ScrollBar]]

====DrawThemeButton() documentation====

'''Started'''

See : [[Mac_OS_X_Porting_-_Native_Controls#ComboBox]]

Started
<pre>
DrawThemeButton
Draws a button.

OSStatus DrawThemeButton (
const Rect * inBounds,
ThemeButtonKind inKind,
const ThemeButtonDrawInfo * inNewInfo,
const ThemeButtonDrawInfo * inPrevInfo,
ThemeEraseUPP inEraseProc,
ThemeButtonDrawUPP inLabelProc,
UInt32 inUserData
);
Parameters
inBounds
A pointer to a structure of type Rect. Pass a rectangle specifying the boundary of the button, in local coordinates.

inKind
A value of type ThemeButtonKind. Pass a constant specifying the type of button to draw.
See “Theme Buttons” for descriptions of possible values.

inNewInfo
A pointer to a structure of type ThemeButtonDrawInfo. Before calling DrawThemeButton,
set the structure to contain the new state, value, and adornment for the button.
DrawThemeButton uses the information passed in the inNewInfo and inPrevInfo parameters
to apply transitional animation or sound effects as the button state changes, if such are
specified under the current theme.

inPrevInfo
A pointer to a structure of type ThemeButtonDrawInfo. If the button state is changing,
set the structure to contain the previous state, value, and adornment for the button,
to allow DrawThemeButton to apply any transitional effects. If the button state is not
changing, you can pass NULL.

inEraseProc
A value of type ThemeEraseUPP. If you have a custom background, use this parameter to pass
a universal function pointer to an application-defined function such as that described in
ThemeEraseProcPtr. DrawThemeButton calls this function to erase the background before drawing
the button. If you pass NULL, DrawThemeButton's default behavior is to erase the background
for you.

inLabelProc
A value of type ThemeButtonDrawUPP. If you pass a universal function pointer to an
application-defined function such as that described in ThemeButtonDrawProcPtr, DrawThemeButton
calls that function to draw the label of the button. If you pass NULL, no label is drawn.

inUserData
An unsigned 32-bit integer. Provide any data to be passed in to the callback functions specified in
the inLabelProc and inEraseProc parameters. Pass NULL if you do not wish to provide any data.

Return Value
A result code. See “Appearance Manager Result Codes”.

Discussion
The DrawThemeButton function draws a theme-compliant button. If a ThemeEraseProcPtr is
specified in the inEraseProc parameter, DrawThemeButton uses that function to erase the
background of the button before drawing the button. After the button is drawn, if a
ThemeButtonDrawProcPtr is specified in the inLabelProc parameter, DrawThemeButton calls
that function to draw the button’s label.

Note that DrawThemeButton also draws any appearance adornments for the button and that these
can extend beyond the button’s basic bounding rectangle, as specified in the inBounds parameter,
and may be of variable shape. You may therefore wish to call the function
GetThemeButtonBackgroundBounds to obtain the actual rectangle containing the pixels belonging
to a button under the current theme.

Version Notes
This function is available with Appearance Manager 1.1 and later.

Availability
Available in CarbonLib 1.0 and later when Appearance 1.1 or later is present.
Available in Mac OS X 10.0 and later.
Declared In
Appearance.h
</pre>

====HIComboBoxCreate() documentation====

<pre>
HIComboBoxCreate
Creates a combo box control.

OSStatus HIComboBoxCreate (
const HIRect* boundsRect,
CFStringRef text,
const ControlFontStyleRec* style,
CFArrayRef list,
OptionBits inAttributes,
HIViewRef* outComboBox
);
Parameters
boundsRect
The bounding box of the control.

text
The default text in the editable portion of the control. Can be NULL.

style
The font style of the both editable text and the text in the disclosure list. Can be NULL.

list
The default values available in the disclosure list. Can be NULL.

inAttributes
The default attributes of the combo box. For possible values, see “Combo Box Attributes”.

outComboBox
On exit, a pointer to a reference for the new control.

Discussion
The combo box can be used in compositing mode, as well as traditional Control Manager mode.
When created, this view is invisible. To see the view, you must show the view by calling HIViewSetVisible.
</pre>

== What is used for Linux, Windows, Mac OS X ...build ? ==

'''[[Description of the dependencies]]'''

'''[[Windows]]'''

'''[[MacOS X]]'''

'''[[Linux]]'''

'''[[Solaris]]'''

== Content of Aqua ==

'''[[Click here to see the complete list]]'''

'''Content of vcl/inc'''

Notes:

1) Where to find includes

<foo/bar.hxx> means you can find bar.hxx in the foo module. The new style file is foo/inc/foo/bar.hxx, old style is foo/inc/bar.hxx and sometimes the file is somewhere else in the tree or generated. The deliver process copies/generates the file into solver at solver/680/build_type/inc/foo. Good for fixing broken builds. ;-)

2)
suffix .h (for C calls or first version?) or .hxx (C++)

'''A) Family of includes''':

Looking more closely at the list brings to the fore (expression from dictionary ;-) ) that include names are
informatives. Most of the time, the name gives the function/role.
What is interesting is the files with name begining with "sal". sal means System Abstraction Layer + include's function (or explicit name).

Partial list, for example:

salatype.hxx

salbmp.hxx

salctrlhandle.hxx

salctype.hxx

salframe.hxx

salgdi.hxx

salgeom.hxx

sallayout.hxx (main header for fonts services)
...
salmenu
salnativewidgets
...etc

Other important families are "sv" and "uno" or "win" (window) prefixed. sal family will be analysed apart.

'''B) Includes of includes'''

Some includes are more important than other. To prove this, just have a look is sufficient: some are always needed, and some more rarely.

To verify, a simple test to do in vcl/inc:

egrep -H "#include" ./* | wc -l gives me 681 lines ! And some of them are the same...

To know more, the precedent command line can be modified to make appear the numerous call
to the same includes files.

egrep -H "#include" ./* | cut -d"#" -f2 | sort > liste.txt

The content of liste.txt is explicit: dllapi.h, sv.h and some other are very important, while some other includes are only one or two times used. We can see too that vos includes are numerous, even if vos is deprecated**

**see http://wiki.services.openoffice.org/wiki/Source_code_directories

I'm nearly sure that a complete analysis of just this result will give us a lot of information.

I propose to change the order of analysis starting with dllapi.h and sv.h.

[to be continued]

'''B1) "sal" includes family'''

[[salinst.hxx]] This seems to be the main include file

[[salatype.hxx]]

[[salctrlhandle.hxx]]

[[salctype.hxx]]

[[salframe.hxx]]

[[salgdi.hxx]]

[[salgeom.hxx]]

'''[[ sallayout.hxx ]]''' <-- see Native Fonts implementation

[[salgtype.hxx]]

[[vcl/inc/salobj.hxx]]

'''B2) Classicals includes'''

file: abstdlg.hxx [ means abstract dialog ]

This includes does contain the following classes definitions:

[FIXME] : choose a precise presentation template for classes

VclAbstractDialog,

VclAbstractTerminateDialog,

VclAbstractRefreshableDialog,

VclAbstractDialogFactory,

uses <tools/solar.h> , <tools/string.hxx> +

"dllapi.h"

Note : dllapi.h is very interesting because when we have to find (for example) a library suffix, SAL_DLLEXTENSSION can replace all suffixes (every OS's and archs). Just including sal/config.h does it !

Classes:

Window -> what? [FIXME]
ResId -> what?

Does contain the prototype of VclAbstractDialog, inherit of VCL_DLLPUBLIC

file: dllapi.h [ dll for dynamic linked library ]
Uses: <sal/config.h> and >sal/types/h>
includes: VCL_DLLPUBLIC macro

file: accel.h [ means accelerator ]

Classes:

Accelerator
{
}
ImplAccelEntry
{
public members:

Names

mnId
maKeyCode
mpAccel
mpAutoAccel
mbEnabled
}

function / returns / parameters

ImplGetKeyCode / void / KeyFuncType eFunc, ref rCode1 , ref rCode2, ref rCode3

file: accel.hxx

Uses: <sv.h> , "dllapi.h" ,<tools/resid.hxx>, <<tools/rc.hxx>

Classes:

ImplAccelData;
ImplAccelEntry;

== Important Links ==
'''[[Progressive implementation]]'''

'''Native Font server Implementation''' '''[[Mac OS X Porting - Native Fonts]]'''

'''Native Sound Implementation''': [[Mac OS X Porting - Native Audio and Video]]

'''Native Printing Implementation''': [[Mac OS X Porting - Native_Printing]]

'''Drag and Drop implementation''': [[Mac OS X Porting - Native Drag and drop]]

'''Data Acquisition''' : [[Mac OS X Porting - Data Acquisition]]

This work is part of http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s

[to be continued:-) ]

== Keyboard comparizon between OpenOffice.org / Mac OS X application ==

[FIXME] redo a cleanest array

{| style="vertical-align:top; text-align:centered; background-color:#F0F0F0;"
|- style="background-color:#99CCFF; font-weight:bold;"
| Modifier||+ key || Result || TextEdit returns
|-
|ALT|| a||æ ||æ
|-
|ALT||b||ß ||ß
|-
|ALT||c||© ||©
|-
|ALT||d||∂ ||∂
|-
|ALT||e||ê ||ê
|-
|ALT||f||ƒ ||ƒ
|-
|ALT||g ||ﬁ ||ﬁ
|-
|ALT||h ||Ì ||Ì
|-
|ALT||i ||î ||î
|-
|ALT||j ||Ï ||Ï
|-
|ALT||k ||È ||È
|-
|ALT||l ||¬ ||¬
|-
|ALT||m ||µ ||µ
|-
|ALT||n ||~ ||~
|-
|ALT||o ||œ ||œ
|-
|ALT||p ||π ||π
|-
|ALT||q ||‡ ||‡
|-
|ALT||r ||® ||®
|-
|ALT||s ||Ò ||Ò
|-
|ALT||t ||† ||†
|-
|ALT||u ||º ||º
|-
|ALT||v ||◊ ||◊
|-
|ALT||w ||‹ ||‹
|-
|ALT||x ||≈ ||≈
|-
|ALT||y ||Ú ||Ú
|-
|ALT||z ||Â ||Â
|-
|ALT||A ||Æ ||Æ
|-
|ALT||B ||∫ ||∫
|-
|ALT||C ||¢ ||¢
|-
|ALT||D||∆||∆
|-
|ALT||F ||· ||·
|-
|ALT||G ||ﬂ ||ﬂ
|-
|ALT||H ||Î ||Î
|-
|ALT||I ||Î ||Î
|-
|ALT||J ||Í ||Í
|-
|ALT||K ||Ë ||Ë
|-
|ALT||L || <pre>|</pre> ||<pre>|</pre>
|-
|ALT||M ||Ó ||Ó
|-
|ALT||N ||ı ||ı
|-
|ALT||O ||Œ ||Œ
|-
|ALT||P ||∏ ||∏
|-
|ALT||Q ||Ω ||Ω
|-
|ALT||R ||‚ ||‚
|-
|ALT||S ||∑ ||∑
|-
|ALT||T ||™ ||™
|-
|ALT||U ||ª ||ª
|-
|ALT||V ||√ ||√
|-
|ALT||W ||› ||›
|-
|ALT||X ||⁄ ||⁄
|-
|ALT||Y ||Ÿ ||Ÿ
|-
|ALT||Z ||Å ||Å
|-
|ALT||$ ||€ ||€
|-
|ALT||` ||@ ||@
|-
|ALT||£ ||# ||#
|-
|ALT||* ||¥ ||¥
|}

Sous réserve d'erreur ou omission [[User:Ericb|Ericb]] 00:05, 14 January 2007 (CET)

--[[User:Ericb|Ericb]] 15:00, 22 Jul 2005 (EDT)

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

User:Ericb

2007-04-25T20:12:15Z

Plipli: /* '''Interesting Labs''' */

==Public Documentation License Notice==

The contents of this Documentation (excepted Native Port Roadmap),are subject to the Public Documentation License Version 1.0 (the "License"); you may only use this Documentation if you comply with the terms of this License. A copy of the License is available at http://www.openoffice.org/licenses/PDL.html.
The Original Documentation is "Mac OS X native port". The Initial Writer of the Original Documentation is (JCA) Eric Bachard (C) 2005-2006. All Rights Reserved. (Initial Writer contact(s): ericb@openoffice.org.)

=='''Mac OS X Native port'''==

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">
'''The first Mac OS X native port objective is make OpenOffice.org run without X11 use, to make it a real Mac application.'''

'''The second one is respect Aqua Human interface Guidelines'''

''' This is a long term work, and every help and/or contributions, like donations** are welcome.'''
</div>

**see http://contributing.openoffice.org/index.html

=='''Native Port Roadmap'''==

==='''2006'''===

* June 2006: work in progress

- Basis: frame, instances, threads, drawing, painting, resizing (Stephan Schaefer, Tino Rachui)

Done:
implement threads
create, manage instance
create, manage windows (including parents)
create, manage events
create manage drawing, resizing
create, add menus (Pavel Janik)
toggle window fullscreen (Pierre de Filippis)
make font server work (Stephan Schaefer)

* Current status font support (Stephan Schaefer, 2006/07/28): the following features are basically working now
** font selection
** font size
** simple font attributes (bold, italic)

Next step: document first part, and propose design

- native filepicker (Pavel Janik, Florian Heckl)

- native printing implementation (Oliver?)

- native font implementation (Eric Bachard)

* September 2006:

- first proofs of concept: fonts, filepicker .. (more?)
- show the results (OOoCon 2006?)

==='''2007'''===

* January 2007: first alpha implementation

=='''Strategy for native port'''==

'''Possible Actions''':

Identify us:

#Complete the arrays below
#Update photos on frapr.com?

Share the work:

#Divide the work between little Teams
#Update Todo list regularly -> needs some love these days ... [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s]

Help:

#Teach tools between us
#Do a debug party on IRC
#write documentation

Meet us:

#IRC
#Mac Meeting (like nov2005 in Hamburg?)

Inform:

#Update website regularly
#Blogs

'''WHO''':

Mac Team:

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
|Developer \ skills || build || write code || code review || debug/trace (higher is better) || contribute to documentation ||
|-
|ericb|| x || x || || 1 || x ||
|-
|pjanik|| || || || || ||
|-
|ssa|| || || || || ||
|-
|maho|| || || || || ||
|-
|tinor|| || || || || ||
|-
|schmidtm|| || || || || ||
|-
|ebischoff|| || || || || ||
|-
|obr|| || || || || ||
|-
|cl|| || || || || ||
|-
|aliscafo|| || || || || ||
|-
|fheckl|| || || || || ||
|-
|Fridrich|| || || || || ||
|-
|plipli|| || x || || || x ||
|-
|}

'''Other resources''':

fonts: ?

events: ?

QA: James McKenzie leads QA for the Mac OS X port of OpenOffice.org and is looking for volunteers to spread this effort over several people and needs people from all over the world to test various languages.

graphical: ?

Communication: ?

'''WHAT''': Status of most important tasks

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
| Task || Names|| Urgency (1=higher)|| Work in Progress || Done || Code review || Debug || Integration ||
|-
|Get rid of X11||done || 1 || x || x || || || ||
|-
|Bundle|| || 1 || x || || || || | ||
|-
|Drawing|| || 1 || x || || || || || ||
|-
|Fonts||plipli || 1 || x || || || || || ||
|-
|Events management|| || 2 || x || || || || || ||
|-
|Controls (see list) ||ericb, aliscafo || 2 || x || || || || || ||
|-
|Native FilePicker||Florian Heckl, Pavel Janik || 3 || x || x || || || || ||
|-
|Native Printing||Yvan Barthelemy || 3 || x || || || || || ||
|-
|Native SpellChecker|| || 4 || || || || || || ||
|-
|Player||Mox Soini || 4 || x || || || || || ||
|}

Other tasks:

Help for writing bug lists, status of bugs ..etc

Write howto use gdb, leaks, other tools

'''WHEN''':

From Christian Lippka (last meeting, 25th of august 2006):
Aug 26 00:21:38 ChristianL
from my point of view what is missing for point 1:
text layout, complete font support, keyboard support,
fixing repaint issues, having aqua install and run out of the box

'''September 2006'''

Present the current state of the project at the 2006 OpenOffice conference in Lyon and Paris

'''Late 2006'''

fix OpenOffice.org launch
fix drawing (repainting)
Implement missing methods and fix most important bugs (mainly the one leading to crash) in:
ATS
Salgraphics
Salinstance

'''January or February 2007'''

make Java work (works partially)
make intensive debug
present something working as alpha

'''June 2007 '''

Implementation of:
native filepicker
native printing

== '''Become a Domain Developer for Mac OS X port''' ==

People regularly contributing to Mac OS x port with regular and quality patches are, after proposal, invited to become a [[DomainDeveloper]].

The purpose of this document is to clearly define all the steps to become a [[DomainDeveloper]].

Preliminary : step 1 in [[Commit_Rights]] must be completed and checked, and you must be in the list of [[http://www.openoffice.org/FAQs/faq-licensing.html#jca1 JCA Licensed people]]

=== Steps for ssh2 key to be uploaded ===

==== Create the key ====

Everything is described here : [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

==== Upload the key ====

You must create an issue, like described below :

Component : www

Sub Component : openoffice.org cvs

Title : CVS Commit access request

Add louis ( Louis Suarez Potts) or st ( Stefan Taxhet ) on CC

Upload your ssh2 public key respecting the process ( Attach a DSA key, not an RSA )

A project lead will confirm your request

Then the support will upload your key

Once done the issue is set to Fixed , and the next step has to be verified before '''you''' close it.

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75291 Upload SSH2 Key for Etsushi Kato]]

==== Verify it works ====

You now can try to connect via tunnel, and follow instructions given [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

If something goes wrong, ask for help to support, with a maximum of details, to solve the problem.

Once it works, the issue can be closed, and you can e.g. test downloading a module from tunnel repository :

First create a tunnel with the command:
<pre>
ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org
</pre>

Then in a new window:

<pre>
export CVSROOT=":pserver:your_login@localhost:/cvs"

cvs login ( enter )

(your password )

mkdir TEST

cd TEST

cvs -z4 co -r SRC680_m205 vcl

cd vcl

cat CVS/Root -> should indicate : your local repository
</pre>

=== Ask for CVS access for all modules required ===

Two steps : create an issue is mandatory because the concerned project is tools, and because people can have only ssh2 key without being [[DomainDeveloper]].

==== Create an issue ====

You must create an issue, described below :

Component : tools

Sub Component : www

Title : CVS access to all modules required

Assigned to mh + CC for ericb and/or pjanik

Present yourself quickly, and ask the access

A project lead will confirm

An admin will confirm this is ok, and set the issue to Fixed

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75494 CVS Access all modules for Etsushi Kato]]

==== Verify ====

Create the tunnel :

open a terminal and type :

ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org

once logged in, open a new terminal, and do ( for example ):
<pre>
cd $OOO_SRC_ROOT/

source MacOSXPPCEnv.Set.sh { source MacOSXX86Env.Set.sh for Mac Intel }

cd vcl ( for example )

IMPORTANT : be sure vcl has been checked from tunnel, not from anoncvs ( cat CVS/Root will give you the answer )

export CWS_WORK_STAMP=aquavcl01 # Only needed for working with [[EIS]], can change for a different CWS ;)

cd aqua/source/gdi

add your changes to your_file.cxx, then commit :

cvs commit -m "#i75689# bla bla ... the reason of the modification(s)" your_file.cxx # The #i75689# is an issue number in the tracker

cvs update

If nothing is wrong, cvs update should not return M for your_file.cxx, means the commit is successfull.
</pre>
In case of problem, use the issue until it is fixed

<big>'''Welcome aboard :)'''</big>

== '''Mac OS X porter Team at WWDC 2007''' ==

=== What is WWDC 2007 ? ===

See [http://developer.apple.com/wwdc/ Apple WWDC 2007]

====Labs Agenda====

It is extremely important to organize us for Labs.

The rule is extremely simple : bring your laptop, your code, and ask :)

{| border="1" cellpadding="10"
| Days
|monday<br>June 11
|tuesday<br>June 12
|wednesday<br>June 13
|thursday<br>June 14
|friday <br>June 15
|-
|Labs
|<br>Afternoon
|Morning<br>Afternoon
|Morning<br>Afternoon
|Morning<br>Afternoon
|Morning<br>Afternoon
|}

===='''Interesting Labs'''====

The complete list : [http://developer.apple.com/wwdc/tracks/macosx.html Mac OS X Essentials]

*Core Text Lab
Receive one-on-one technical assistance and troubleshooting advice from the Core Text engineering team. Learn how to use the advanced font handling and blazingly fast Unicode layout capabilities of Core Text. Bring your laptop, your code, and your questions.

*HIToolbox Lab
Work on tuning and debugging HIToolbox code in your Carbon application. Receive one-on-one technical assistance and troubleshooting advice from the High Level Toolbox engineering team, Apple DTS engineers, and technology evangelists. Bring your laptop, your code, and your questions.

=== Our Objectives at the WWDC 2007 ===

1) Contacts with Apple's teams :

* Present our current work, methods and team to Apple people, easy to meet only during WWDC ( Apple people can give us a face, and keep the contact )

=> There is information difficult to find or ask by email, or IRC or whatever web : direct contact saves a lot of time, and is a very efficient way to progress with code

* Get their impression about what we have already done and what is still ToDo

2) Mac Team's goals on Aqua OOo -> Apple's Expertise :

* "Give MacOS X users the OOo suite they deserve" :

=> As mac platform and apple's product fans, we are proud to bring the quality and power of OOo to mac users community
=> Make OOo uses all the power of Mac OSX, including upcoming Leopard !

* "OOo to be as Apple HIG compliant as possible" :

=> Define what is expected for User Interface with people from Apple UI project

- FYI : Last year, Apple UI project proposed ericb to help us, once our native menus will be working.

This is now done, and meet them cannot be a bad idea :)

3) Get code guidelines, tips, samples :

=> Ask for code review and find code snippets for :

- HIView
- Printing
- Drag and Drop
+ more if possible

=> More than 1000 Apple engineers are present, and can answer our questions regarding the code, during the whole week

During WWDC2006 we found all the relevant informations for RunApplicationEventLoop() to be implemented . Without this code, we wouldn't have something working at all, because this event loop is the key for everything in OpenOffice.org on Mac OS X ( without X11 ).

4) Social Contract : Discuss and meet new developers and / or american people working for Mac OS X port (like Michael Sicotte, Vijay Venkatraman , other.. )

5) Visibility : make OpenOffice.org project visible in an ocean of other software. This is extremely important because it shows that OpenOffice.org project is alive for Mac OS X platform.

=== Who ? ===

* Sébastien Plisson
* Eric Bachard
* ???

=== Todo list ===

Please add topics, technical questions you would see asked by attendees to Apple engineers during WWDC

====Suggestions for current issues to be fixed ====

Timers :

Current code is obsolete, and compatibility with Leopard won't probably exist.

Pavel wrote a patch using recent code. Seems to work fine, excepted a thread issue ( never crashed because of that yet , but this is probably correct)

Salframe :

Looot of things :

*Find infos/code sample about parenting

*Code review for HIFrameWork implementation

*adapt native widget framework

Events : code review, tips

ATS : code review, ATS issues

Mike Sicotte:
I understood that implementing printing in aqua OOo was a topic that we didn't get accepted into Google SOC - so remains on the ToDo list. I notice that there are three Sessions specfically related to printing at WWDC:
Leveraging the Common Unix Printing System (CUPS)
Printing with Style in Mac OS X
Printing Lab
If this is judged to be a good use of time at WWDC I would be willing to spend some time to help further develop the questions to be addressed with the Apple engineers.

ericb->Mike Sicotte

Good idea. You are welcome :)

==== Misc ====

*describe the schedule of the travel

ericb :
<pre>
Mulhouse -> Paris -> SF : 9th of June SF scheduled arrival : 7:13 pm
SF -> Paris -> Mulhouse : 16th of June ( arrival 17th ) SF departure for the return : 3:00 pm

Hotel : King Georges ( close to Union Square )

Airport to Hotel transportation : not included
</pre>

sebastien :

[to be completed]

third attendee :

[to be completed]

*Prepare 50 to 100 business cards :

the most simple is to use the model I can provide on demand , and print them with special paper ( pre-cut )

== '''Mac OS X porter Team at OOoCon 2007''' ==

=== Who ? ===

* Shaun McDonald
* Eric Bachard
* (list to be completed)

=== What ? ===

The conference is over 3 days. Presentations should last around 45 minutes. http://www.openoffice.org/servlets/ReadMsg?list=announce&msgNo=320 Papers have to be submitted by 1st June to be considered.

Ideas :

Mike Sicotte: Perhaps the results of the Google SOC could be a presentation.

*create a complete topic for Mac port (one stream for a day or half day)
*How to improve ooo usability though the use of floating palettes instead of modal dialogs

- several presentations / BOF

Eric Bachard : Aqua OpenOffice.org ( conf / 1 hour )

Others ?

*reserve rooms together ? Better rent a house?

* [FIXME]

=='''2nd Mac porters meeting'''==

This section has been moved to [[2nd Mac porters meeting]]

=='''IRC Mac port meetings'''==

This section has been moved to [[MacOSXPortMeetings]].

== '''Mac OS X (X11) Quality Assurance'''==

This section has been moved to [[Mac OS X ( X11) Quality Assurance]]

== '''Mac OS X Implementing HIView and Carbon events'''==

This section has been moved to [[Mac OS X Implementing HIView ]]

== '''Debug OpenOffice.org using XCode '''==

[[ MacOSX Debug OpenOffice.org using XCode]]

=='''Description of the Native Port problem'''==

=== How does OpenOffice.org work on Mac OS X? ===

Currently, on Mac OS X, OpenOffice.org uses X11, as "client": X11 is a graphical server, coming from Unix world, and able to run under Linux, *BSD, Solaris, Mac OS X.

- X11 is run as an application, managed like other Apple applications.
- All unix like applications are managed by X11, and from Aqua environment, only X11 is seen as only one applicatiion,
even if other Unix/Linux (e.g.) applications are runing.

OpenOffice.org asks X11 to display a window, waits for X11 acknowledgment, and OpenOffice.org displays the window. All transactions use the network, locally or not. the same mechanism is used for everything to be displayed.

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=== Issues and known problems ===

All events are managed by OpenOffice.org and X11, using the Xlib

Only .ttf fonts type is currently available. Note: '''system fonts are available '''

The rendering is made by X11, not by Mac OS X rendering engine.

X11 and all its clients are seen as one application only: drag and drop protocol does not work because of that (solution: Pasteboard Manager)

==== Other links ====

http://wiki.services.openoffice.org/wiki/List_of_OpenOffice.org_Mac_OS_X_issues_and_problems#

http://wiki.services.openoffice.org/wiki/Printing_problems_with_OpenOffice.org_2.0_for_Mac_OS_X#Reporting_printing_problems

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

== What do we have to do?==

* (in progress) : Implement direct access to Apple graphical engine, using Apple API: Quartz2D/CoreGraphics (and replacing Xlib use)

like: instantiate, manage events and threads for a graphical instance + all needed objects, drawing: manage all drawing cases

* (in progress) : Implement native events management, using CarbonEventManager (replacing Xlib management)

* (in progress) : Implement native font use, using Apple Type Server and ATSUI (for Unicode Imagery) (replacing X11 management)

Work in progress: [[Mac OS X Porting - Native Fonts]]

* Implement native sound, using QuickTime (replacing Java Media Framework): [[Mac OS X Porting - Native Audio and Video]]

* Implement native Drag and drop, Implementing Pasteboard Manager: [[Mac OS X Porting - Native Drag and drop]]

* (done experimental) Implement Native Filepicker

* Implement Native Printing: current uses cups, but native printing is mandatory: [[Mac OS X Porting - Native_Printing]]

* Implement Apple Spellchecker

--[[User:Plipli|Plipli]] 09:27, 25 March 2007 (CEST)

=='''Where is located the code to be modified?'''==

Most of the changes are located in vcl (Visual Class Layer), for everything graphical, events, fonts, rendering and printing.

Other, for sound and movies will be in avmedia (where the player is implemented in OpenOffice.org sources).

For drag and drop, dtrans is concerned (Pasteboard Manager implementation)

[FIXME]: Filepicker? Apple Spellchecker?

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=='''How will the new implementation be tested?==

Currently, all openOffice.org code can be compiled without using the Xlib. but of course, a lot of features are missing,

and the final package simply won't work

In vcl module", a '''toy''' called svdem is built at buildtime. This binary is linked to libvcl* and so all new stuff can be tested.

e.g. : draw anti-aliased lines works well.

Everything implemented in aqua vcl code will be included in libvclplug_aqua, and svdem source code will contain a specific part to proceed tests.

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">

'''The magic is: when all needed features will work with svdem, it will work in the new version of OpenOffice.org !!'''

</div>

[FIXME]: add more complete list of features to implement and test.

== AquaVCL 01 cws ==

[[http://qa.openoffice.org/issues/buglist.cgi?keywords=aqua Top 10 of Aqua issues]]

[[Aquavcl01 tasks]]

===Changelog ===

====Work in progresss : alpha 0.6 ====

Started (19th March ) :

Michael Sicotte proposed to investigate in timers, and continue [[http://www.openoffice.org/issues/show_bug.cgi?id=75228 Pavel's work]] : objective is to replace obsolete code. ( 23th March)

[experimental] plipli proposed a patch for a new salframe implementation, using HIView + optionally compositing (21th March )

[commit scheduled] Michael Sicotte proposed a complete patch for invert() ( SAL_INVERT SAL_INVERT_50 and SAL_INVERT_TRACKFRAME ) (20th March )

Tino proposed to work on code cleanup in salatsuifontutils.cxx, removing obsolete code

ismael and michael work on invert() + drawAlphaRect()

Damien started to work on drawEPS()

plipli and ericb work on refresh

==== alpha 0.5====

Top 10 Summary : 7 issues over 10 are fixed or very close to be :

'''time to code review, tracing, and search for memory leaks'''

[done] Unicode input in salframe ( ekato ) ( 19th March )

[experimental, works partially] beginning of HIView + HIComboxes works (text still missing) (ericb + plipli) ( 14th March )

[done] replace NewRgn() in salframe (ericb (11th March )

[experimental, but very interesting] Improved native windows ( ismael ) ( 7th March )

====alpha 0.4====

'''[Informative]''' build runs with Leopard 9A377a ( fheckl ) ( 7th March )

Refresh screen issues (plipli) (4th to 10th March )

'''[informative]''' plipli announced progress with refresh screen issues ( 28th February )

[experimental, not yet commited] Proxy configuration from system ( pjanik) ( 28th February )

[done] highlighted native button ( pjanik) ( 27th February )

Native File Picker works ( fheckl / pjanik ) ( 23th February )

====alpha 0.3====

Cursor does appear -> invert() + setting a setBlinkTime value in UpdateSettings() (pjanik /ericb )

[done] mirroring negative images (ismael) + DrawAlphaBitmap() + CreateWithMask()

pjanik patch for Focus Events

[done] scrolling works ( pjanik ) (17th February )

[done ] carret works ( plipli) (17th February )

[done] checkbuttons fix for checkmarks (ericb) ( 17th February )

'''[Informative]''' Pavel Janik propose to solve offScreen buffer using HIView ( 17th February )

[experimental, never commited] patch for macosxrc.txt use + UpdateSettings() use in salframe.cxx ( ericb ( 16th February )

Michael Sicotte joined the Team ( 15th February )

invert() : first try (ericb) ( 13th february )

====alpha 0.2====

[12th February 2007 ]

[done] calc does not start : bug identified by tino , first workaround (ericb) [[http://www.openoffice.org/issues/show_bug.cgi?id=73691 issue 73691]]

[done] bitmaps in native popup menus (ismael)

[done] replace obsolete code for HandleWindowPaintEvent(), newRgn() .. etc (ericb) (12th February)

correct salatslayout patch (plipli) ( 11th February)

'''[Informative]''' Michel Renon proposed a summary about his work on fonts issues

[patch] Pavel fixed several menu crashes (09th February )

'''[Informative]''' : Pavel posted a mail about several crashes origin

patch for radioboxes and checkboxes ( ericb ) (9th February)

first complete patch for salatslayout.cxx ( plipli) ( 9th February )

[done] most important crashes fixed ( pjanik) ( 09th february )

Modified baseline for 2.2. : Mac OS X10.4 -> Aqua will be 10.4 and 10.5 compatible only ( ericb)

first try with multi line sallayout (plipli ) ( 08th February )

Damien Duportal joined the Team ( 7th February )

[done] scrollbar changes (ericb ) ( 4th February )

====alpha 0.1====

create Top 10 of issues before alpha 3rd February 2007 : See : [[http://porting.openoffice.org/mac/news/2007/20070203toptenbeforealpha.html Top 10 of issues]]

[experimental, not commited] patch for TPT() implementation (ericb) ( 2nd February 2007 )

Pavel Janik proposed to implement TransformProcessType() ( 2nd February 2007 )

[not commited] implement UpdateSettings() (ericb)

Pavel Janik resynchronized aquavel01 cws with m202 ( 2nd February 2007 )

====alpha 0.03====

Michel Renon joined the Team (1st February )

[done] fix checkbuttons and radiobuttons issues: offsets, redrawing of the check marks ( ericb)

[done] fix scrollbar buttons (implement correct methods to retrieve dimensions)

[done] implement mapfiles for Mac OS X (Stephan Bergmann, Daniel Boelzle, Tino Rachui , Pavel Janik)

====alpha 0.02====

[done] modify libsalsystools.dylib to be correctly loaded with the bundle (ericb, + pjanik)

[done] add mouse drag events ( pjanik )

====alpha 0.01====

[done] add new feature for Aqua windows, to allow QuickTime player use( mox )

[done] replace obsolete code in salframe.cxx with (ericb)

[done] fix correct size for main window (GetOptimaWindowSize() ) (ericb)

[done] fix alpha channel in pixmaps (ismael)

====alpha 0.0====

[done] pushbutton where not correctly drawn (ericb)

[done] fix missing mouse events (pjanik)

[done] fix nRepeat in text entry (ssa)

2nd Mac porters Meeting

===Work in progress ===

URGENT :

Top of issues causing crashes : event issue when tips is enabled causes crashes ( well known window / handler / window desctructor / event loop bug )

Salatsuifontutils : replace old code, track leaks : tino

[done] Bitmaps : ( isma87)

[running] Crashes : (tino, pjanik, ericb, isma87, plipli )

[???] Drag and drop : (vijay)

[???] Printing (ybart)

Florian Heckl proposed a subject for Google Summer of Code about native printing

Drawing/ windowing ( plipli / ericb ) -> mainly refresh

[done] Implement cursor

[started] Native Controls (ericb)

[work in progress] partial multiline sallayout (plipli )

To do :

(started, Oliver) - modify the tree to make the bundle start without hack ( issue fixed during buildtime)

(started, Florian Heckl) verify Native FilePicker implementation ( works , tested in Hamburg )

[done] Ismael Merzaq) implement blit functions in salgdi ( important fix: probably apha version to be tested once done)

[done] Sebastien Plisson- update the missing functions list ( fonts ... ask hdu & cl

[started] ericb, Mox Soini, Sebastien Plisson, Tino Rachui, Pavel janik continue to replace obsolete code

fix crashes with menus (started : tino )

== '''Sort of documentation about VCL around Native Mac OS X port''' ==

Do we really need to understand how it works? ;-)

vcl content:

ls -laR | wc -l
1750

-> Uff 1750 files to analyse :-/

Our purpose is to describe the vcl organisation. The content of vcl is so important, that at the begining, the content will looks a bit confused. e.g. class names ..etc have nothing to do, only description with words and sense, but this will need some time before we can understand everything.

How analyse with more efficiency? After some months to anlalyse '''"horizontaly"''', it appears that list all the content of a directory is not the solution. Of course, we learned a lot, but we now have to complete with '''"orthogonal"''' method (compared to the previous one). The first method wasn't obviously not the good/best way to describe vcl.

[FIXME] a different approach (will ask confirmation to Philipp Lohman), could be a description of how it work in runtime. First define what an instance is, a frame, and what exactly is concerned by such "objects".

With that, we can write a list of different objects all using the same scheme: empty boxes (means pure virtual methods and classes in generic libvvcl), really implemented in the specific part, and finally, the API "encapsulated".

The most difficult is to see where the API is used. But for all the parts, this is the same.

Finally, '''what is important is the design of vcl'''. Which '''patterns''' are used? What are the dependencies, how works the stack for the events, how works the scheduler, the timers too is very important, even fundamental for Aqua implementation. Will have a look at gsl mailing list, and other resources. Probably everything is already (randomly) written somewhere.

=== VCL organisation ===

Thank's to Philipp Lohmann for this short, but precise description:

Basically vcl is divided in the system dependent and the system independent part. The interface between these two is mostly the Sal interface (every interface name Sal*: SalInstance, SalFrame, SalGraphics, SalPrinter, etc.).

SalInstance is a factory that can create all the other abstracted interfaces of the system dependent part. It also provides the main loop SalInstance::Yield()

SalFrame abstracts any kind of system window.

SalVirtualDevice abstracts an offscreen window (e.g. a Pixmap on X11)

SalPrinter and SalInfoPrinter abstract the system print queues where SalInfoPrinter is for querying and SalPrinter for actual printing.

SalGraphics is an interface produced by either SalFrame, SalVirtualDevice or SalPrinter which is used for actual drawing operations (text, bitmaps, vector graphics)

SalSound is for sound playing.

SalBitmap provides memory for bitmap graphics as well as methods converting this memory to a system handle (e.g. a Pixmap on X11).

SalOpenGL provides OpenGL functionality if available.

SalTimer is an interface for periodically triggering the event queue (to timer implementation).

SalI18NImeStatus handles how the status window of an Input Method Editor (IME) should display (this is mainly X11 specific).

SalSystem has some system specific methods that did not belong anywhere else:-)

Of all these there interfaces is at least one implementation per system (Windows, X11 or Mac). The Unix implementation also has a plugin concept to allow for integration of different native toolkits (currently gtk and Qt) which became necessary for the implementation of Native Widget Framework (NWF) to display controls like their normal desktop counterparts.

Basically the independent part (what is beneath vcl/source directory) has generic methods for drawing, window handling and stuff which it brings into a suitable form and then delegates to the system specific implementation (located beneath vcl/win for Windows and vcl/unx for the X11 platforms).

[[User:Ericb|Ericb]] 16:12, 1 July 2006 (CEST)

===Sub-directories description ===

==== '''Organisation of vcl directories''' ====

[[Image:aquavcl_organisation_complete_02.jpg]]

==== '''Directories in vcl. Short description''' ====

''' aqua ''': The name Aqua means Apple look and feel, and is well known as [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html Aqua Human Interface Guidelines]. This look and feel means Mac OS X. The work was begun by (probably) P. luby, Dan Williams Herbert Duerr (most of fonts stuff) and Ed Peterlin. Currently in ruin, this directory does contain a lot of ideas to investigate. The most important part of needed changes for native version (3.0) will be done inside aqua dir inc: does contain all vcl relative includes [PART1]

''' prj ''': Does contain build.lst and d.lst build.lst give us dependencies: probably a lot for vcl, build 98th module over ~148. Everything graphical depends in vcl.

''' qa ''' does contain all quality assurancy stuff

'''source''': the most important:-) This directory contains common sources for all architectures and OS. Mainly: Windows, Unix: Linux , Mac OS X (X11), Solaris, including generic, kde and gtk plugins, and Aqua (Mac OS X without X11, work currently in progress).

Depending on the OS and the architecture, binaries are built or not.

''' test ''': This directory does contain all the needed stuff for tests. As example, in qa/testdocuments, you'll find three documents (one writer, one calc and one impress) for tests purpose.
Other available tests are about memcheck and persistent window state.

''' unx ''': this directory does contain all unixes stuff. We have to understand what is inside to implement aqua port. For example, a lot of classes/strutures and objects use Xlib calls we have to replace with Carbon/Cocoa call (at least at first time) for Mac OS X native port.

''' win ''': Doing Mac OS X native port, I first believed this directory was not interesting for us, but I was wrong: OpenOffice.org roots are inside this directory, and a lot of comments and resources are inside. Mainly interesting if Carbon is used.

'''workben''': Does contain a toy called "svdem". svdem is a binary, used for new implementations. For example, actual aqua development uses svdem intensively, to verify all important properties we need:

- display a window first (al least ...:))

- close cleanly this window

- display a point

- trace a line

- trace an area

- superpose two areas doing some important graphical operations, (like xor),

- display a character

- display a menu.

- intercept events correctly.

[FIXME] add more tests

[[User:Ericb|Ericb]] 13:21, 3 June 2006 (CEST)

=='''Naming convention''' ==

* Class names start with upper case letters, to improve readability.

* Implemented Class names are derived from the virtual classes but can of course take arbitrary names.
To increase readability, it's recommended to closely follow the base class name.

* '''Impl prefix: means Implementation details'''. The concerned class or method or function is not used outside of this module, so no external code (or other libraries) can see it.

'''[[ Events types using Carbon API (Mac OS X): ]]''' A lot of events have to be managed in runtime. Here is a short description

- do not freeze because bad event loops

- event types implementation: currently, they are defined in vcl/aqua/inc/aquavclevents.hxx

Apart: exact sense of hedabu? -> [FIXME] as far as I understood it: it is like "copy" to deliver software into the solver, with extra magic. The header files for example are manipulated so paths need not be exact. "headabu" is supposed to disappear little by little.

== '''What do we have to build in vcl?'''==

Two libraries, corresponding ressources (localized) and a toy so called « svdem »

'''Common part''':

in grey on right. The result will be a non architecture dependant library, built in all cases: for instance, libvcl680mxi.dylib on Mac Intel.

'''Specific part " a plugin " ''':

Light yellow: aqua part will only concern Mac OS X (non X11) the name will probably be libvcl_aqua680mxi.dylib

As you can see, win means windows part, in blue

For Unix build (Linux, Solaris or current Mac OS X X11), in purple.

Result will be:

libvclplug_PLUGIN680mxi.DLLSUFFIX , where PLUGIN can be iether gen (generic) or gtk (using gtk+) or kde (using qt), and DLLSUFFIX can be either .so (linux) or .dylib (Mac OS X) ...etc (I'm not sure for other cases).

Example: libvcl680mxi.dylib and libvclplug_aqua680mxi.dylib

'''In runtime''', libvclplug_aqua will be linked to libvcl680. the first one will contain the real implementation (respecting the API, e.g. Carbon) while the generic libvcl will only contain pure virtual methods ...etc like "empty boxes".

=== Current Aqua content ===

A more complete description of aqua (Mac OS X / no X11 specific): [[Image:Vcl_aqua_organisation_02_tree.jpg]]

==EXISTING objects to build in aqua==

===Sal APP "everything application"===

[FIXME] add all objects descriptions

==== saldata ====

* '''Defined in plugin exclusively''' (i.e. for headers)

Unix: unx/source/app/saldata.cxx (header in unx/inc)

'''Aqua: aqua/source/app/saldata.cxx (header in win/inc)'''

Windows: win/source/app/saldata.cxx (header in aqua/inc)

* Role: saldata contains various kind of data used by the implementation for the concerned platform. '''It is a bunch of global data collections reserved for the platform'''

It is just completely platform dependent, and nobody except this plugin can see it.

'''Saldata is something like a "second sal", but providing an abstraction regarding windowing and graphics''', while SAL module provides an abstraction more Operating System oriented)

e.g. : have a look at XRequest array in vcl/unx/source/app/saldata.cxx => all calls are for Xlib (X11). Ok, useless there, but interesting:-)

[FIXME]: use Windows implementation could be a good starting point. Nothing is the same, but the current aquavcl cws uses similar objects, and it works very correctly.

saldatax.cxx uses classes SalInstance, SalObject, SalFrame, SalVirtualDevice, SalPrinter and fontList.

Current list of possible objects who can be instantiated/released:

structure SalData: does contain pointers on all kind of objects from other classes used in saldata.

inline functions: [FIXME]: complete the description

- SetSalData:
- GetSalData:
- GetAppSalData:

==== salinst ====

=> implemented in vcl/aqua/source/app/salinst.cxx

Role:

* get environment, mutexes, instantiate AquaSalInstance (Ctor, Dtor),

* instantiates/releases a lot of other objects using Get() / CreateObject() / DestroyObject() methods.

Current list of possible objects who can be instantiated/released:

* VirtualDevice [FIXME]: exact role?

*Printer

- GetDefaultPrinter/ CreatePrinter() / DestroyPrinter - what a name ;-) -

- InfoPrinter (Get/Create/Delete)

- PrinterQueue (DeletePrinterQueueInfo / GetPrinterQueueInfo / GetPrinterQueueState)

* System (Create / Delete) [FIXME]: what means system here?

* Events:

AquaSalInstance::SetEventCallback()

AquaSalInstance::SetErrorEvenCallback()

AquaSalInstance::GetConnectionIdentifier()

* Menu / MenuItem:

AquaSalInstance::CreateMenu() / same for DestroyMenu()

AquaSalInstance::CreateMenuItem / same DestroyMenuItem()

* Sound:

AquaSalInstance::CreateSalSound() => object to a pointer of SalSound type

Note: AquaSalInstance::DestroySalSound is not implemented (?)

* Timer: CreateTimer() /

AquaSalInstance:: DestroyTimer() is not yet implemented (?)

Class MacImeStatus: inherits of SalI18NImeStatus

-> only there to see if there is a window to toggle into menubar [FIXME]??

AquaSalInstance::CreateI18NImeStatus(): instantiates MacImeStatus

'''For futher informations, see: ''' '''[[Content of salinst.cxx]]'''

([[User:Ericb|Ericb]] 16:11, 20 May 2006 (CEST) )

==== salmain ====

Role: if possible, runs the standard vcl application code SVMain()

([[User:Ericb|Ericb]] 16:15, 20 May 2006 (CEST))

==== salsound ====

==== salsys ====

==== saltimer ====

==== saltimer ====

The main problem with SalTimer is the code we use is obsolete. To remove this deprecated code, sevarl work have been tried

1) Pavel Janik, in issue 75228

works, but a serious problem is remaining (a thread issue, nothing anybody explained yet)

2) eric bacahrd ( code will be attached soon )

3) Michael Sicotte, who proposed to work on that, and continue Pavel implementation.

SalTimer description

AquaSalTimerproc

AquaSalTimer::Start()

AquaSalTimer::Stop()

AquaSalTimer::Restart()

AquaSalTimer::Installtask() // yet needed ?

=== Sal GDI (everything Graphical Display Interface) ===

====salgdinativewidgets====

[[native controls]]

==== salatslayout ====

==> implemented in vcl/aqua/source/gdi/salatslayout.cxx

- Handle text layouting :

* Use ATSUI (ATSUCreateTextLayoutFromPtr) to layout the text unicode char buffer
* Use ATSUI (ATSU..) to get informations about glyphs
* Populate different arrays (mpGlyph2Chars, mpChars2Glyph, mpCharsWidths, mpGlyphAdvances)
that are used in various methods.

==== salatsuiutils ====

==== salfontutils ====

==== salmathutils ====

==== sal bmp ====

==== salvd ====

==== salpixmaputils====

==== salprn ====

====salrectangle====

==== salvd ====

=== Sal Window===

==== salframe ====
Documentation in progress, from damiend :
[[User:Damiend|Damiend page]]

====salobj====

== TO BE IMPLEMENTED (missing in Aqua)==

===Audio===

====audioconvert====
(obsolete?)

====devaudio====
(obsolete?)

====native sound====

====salimpsound====

====vsound====

===i18n===

===keysymnames===

===saldisp===

===sm===

[FIXME]: is session manager usefull?

=='''Native Controls'''==

====Scrollbar====

'''Works as expected'''. The most important work is done

See : [[Mac_OS_X_Porting_-_Native_Controls#ScrollBar]]

====DrawThemeButton() documentation====

'''Started'''

See : [[Mac_OS_X_Porting_-_Native_Controls#ComboBox]]

Started
<pre>
DrawThemeButton
Draws a button.

OSStatus DrawThemeButton (
const Rect * inBounds,
ThemeButtonKind inKind,
const ThemeButtonDrawInfo * inNewInfo,
const ThemeButtonDrawInfo * inPrevInfo,
ThemeEraseUPP inEraseProc,
ThemeButtonDrawUPP inLabelProc,
UInt32 inUserData
);
Parameters
inBounds
A pointer to a structure of type Rect. Pass a rectangle specifying the boundary of the button, in local coordinates.

inKind
A value of type ThemeButtonKind. Pass a constant specifying the type of button to draw.
See “Theme Buttons” for descriptions of possible values.

inNewInfo
A pointer to a structure of type ThemeButtonDrawInfo. Before calling DrawThemeButton,
set the structure to contain the new state, value, and adornment for the button.
DrawThemeButton uses the information passed in the inNewInfo and inPrevInfo parameters
to apply transitional animation or sound effects as the button state changes, if such are
specified under the current theme.

inPrevInfo
A pointer to a structure of type ThemeButtonDrawInfo. If the button state is changing,
set the structure to contain the previous state, value, and adornment for the button,
to allow DrawThemeButton to apply any transitional effects. If the button state is not
changing, you can pass NULL.

inEraseProc
A value of type ThemeEraseUPP. If you have a custom background, use this parameter to pass
a universal function pointer to an application-defined function such as that described in
ThemeEraseProcPtr. DrawThemeButton calls this function to erase the background before drawing
the button. If you pass NULL, DrawThemeButton's default behavior is to erase the background
for you.

inLabelProc
A value of type ThemeButtonDrawUPP. If you pass a universal function pointer to an
application-defined function such as that described in ThemeButtonDrawProcPtr, DrawThemeButton
calls that function to draw the label of the button. If you pass NULL, no label is drawn.

inUserData
An unsigned 32-bit integer. Provide any data to be passed in to the callback functions specified in
the inLabelProc and inEraseProc parameters. Pass NULL if you do not wish to provide any data.

Return Value
A result code. See “Appearance Manager Result Codes”.

Discussion
The DrawThemeButton function draws a theme-compliant button. If a ThemeEraseProcPtr is
specified in the inEraseProc parameter, DrawThemeButton uses that function to erase the
background of the button before drawing the button. After the button is drawn, if a
ThemeButtonDrawProcPtr is specified in the inLabelProc parameter, DrawThemeButton calls
that function to draw the button’s label.

Note that DrawThemeButton also draws any appearance adornments for the button and that these
can extend beyond the button’s basic bounding rectangle, as specified in the inBounds parameter,
and may be of variable shape. You may therefore wish to call the function
GetThemeButtonBackgroundBounds to obtain the actual rectangle containing the pixels belonging
to a button under the current theme.

Version Notes
This function is available with Appearance Manager 1.1 and later.

Availability
Available in CarbonLib 1.0 and later when Appearance 1.1 or later is present.
Available in Mac OS X 10.0 and later.
Declared In
Appearance.h
</pre>

====HIComboBoxCreate() documentation====

<pre>
HIComboBoxCreate
Creates a combo box control.

OSStatus HIComboBoxCreate (
const HIRect* boundsRect,
CFStringRef text,
const ControlFontStyleRec* style,
CFArrayRef list,
OptionBits inAttributes,
HIViewRef* outComboBox
);
Parameters
boundsRect
The bounding box of the control.

text
The default text in the editable portion of the control. Can be NULL.

style
The font style of the both editable text and the text in the disclosure list. Can be NULL.

list
The default values available in the disclosure list. Can be NULL.

inAttributes
The default attributes of the combo box. For possible values, see “Combo Box Attributes”.

outComboBox
On exit, a pointer to a reference for the new control.

Discussion
The combo box can be used in compositing mode, as well as traditional Control Manager mode.
When created, this view is invisible. To see the view, you must show the view by calling HIViewSetVisible.
</pre>

== What is used for Linux, Windows, Mac OS X ...build ? ==

'''[[Description of the dependencies]]'''

'''[[Windows]]'''

'''[[MacOS X]]'''

'''[[Linux]]'''

'''[[Solaris]]'''

== Content of Aqua ==

'''[[Click here to see the complete list]]'''

'''Content of vcl/inc'''

Notes:

1) Where to find includes

<foo/bar.hxx> means you can find bar.hxx in the foo module. The new style file is foo/inc/foo/bar.hxx, old style is foo/inc/bar.hxx and sometimes the file is somewhere else in the tree or generated. The deliver process copies/generates the file into solver at solver/680/build_type/inc/foo. Good for fixing broken builds. ;-)

2)
suffix .h (for C calls or first version?) or .hxx (C++)

'''A) Family of includes''':

Looking more closely at the list brings to the fore (expression from dictionary ;-) ) that include names are
informatives. Most of the time, the name gives the function/role.
What is interesting is the files with name begining with "sal". sal means System Abstraction Layer + include's function (or explicit name).

Partial list, for example:

salatype.hxx

salbmp.hxx

salctrlhandle.hxx

salctype.hxx

salframe.hxx

salgdi.hxx

salgeom.hxx

sallayout.hxx (main header for fonts services)
...
salmenu
salnativewidgets
...etc

Other important families are "sv" and "uno" or "win" (window) prefixed. sal family will be analysed apart.

'''B) Includes of includes'''

Some includes are more important than other. To prove this, just have a look is sufficient: some are always needed, and some more rarely.

To verify, a simple test to do in vcl/inc:

egrep -H "#include" ./* | wc -l gives me 681 lines ! And some of them are the same...

To know more, the precedent command line can be modified to make appear the numerous call
to the same includes files.

egrep -H "#include" ./* | cut -d"#" -f2 | sort > liste.txt

The content of liste.txt is explicit: dllapi.h, sv.h and some other are very important, while some other includes are only one or two times used. We can see too that vos includes are numerous, even if vos is deprecated**

**see http://wiki.services.openoffice.org/wiki/Source_code_directories

I'm nearly sure that a complete analysis of just this result will give us a lot of information.

I propose to change the order of analysis starting with dllapi.h and sv.h.

[to be continued]

'''B1) "sal" includes family'''

[[salinst.hxx]] This seems to be the main include file

[[salatype.hxx]]

[[salctrlhandle.hxx]]

[[salctype.hxx]]

[[salframe.hxx]]

[[salgdi.hxx]]

[[salgeom.hxx]]

'''[[ sallayout.hxx ]]''' <-- see Native Fonts implementation

[[salgtype.hxx]]

[[vcl/inc/salobj.hxx]]

'''B2) Classicals includes'''

file: abstdlg.hxx [ means abstract dialog ]

This includes does contain the following classes definitions:

[FIXME] : choose a precise presentation template for classes

VclAbstractDialog,

VclAbstractTerminateDialog,

VclAbstractRefreshableDialog,

VclAbstractDialogFactory,

uses <tools/solar.h> , <tools/string.hxx> +

"dllapi.h"

Note : dllapi.h is very interesting because when we have to find (for example) a library suffix, SAL_DLLEXTENSSION can replace all suffixes (every OS's and archs). Just including sal/config.h does it !

Classes:

Window -> what? [FIXME]
ResId -> what?

Does contain the prototype of VclAbstractDialog, inherit of VCL_DLLPUBLIC

file: dllapi.h [ dll for dynamic linked library ]
Uses: <sal/config.h> and >sal/types/h>
includes: VCL_DLLPUBLIC macro

file: accel.h [ means accelerator ]

Classes:

Accelerator
{
}
ImplAccelEntry
{
public members:

Names

mnId
maKeyCode
mpAccel
mpAutoAccel
mbEnabled
}

function / returns / parameters

ImplGetKeyCode / void / KeyFuncType eFunc, ref rCode1 , ref rCode2, ref rCode3

file: accel.hxx

Uses: <sv.h> , "dllapi.h" ,<tools/resid.hxx>, <<tools/rc.hxx>

Classes:

ImplAccelData;
ImplAccelEntry;

== Important Links ==
'''[[Progressive implementation]]'''

'''Native Font server Implementation''' '''[[Mac OS X Porting - Native Fonts]]'''

'''Native Sound Implementation''': [[Mac OS X Porting - Native Audio and Video]]

'''Native Printing Implementation''': [[Mac OS X Porting - Native_Printing]]

'''Drag and Drop implementation''': [[Mac OS X Porting - Native Drag and drop]]

'''Data Acquisition''' : [[Mac OS X Porting - Data Acquisition]]

This work is part of http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s

[to be continued:-) ]

== Keyboard comparizon between OpenOffice.org / Mac OS X application ==

[FIXME] redo a cleanest array

{| style="vertical-align:top; text-align:centered; background-color:#F0F0F0;"
|- style="background-color:#99CCFF; font-weight:bold;"
| Modifier||+ key || Result || TextEdit returns
|-
|ALT|| a||æ ||æ
|-
|ALT||b||ß ||ß
|-
|ALT||c||© ||©
|-
|ALT||d||∂ ||∂
|-
|ALT||e||ê ||ê
|-
|ALT||f||ƒ ||ƒ
|-
|ALT||g ||ﬁ ||ﬁ
|-
|ALT||h ||Ì ||Ì
|-
|ALT||i ||î ||î
|-
|ALT||j ||Ï ||Ï
|-
|ALT||k ||È ||È
|-
|ALT||l ||¬ ||¬
|-
|ALT||m ||µ ||µ
|-
|ALT||n ||~ ||~
|-
|ALT||o ||œ ||œ
|-
|ALT||p ||π ||π
|-
|ALT||q ||‡ ||‡
|-
|ALT||r ||® ||®
|-
|ALT||s ||Ò ||Ò
|-
|ALT||t ||† ||†
|-
|ALT||u ||º ||º
|-
|ALT||v ||◊ ||◊
|-
|ALT||w ||‹ ||‹
|-
|ALT||x ||≈ ||≈
|-
|ALT||y ||Ú ||Ú
|-
|ALT||z ||Â ||Â
|-
|ALT||A ||Æ ||Æ
|-
|ALT||B ||∫ ||∫
|-
|ALT||C ||¢ ||¢
|-
|ALT||D||∆||∆
|-
|ALT||F ||· ||·
|-
|ALT||G ||ﬂ ||ﬂ
|-
|ALT||H ||Î ||Î
|-
|ALT||I ||Î ||Î
|-
|ALT||J ||Í ||Í
|-
|ALT||K ||Ë ||Ë
|-
|ALT||L || <pre>|</pre> ||<pre>|</pre>
|-
|ALT||M ||Ó ||Ó
|-
|ALT||N ||ı ||ı
|-
|ALT||O ||Œ ||Œ
|-
|ALT||P ||∏ ||∏
|-
|ALT||Q ||Ω ||Ω
|-
|ALT||R ||‚ ||‚
|-
|ALT||S ||∑ ||∑
|-
|ALT||T ||™ ||™
|-
|ALT||U ||ª ||ª
|-
|ALT||V ||√ ||√
|-
|ALT||W ||› ||›
|-
|ALT||X ||⁄ ||⁄
|-
|ALT||Y ||Ÿ ||Ÿ
|-
|ALT||Z ||Å ||Å
|-
|ALT||$ ||€ ||€
|-
|ALT||` ||@ ||@
|-
|ALT||£ ||# ||#
|-
|ALT||* ||¥ ||¥
|}

Sous réserve d'erreur ou omission [[User:Ericb|Ericb]] 00:05, 14 January 2007 (CET)

--[[User:Ericb|Ericb]] 15:00, 22 Jul 2005 (EDT)

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T13:00:00Z

Plipli: /* HIFramework integration and benefits */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

'''In progress :'''<br>
- plipli : '''HIFramework''' integration : compiled, to be cleaned up before testing delivery to mac@porting ;
- ericb/ismael : salnativewidget - create and bind '''native controls''' (HIViews) (ericb) and '''HIWindow''' (ismael);

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework integration and benefits ==
--[[User:Plipli|Plipli]] 15:00, 25 April 2007 (CEST)

* '''''Origin''''' : Issued from Apple samples

* '''''Pros''''' :
- use recent API code, <br>
- given with many helpers and set/getters to manage data and events<br>
- easily adaptable to use new services coming with Leopard (MacOSX 0.5)<br>
- up/down compatibility wit hdifferent MacOSX versions<br>
- hiobject registering system : low couplage with the utility classes of HIFramework<br>

* '''''Cons''''' :
- ?? too nice to be true :-)

* '''''Step by step''''' :
'''1''' - When any HIObject is created in salframe/salnativewidget (AquaSalFrame / AquaSalGraphics) it will be
registered to HIFramework base classes ;<br>
'''2a''' - Being registered gives this instance of HIView/HIWindow access to helpers/setters/getters methods ;<br>
'''2b''' - Event handling is highly centralized/factored : create, initialize, draw... ;<br>
'''3''' - Allmost all possible data / events is covered by HIFramework and will be easily used, as new controls are implemented in salnativewidget ;<br>

* '''''Conclusion''''' :
- Let's clean it, test it and enjoy fastest implementation of Aqua native controls !! (GsoC fun ;-)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T12:58:57Z

Plipli: /* HIFramework integration and benefits */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

'''In progress :'''<br>
- plipli : '''HIFramework''' integration : compiled, to be cleaned up before testing delivery to mac@porting ;
- ericb/ismael : salnativewidget - create and bind '''native controls''' (HIViews) (ericb) and '''HIWindow''' (ismael);

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework integration and benefits ==

----

* '''''Origin''''' : Issued from Apple samples

* '''''Pros''''' :
- use recent API code, <br>
- given with many helpers and set/getters to manage data and events<br>
- easily adaptable to use new services coming with Leopard (MacOSX 0.5)<br>
- up/down compatibility wit hdifferent MacOSX versions<br>
- hiobject registering system : low couplage with the utility classes of HIFramework<br>

* '''''Cons''''' :
- ?? too nice to be true :-)

* '''''Step by step''''' :
'''1''' - When any HIObject is created in salframe/salnativewidget (AquaSalFrame / AquaSalGraphics) it will be
registered to HIFramework base classes ;<br>
'''2a''' - Being registered gives this instance of HIView/HIWindow access to helpers/setters/getters methods ;<br>
'''2b''' - Event handling is highly centralized/factored : create, initialize, draw... ;<br>
'''3''' - Allmost all possible data / events is covered by HIFramework and will be easily used, as new controls are implemented in salnativewidget ;<br>

* '''''Conclusion''''' :
- Let's clean it, test it and enjoy fastest implementation of Aqua native controls !! (GsoC fun ;-)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T12:58:14Z

Plipli: /* HIFramework integration and benefits */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

'''In progress :'''<br>
- plipli : '''HIFramework''' integration : compiled, to be cleaned up before testing delivery to mac@porting ;
- ericb/ismael : salnativewidget - create and bind '''native controls''' (HIViews) (ericb) and '''HIWindow''' (ismael);

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework integration and benefits ==

* '''''Origin''''' : Issued from Apple samples

* '''''Pros''''' :
- use recent API code, <br>
- given with many helpers and set/getters to manage data and events<br>
- easily adaptable to use new services coming with Leopard (MacOSX 0.5)<br>
- up/down compatibility wit hdifferent MacOSX versions<br>
- hiobject registering system : low couplage with the utility classes of HIFramework<br>

* '''''Cons''''' :
- ?? too nice to be true :-)

* '''''Step by step''''' :
'''1''' - When any HIObject is created in salframe/salnativewidget (AquaSalFrame / AquaSalGraphics) it will be
registered to HIFramework base classes ;<br>
'''2a''' - Being registered gives this instance of HIView/HIWindow access to helpers/setters/getters methods ;<br>
'''2b''' - Event handling is highly centralized/factored : create, initialize, draw... ;<br>
'''3''' - Allmost all possible data / events is covered by HIFramework and will be easily used, as new controls are implemented in salnativewidget ;<br>

* '''''Conclusion''''' :
- Let's clean it, test it and enjoy fastest implementation of Aqua native controls !! (GsoC fun ;-)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T12:57:50Z

Plipli: /* HIFramework integration and benefits */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

'''In progress :'''<br>
- plipli : '''HIFramework''' integration : compiled, to be cleaned up before testing delivery to mac@porting ;
- ericb/ismael : salnativewidget - create and bind '''native controls''' (HIViews) (ericb) and '''HIWindow''' (ismael);

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework integration and benefits ==

* '''''Origin''''' : Issued from Apple samples

* '''''Pros''''' :
- use recent API code,
- given with many helpers and set/getters to manage data and events
- easily adaptable to use new services coming with Leopard (MacOSX 0.5)
- up/down compatibility wit hdifferent MacOSX versions
- hiobject registering system : low couplage with the utility classes of HIFramework

* '''''Cons''''' :
- ?? too nice to be true :-)

* '''''Step by step''''' :
'''1''' - When any HIObject is created in salframe/salnativewidget (AquaSalFrame / AquaSalGraphics) it will be
registered to HIFramework base classes ;<br>
'''2a''' - Being registered gives this instance of HIView/HIWindow access to helpers/setters/getters methods ;<br>
'''2b''' - Event handling is highly centralized/factored : create, initialize, draw... ;<br>
'''3''' - Allmost all possible data / events is covered by HIFramework and will be easily used, as new controls are implemented in salnativewidget ;<br>

* '''''Conclusion''''' :
- Let's clean it, test it and enjoy fastest implementation of Aqua native controls !! (GsoC fun ;-)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T12:57:23Z

Plipli: /* HIFramework integration and benefits */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

'''In progress :'''<br>
- plipli : '''HIFramework''' integration : compiled, to be cleaned up before testing delivery to mac@porting ;
- ericb/ismael : salnativewidget - create and bind '''native controls''' (HIViews) (ericb) and '''HIWindow''' (ismael);

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework integration and benefits ==

* '''''Origin''''' : Issued from Apple samples

* '''''Pros''''' :
- use recent API code,
- given with many helpers and set/getters to manage data and events
- easily adaptable to use new services coming with Leopard (MacOSX 0.5)
- up/down compatibility wit hdifferent MacOSX versions
- hiobject registering system : low couplage with the utility classes of HIFramework

* '''''Cons''''' :
- ?? too nice to be true :-)

* '''''Step by step''''' :
'''1''' - When any HIObject is created in salframe/salnativewidget (AquaSalFrame / AquaSalGraphics) it will be
registered to HIFramework base classes ;
'''2a''' - Being registered gives this instance of HIView/HIWindow access to helpers/setters/getters methods ;
'''2b''' - Event handling is highly centralized/factored : create, initialize, draw... ;
'''3''' - Allmost all possible data / events is covered by HIFramework and will be easily used, as new controls are implemented in salnativewidget ;

* '''''Conclusion''''' :
- Let's clean it, test it and enjoy fastest implementation of Aqua native controls !! (GsoC fun ;-)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T12:56:58Z

Plipli: /* HIFramework integration and benefits */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

'''In progress :'''<br>
- plipli : '''HIFramework''' integration : compiled, to be cleaned up before testing delivery to mac@porting ;
- ericb/ismael : salnativewidget - create and bind '''native controls''' (HIViews) (ericb) and '''HIWindow''' (ismael);

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework integration and benefits ==

* '''''Origin''''' : Issued from Apple samples

* '''''Pros''''' :
- use recent API code,
- given with many helpers and set/getters to manage data and events
- easily adaptable to use new services coming with Leopard (MacOSX 0.5)
- up/down compatibility wit hdifferent MacOSX versions
- hiobject registering system : low couplage with the utility classes of HIFramework

* '''''Cons''''' :
- ?? too nice to be true :-)

* '''''Step by step''''' :
'''1''' - When any HIObject is created in salframe/salnativewidget (AquaSalFrame / AquaSalGraphics) it will be
registered to HIFramework base classes
'''2a''' - Being registered gives this instance of HIView/HIWindow access to helpers/setters/getters methods
'''2b''' - Event handling is highly centralized/factored : create, initialize, draw...
'''3''' - Allmost all possible data / events is covered by HIFramework and will be easily used, as new controls are implemented in salnativewidget

* '''''Conclusion''''' :
- Let's clean it, test it and enjoy fastest implementation of Aqua native controls !! (GsoC fun ;-)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T12:55:36Z

Plipli: /* VCL / AQUA traces deductions (ericb) */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

'''In progress :'''<br>
- plipli : '''HIFramework''' integration : compiled, to be cleaned up before testing delivery to mac@porting ;
- ericb/ismael : salnativewidget - create and bind '''native controls''' (HIViews) (ericb) and '''HIWindow''' (ismael);

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework integration and benefits ==

* Origin : Issued from Apple samples

* Pros :
- use recent API code,
- given with many helpers and set/getters to manage data and events
- easily adaptable to use new services coming with Leopard (MacOSX 0.5)
- up/down compatibility wit hdifferent MacOSX versions
- hiobject registering system : low couplage with the utility classes of HIFramework

* Cons :
- ?? too nice to be true :-)

* Step by step :
1 - When any HIObject is created in salframe/salnativewidget (AquaSalFrame / AquaSalGraphics) it will be
registered to HIFramework base classes
2a - Being registered gives this instance of HIView/HIWindow access to helpers/setters/getters methods
2b - Event handling is highly centralized/factored : create, initialize, draw...
3 - Allmost all possible data / events is covered by HIFramework and will be easily used, as new controls are implemented in salnativewidget

* Conclusion :
- Let's clean it, test it and enjoy fastest implementation of Aqua native controls !! (GsoC fun ;-)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T12:55:21Z

Plipli: /* Reengineer Events handling (plipli) */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

'''In progress :'''<br>
- plipli : '''HIFramework''' integration : compiled, to be cleaned up before testing delivery to mac@porting ;
- ericb/ismael : salnativewidget - create and bind '''native controls''' (HIViews) (ericb) and '''HIWindow''' (ismael);

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework integration and benefits ==

* Origin : Issued from Apple samples

* Pros :
- use recent API code,
- given with many helpers and set/getters to manage data and events
- easily adaptable to use new services coming with Leopard (MacOSX 0.5)
- up/down compatibility wit hdifferent MacOSX versions
- hiobject registering system : low couplage with the utility classes of HIFramework

* Cons :
- ?? too nice to be true :-)

* Step by step :
1 - When any HIObject is created in salframe/salnativewidget (AquaSalFrame / AquaSalGraphics) it will be
registered to HIFramework base classes
2a - Being registered gives this instance of HIView/HIWindow access to helpers/setters/getters methods
2b - Event handling is highly centralized/factored : create, initialize, draw...
3 - Allmost all possible data / events is covered by HIFramework and will be easily used, as new controls are implemented in salnativewidget

* Conclusion :
- Let's clean it, test it and enjoy fastest implementation of Aqua native controls !! (GsoC fun ;-)

== VCL / AQUA traces deductions (ericb) ==
1)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T12:51:27Z

Plipli: /* HIFramework */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

'''In progress :'''<br>
- plipli : '''HIFramework''' integration : compiled, to be cleaned up before testing delivery to mac@porting ;
- ericb/ismael : salnativewidget - create and bind '''native controls''' (HIViews) (ericb) and '''HIWindow''' (ismael);

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework integration and benefits ==

* Origin : Issued from Apple samples

* Pros :
- use recent API code,
- given with many helpers and set/getters to manage data and events
- easily adaptable to use new services coming with Leopard (MacOSX 0.5)
- up/down compatibility wit hdifferent MacOSX versions
- hiobject registering system : low couplage with the utility classes of HIFramework

* Cons :
- ?? too nice to be true :-)

* Step by step :
1 - When any HIObject is created in salframe/salnativewidget (AquaSalFrame / AquaSalGraphics) it will be
registered to HIFramework base classes
2a - Being registered gives this instance of HIView/HIWindow access to helpers/setters/getters methods
2b - Event handling is highly centralized/factored : create, initialize, draw...
3 - Allmost all possible data / events is covered by HIFramework and will be easily used, as new controls are implemented in salnativewidget

* Conclusion :
- Let's clean it, test it and enjoy fastest implementation of Aqua native controls !! (GsoC fun ;-)

== Reengineer Events handling (plipli) ==

Main files : salframe.cxx, salframe.h, aquavclevents.hxx

Description :

In OOo, the class SalFrame defines the object containing :
- a window
- other objects related to window management system

AquaSalFrame is the native implementation of VCL Salframe.

== VCL / AQUA traces deductions (ericb) ==
1)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T12:43:00Z

Plipli: /* Introduction */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

'''In progress :'''<br>
- plipli : '''HIFramework''' integration : compiled, to be cleaned up before testing delivery to mac@porting ;
- ericb/ismael : salnativewidget - create and bind '''native controls''' (HIViews) (ericb) and '''HIWindow''' (ismael);

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework ==

== Reengineer Events handling (plipli) ==

Main files : salframe.cxx, salframe.h, aquavclevents.hxx

Description :

In OOo, the class SalFrame defines the object containing :
- a window
- other objects related to window management system

AquaSalFrame is the native implementation of VCL Salframe.

== VCL / AQUA traces deductions (ericb) ==
1)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T12:42:13Z

Plipli: /* Introduction */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

== In progress :<br>
- plipli : HIFramework integration : compiled, to be cleaned up before testing delivery to mac@porting ;
- ericb/ismael : salnativewidget - create and bind native controls (ericb) and HIWindow (ismael); ==

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework ==

== Reengineer Events handling (plipli) ==

Main files : salframe.cxx, salframe.h, aquavclevents.hxx

Description :

In OOo, the class SalFrame defines the object containing :
- a window
- other objects related to window management system

AquaSalFrame is the native implementation of VCL Salframe.

== VCL / AQUA traces deductions (ericb) ==
1)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-04-25T12:40:12Z

Plipli: /* Introduction */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

In progress :
- plipli : HIFramework integration : compiled, to be cleaned up before testing delivery to mac@porting
- ericb/ismael : salnativewidget - create and bind native controls (ericb) and HIWindow (ismael)

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== HIFramework ==

== Reengineer Events handling (plipli) ==

Main files : salframe.cxx, salframe.h, aquavclevents.hxx

Description :

In OOo, the class SalFrame defines the object containing :
- a window
- other objects related to window management system

AquaSalFrame is the native implementation of VCL Salframe.

== VCL / AQUA traces deductions (ericb) ==
1)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

User:Ericb

2007-04-22T18:56:58Z

Plipli: /* '''Mac OS X porter Team at WWDC 2007''' */

==Public Documentation License Notice==

The contents of this Documentation (excepted Native Port Roadmap),are subject to the Public Documentation License Version 1.0 (the "License"); you may only use this Documentation if you comply with the terms of this License. A copy of the License is available at http://www.openoffice.org/licenses/PDL.html.
The Original Documentation is "Mac OS X native port". The Initial Writer of the Original Documentation is (JCA) Eric Bachard (C) 2005-2006. All Rights Reserved. (Initial Writer contact(s): ericb@openoffice.org.)

=='''Mac OS X Native port'''==

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">
'''The first Mac OS X native port objective is make OpenOffice.org run without X11 use, to make it a real Mac application.'''

'''The second one is respect Aqua Human interface Guidelines'''

''' This is a long term work, and every help and/or contributions, like donations** are welcome.'''
</div>

**see http://contributing.openoffice.org/index.html

=='''Native Port Roadmap'''==

==='''2006'''===

* June 2006: work in progress

- Basis: frame, instances, threads, drawing, painting, resizing (Stephan Schaefer, Tino Rachui)

Done:
implement threads
create, manage instance
create, manage windows (including parents)
create, manage events
create manage drawing, resizing
create, add menus (Pavel Janik)
toggle window fullscreen (Pierre de Filippis)
make font server work (Stephan Schaefer)

* Current status font support (Stephan Schaefer, 2006/07/28): the following features are basically working now
** font selection
** font size
** simple font attributes (bold, italic)

Next step: document first part, and propose design

- native filepicker (Pavel Janik, Florian Heckl)

- native printing implementation (Oliver?)

- native font implementation (Eric Bachard)

* September 2006:

- first proofs of concept: fonts, filepicker .. (more?)
- show the results (OOoCon 2006?)

==='''2007'''===

* January 2007: first alpha implementation

=='''Strategy for native port'''==

'''Possible Actions''':

Identify us:

#Complete the arrays below
#Update photos on frapr.com?

Share the work:

#Divide the work between little Teams
#Update Todo list regularly -> needs some love these days ... [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s]

Help:

#Teach tools between us
#Do a debug party on IRC
#write documentation

Meet us:

#IRC
#Mac Meeting (like nov2005 in Hamburg?)

Inform:

#Update website regularly
#Blogs

'''WHO''':

Mac Team:

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
|Developer \ skills || build || write code || code review || debug/trace (higher is better) || contribute to documentation ||
|-
|ericb|| x || x || || 1 || x ||
|-
|pjanik|| || || || || ||
|-
|ssa|| || || || || ||
|-
|maho|| || || || || ||
|-
|tinor|| || || || || ||
|-
|schmidtm|| || || || || ||
|-
|ebischoff|| || || || || ||
|-
|obr|| || || || || ||
|-
|cl|| || || || || ||
|-
|aliscafo|| || || || || ||
|-
|fheckl|| || || || || ||
|-
|Fridrich|| || || || || ||
|-
|plipli|| || x || || || x ||
|-
|}

'''Other resources''':

fonts: ?

events: ?

QA: James McKenzie leads QA for the Mac OS X port of OpenOffice.org and is looking for volunteers to spread this effort over several people and needs people from all over the world to test various languages.

graphical: ?

Communication: ?

'''WHAT''': Status of most important tasks

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
| Task || Names|| Urgency (1=higher)|| Work in Progress || Done || Code review || Debug || Integration ||
|-
|Get rid of X11||done || 1 || x || x || || || ||
|-
|Bundle|| || 1 || x || || || || | ||
|-
|Drawing|| || 1 || x || || || || || ||
|-
|Fonts||plipli || 1 || x || || || || || ||
|-
|Events management|| || 2 || x || || || || || ||
|-
|Controls (see list) ||ericb, aliscafo || 2 || x || || || || || ||
|-
|Native FilePicker||Florian Heckl, Pavel Janik || 3 || x || x || || || || ||
|-
|Native Printing||Yvan Barthelemy || 3 || x || || || || || ||
|-
|Native SpellChecker|| || 4 || || || || || || ||
|-
|Player||Mox Soini || 4 || x || || || || || ||
|}

Other tasks:

Help for writing bug lists, status of bugs ..etc

Write howto use gdb, leaks, other tools

'''WHEN''':

From Christian Lippka (last meeting, 25th of august 2006):
Aug 26 00:21:38 ChristianL
from my point of view what is missing for point 1:
text layout, complete font support, keyboard support,
fixing repaint issues, having aqua install and run out of the box

'''September 2006'''

Present the current state of the project at the 2006 OpenOffice conference in Lyon and Paris

'''Late 2006'''

fix OpenOffice.org launch
fix drawing (repainting)
Implement missing methods and fix most important bugs (mainly the one leading to crash) in:
ATS
Salgraphics
Salinstance

'''January or February 2007'''

make Java work (works partially)
make intensive debug
present something working as alpha

'''June 2007 '''

Implementation of:
native filepicker
native printing

== '''Become a Domain Developer for Mac OS X port''' ==

People regularly contributing to Mac OS x port with regular and quality patches are, after proposal, invited to become a [[DomainDeveloper]].

The purpose of this document is to clearly define all the steps to become a [[DomainDeveloper]].

Preliminary : step 1 in [[Commit_Rights]] must be completed and checked, and you must be in the list of [[http://www.openoffice.org/FAQs/faq-licensing.html#jca1 JCA Licensed people]]

=== Steps for ssh2 key to be uploaded ===

==== Create the key ====

Everything is described here : [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

==== Upload the key ====

You must create an issue, like described below :

Component : www

Sub Component : openoffice.org cvs

Title : CVS Commit access request

Add louis ( Louis Suarez Potts) or st ( Stefan Taxhet ) on CC

Upload your ssh2 public key respecting the process ( Attach a DSA key, not an RSA )

A project lead will confirm your request

Then the support will upload your key

Once done the issue is set to Fixed , and the next step has to be verified before '''you''' close it.

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75291 Upload SSH2 Key for Etsushi Kato]]

==== Verify it works ====

You now can try to connect via tunnel, and follow instructions given [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

If something goes wrong, ask for help to support, with a maximum of details, to solve the problem.

Once it works, the issue can be closed, and you can e.g. test downloading a module from tunnel repository :

First create a tunnel with the command:
<pre>
ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org
</pre>

Then in a new window:

<pre>
export CVSROOT=":pserver:your_login@localhost:/cvs"

cvs login ( enter )

(your password )

mkdir TEST

cd TEST

cvs -z4 co -r SRC680_m205 vcl

cd vcl

cat CVS/Root -> should indicate : your local repository
</pre>

=== Ask for CVS access for all modules required ===

Two steps : create an issue is mandatory because the concerned project is tools, and because people can have only ssh2 key without being [[DomainDeveloper]].

==== Create an issue ====

You must create an issue, described below :

Component : tools

Sub Component : www

Title : CVS access to all modules required

Assigned to mh + CC for ericb and/or pjanik

Present yourself quickly, and ask the access

A project lead will confirm

An admin will confirm this is ok, and set the issue to Fixed

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75494 CVS Access all modules for Etsushi Kato]]

==== Verify ====

Create the tunnel :

open a terminal and type :

ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org

once logged in, open a new terminal, and do ( for example ):
<pre>
cd $OOO_SRC_ROOT/

source MacOSXPPCEnv.Set.sh { source MacOSXX86Env.Set.sh for Mac Intel }

cd vcl ( for example )

IMPORTANT : be sure vcl has been checked from tunnel, not from anoncvs ( cat CVS/Root will give you the answer )

export CWS_WORK_STAMP=aquavcl01 # Only needed for working with [[EIS]], can change for a different CWS ;)

cd aqua/source/gdi

add your changes to your_file.cxx, then commit :

cvs commit -m "#i75689# bla bla ... the reason of the modification(s)" your_file.cxx # The #i75689# is an issue number in the tracker

cvs update

If nothing is wrong, cvs update should not return M for your_file.cxx, means the commit is successfull.
</pre>
In case of problem, use the issue until it is fixed

<big>'''Welcome aboard :)'''</big>

== '''Mac OS X porter Team at WWDC 2007''' ==

=== What is WWDC 2007 ? ===

See [http://developer.apple.com/wwdc/ Apple WWDC 2007]

=== Our Objectives at the WWDC 2007 ===

1) Contacts with Apple's teams :

* Present our current work, methods and team to Apple people, easy to meet only during WWDC ( Apple people can give us a face, and keep the contact )

=> There is information difficult to find or ask by email, or IRC or whatever web : direct contact saves a lot of time, and is a very efficient way to progress with code

* Get their impression about what we have already done and what is still ToDo

2) Mac Team's goals on Aqua OOo -> Apple's Expertise :

* "Give MacOS X users the OOo suite they deserve" :

=> As mac platform and apple's product fans, we are proud to bring the quality and power of OOo to mac users community
=> Make OOo uses all the power of Mac OSX, including upcoming Leopard !

* "OOo to be as Apple HIG compliant as possible" :

=> Define what is expected for User Interface with people from Apple UI project

- FYI : Last year, Apple UI project proposed ericb to help us, once our native menus will be working.

This is now done, and meet them cannot be a bad idea :)

3) Get code guidelines, tips, samples :

=> Ask for code review and find code snippets for :

- HIView
- Printing
- Drag and Drop
+ more if possible

=> More than 1000 Apple engineers are present, and can answer our questions regarding the code, during the whole week

During WWDC2006 we found all the relevant informations for RunApplicationEventLoop() to be implemented . Without this code, we wouldn't have something working at all, because this event loop is the key for everything in OpenOffice.org on Mac OS X ( without X11 ).

4) Social Contract : Discuss and meet new developers and / or american people working for Mac OS X port (like Michael Sicotte, Vijay Venkatraman , other.. )

5) Visibility : make OpenOffice.org project visible in an ocean of other software. This is extremely important because it shows that OpenOffice.org project is alive for Mac OS X platform.

=== Who ? ===

* Sébastien Plisson
* Shaun McDonald
* Eric Bachard

=== Todo list ===

Please add topics, technical questions you would see asked by attendees to Apple engineers during WWDC

Mike Sicotte:
I understood that implementing printing in aqua OOo was a topic that we didn't get accepted into Google SOC - so remains on the ToDo list. I notice that there are three Sessions specfically related to printing at WWDC:
Leveraging the Common Unix Printing System (CUPS)
Printing with Style in Mac OS X
Printing Lab
If this is judged to be a good use of time at WWDC I would be willing to spend some time to help further develop the questions to be addressed with the Apple engineers.

== '''Mac OS X porter Team at OOoCon 2007''' ==

=== Who ? ===

* Shaun McDonald
* Eric Bachard

=== What ? ===

The conference is over 3 days. Presentations should last around 45 minutes. http://www.openoffice.org/servlets/ReadMsg?list=announce&msgNo=320 Papers have to be submitted by 1st June to be considered.

Ideas :

Mike Sicotte: Perhaps the results of the Google SOC could be a presentation.

*create a complete topic for Mac port (one stream for a day or half day)
*How to improve ooo usability though the use of floating palettes instead of modal dialogs

- several presentations / BOF

Eric Bachard : Aqua OpenOffice.org ( conf / 1 hour )

Others ?

*reserve rooms together ? Better rent a house?

* [FIXME]

=='''2nd Mac porters meeting'''==

This section has been moved to [[2nd Mac porters meeting]]

=='''IRC Mac port meetings'''==

This section has been moved to [[MacOSXPortMeetings]].

== '''Mac OS X (X11) Quality Assurance'''==

This section has been moved to [[Mac OS X ( X11) Quality Assurance]]

== '''Mac OS X Implementing HIView and Carbon events'''==

This section has been moved to [[Mac OS X Implementing HIView ]]

== '''Debug OpenOffice.org using XCode '''==

[[ MacOSX Debug OpenOffice.org using XCode]]

=='''Description of the Native Port problem'''==

=== How does OpenOffice.org work on Mac OS X? ===

Currently, on Mac OS X, OpenOffice.org uses X11, as "client": X11 is a graphical server, coming from Unix world, and able to run under Linux, *BSD, Solaris, Mac OS X.

- X11 is run as an application, managed like other Apple applications.
- All unix like applications are managed by X11, and from Aqua environment, only X11 is seen as only one applicatiion,
even if other Unix/Linux (e.g.) applications are runing.

OpenOffice.org asks X11 to display a window, waits for X11 acknowledgment, and OpenOffice.org displays the window. All transactions use the network, locally or not. the same mechanism is used for everything to be displayed.

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=== Issues and known problems ===

All events are managed by OpenOffice.org and X11, using the Xlib

Only .ttf fonts type is currently available. Note: '''system fonts are available '''

The rendering is made by X11, not by Mac OS X rendering engine.

X11 and all its clients are seen as one application only: drag and drop protocol does not work because of that (solution: Pasteboard Manager)

==== Other links ====

http://wiki.services.openoffice.org/wiki/List_of_OpenOffice.org_Mac_OS_X_issues_and_problems#

http://wiki.services.openoffice.org/wiki/Printing_problems_with_OpenOffice.org_2.0_for_Mac_OS_X#Reporting_printing_problems

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

== What do we have to do?==

* (in progress) : Implement direct access to Apple graphical engine, using Apple API: Quartz2D/CoreGraphics (and replacing Xlib use)

like: instantiate, manage events and threads for a graphical instance + all needed objects, drawing: manage all drawing cases

* (in progress) : Implement native events management, using CarbonEventManager (replacing Xlib management)

* (in progress) : Implement native font use, using Apple Type Server and ATSUI (for Unicode Imagery) (replacing X11 management)

Work in progress: [[Mac OS X Porting - Native Fonts]]

* Implement native sound, using QuickTime (replacing Java Media Framework): [[Mac OS X Porting - Native Audio and Video]]

* Implement native Drag and drop, Implementing Pasteboard Manager: [[Mac OS X Porting - Native Drag and drop]]

* (done experimental) Implement Native Filepicker

* Implement Native Printing: current uses cups, but native printing is mandatory: [[Mac OS X Porting - Native_Printing]]

* Implement Apple Spellchecker

--[[User:Plipli|Plipli]] 09:27, 25 March 2007 (CEST)

=='''Where is located the code to be modified?'''==

Most of the changes are located in vcl (Visual Class Layer), for everything graphical, events, fonts, rendering and printing.

Other, for sound and movies will be in avmedia (where the player is implemented in OpenOffice.org sources).

For drag and drop, dtrans is concerned (Pasteboard Manager implementation)

[FIXME]: Filepicker? Apple Spellchecker?

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=='''How will the new implementation be tested?==

Currently, all openOffice.org code can be compiled without using the Xlib. but of course, a lot of features are missing,

and the final package simply won't work

In vcl module", a '''toy''' called svdem is built at buildtime. This binary is linked to libvcl* and so all new stuff can be tested.

e.g. : draw anti-aliased lines works well.

Everything implemented in aqua vcl code will be included in libvclplug_aqua, and svdem source code will contain a specific part to proceed tests.

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">

'''The magic is: when all needed features will work with svdem, it will work in the new version of OpenOffice.org !!'''

</div>

[FIXME]: add more complete list of features to implement and test.

== AquaVCL 01 cws ==

[[http://qa.openoffice.org/issues/buglist.cgi?keywords=aqua Top 10 of Aqua issues]]

[[Aquavcl01 tasks]]

===Changelog ===

====Work in progresss : alpha 0.6 ====

Started (19th March ) :

Michael Sicotte proposed to investigate in timers, and continue [[http://www.openoffice.org/issues/show_bug.cgi?id=75228 Pavel's work]] : objective is to replace obsolete code. ( 23th March)

[experimental] plipli proposed a patch for a new salframe implementation, using HIView + optionally compositing (21th March )

[commit scheduled] Michael Sicotte proposed a complete patch for invert() ( SAL_INVERT SAL_INVERT_50 and SAL_INVERT_TRACKFRAME ) (20th March )

Tino proposed to work on code cleanup in salatsuifontutils.cxx, removing obsolete code

ismael and michael work on invert() + drawAlphaRect()

Damien started to work on drawEPS()

plipli and ericb work on refresh

==== alpha 0.5====

Top 10 Summary : 7 issues over 10 are fixed or very close to be :

'''time to code review, tracing, and search for memory leaks'''

[done] Unicode input in salframe ( ekato ) ( 19th March )

[experimental, works partially] beginning of HIView + HIComboxes works (text still missing) (ericb + plipli) ( 14th March )

[done] replace NewRgn() in salframe (ericb (11th March )

[experimental, but very interesting] Improved native windows ( ismael ) ( 7th March )

====alpha 0.4====

'''[Informative]''' build runs with Leopard 9A377a ( fheckl ) ( 7th March )

Refresh screen issues (plipli) (4th to 10th March )

'''[informative]''' plipli announced progress with refresh screen issues ( 28th February )

[experimental, not yet commited] Proxy configuration from system ( pjanik) ( 28th February )

[done] highlighted native button ( pjanik) ( 27th February )

Native File Picker works ( fheckl / pjanik ) ( 23th February )

====alpha 0.3====

Cursor does appear -> invert() + setting a setBlinkTime value in UpdateSettings() (pjanik /ericb )

[done] mirroring negative images (ismael) + DrawAlphaBitmap() + CreateWithMask()

pjanik patch for Focus Events

[done] scrolling works ( pjanik ) (17th February )

[done ] carret works ( plipli) (17th February )

[done] checkbuttons fix for checkmarks (ericb) ( 17th February )

'''[Informative]''' Pavel Janik propose to solve offScreen buffer using HIView ( 17th February )

[experimental, never commited] patch for macosxrc.txt use + UpdateSettings() use in salframe.cxx ( ericb ( 16th February )

Michael Sicotte joined the Team ( 15th February )

invert() : first try (ericb) ( 13th february )

====alpha 0.2====

[12th February 2007 ]

[done] calc does not start : bug identified by tino , first workaround (ericb) [[http://www.openoffice.org/issues/show_bug.cgi?id=73691 issue 73691]]

[done] bitmaps in native popup menus (ismael)

[done] replace obsolete code for HandleWindowPaintEvent(), newRgn() .. etc (ericb) (12th February)

correct salatslayout patch (plipli) ( 11th February)

'''[Informative]''' Michel Renon proposed a summary about his work on fonts issues

[patch] Pavel fixed several menu crashes (09th February )

'''[Informative]''' : Pavel posted a mail about several crashes origin

patch for radioboxes and checkboxes ( ericb ) (9th February)

first complete patch for salatslayout.cxx ( plipli) ( 9th February )

[done] most important crashes fixed ( pjanik) ( 09th february )

Modified baseline for 2.2. : Mac OS X10.4 -> Aqua will be 10.4 and 10.5 compatible only ( ericb)

first try with multi line sallayout (plipli ) ( 08th February )

Damien Duportal joined the Team ( 7th February )

[done] scrollbar changes (ericb ) ( 4th February )

====alpha 0.1====

create Top 10 of issues before alpha 3rd February 2007 : See : [[http://porting.openoffice.org/mac/news/2007/20070203toptenbeforealpha.html Top 10 of issues]]

[experimental, not commited] patch for TPT() implementation (ericb) ( 2nd February 2007 )

Pavel Janik proposed to implement TransformProcessType() ( 2nd February 2007 )

[not commited] implement UpdateSettings() (ericb)

Pavel Janik resynchronized aquavel01 cws with m202 ( 2nd February 2007 )

====alpha 0.03====

Michel Renon joined the Team (1st February )

[done] fix checkbuttons and radiobuttons issues: offsets, redrawing of the check marks ( ericb)

[done] fix scrollbar buttons (implement correct methods to retrieve dimensions)

[done] implement mapfiles for Mac OS X (Stephan Bergmann, Daniel Boelzle, Tino Rachui , Pavel Janik)

====alpha 0.02====

[done] modify libsalsystools.dylib to be correctly loaded with the bundle (ericb, + pjanik)

[done] add mouse drag events ( pjanik )

====alpha 0.01====

[done] add new feature for Aqua windows, to allow QuickTime player use( mox )

[done] replace obsolete code in salframe.cxx with (ericb)

[done] fix correct size for main window (GetOptimaWindowSize() ) (ericb)

[done] fix alpha channel in pixmaps (ismael)

====alpha 0.0====

[done] pushbutton where not correctly drawn (ericb)

[done] fix missing mouse events (pjanik)

[done] fix nRepeat in text entry (ssa)

2nd Mac porters Meeting

===Work in progress ===

URGENT :

Top of issues causing crashes : event issue when tips is enabled causes crashes ( well known window / handler / window desctructor / event loop bug )

Salatsuifontutils : replace old code, track leaks : tino

[done] Bitmaps : ( isma87)

[running] Crashes : (tino, pjanik, ericb, isma87, plipli )

[???] Drag and drop : (vijay)

[???] Printing (ybart)

Florian Heckl proposed a subject for Google Summer of Code about native printing

Drawing/ windowing ( plipli / ericb ) -> mainly refresh

[done] Implement cursor

[started] Native Controls (ericb)

[work in progress] partial multiline sallayout (plipli )

To do :

(started, Oliver) - modify the tree to make the bundle start without hack ( issue fixed during buildtime)

(started, Florian Heckl) verify Native FilePicker implementation ( works , tested in Hamburg )

[done] Ismael Merzaq) implement blit functions in salgdi ( important fix: probably apha version to be tested once done)

[done] Sebastien Plisson- update the missing functions list ( fonts ... ask hdu & cl

[started] ericb, Mox Soini, Sebastien Plisson, Tino Rachui, Pavel janik continue to replace obsolete code

fix crashes with menus (started : tino )

== '''Sort of documentation about VCL around Native Mac OS X port''' ==

Do we really need to understand how it works? ;-)

vcl content:

ls -laR | wc -l
1750

-> Uff 1750 files to analyse :-/

Our purpose is to describe the vcl organisation. The content of vcl is so important, that at the begining, the content will looks a bit confused. e.g. class names ..etc have nothing to do, only description with words and sense, but this will need some time before we can understand everything.

How analyse with more efficiency? After some months to anlalyse '''"horizontaly"''', it appears that list all the content of a directory is not the solution. Of course, we learned a lot, but we now have to complete with '''"orthogonal"''' method (compared to the previous one). The first method wasn't obviously not the good/best way to describe vcl.

[FIXME] a different approach (will ask confirmation to Philipp Lohman), could be a description of how it work in runtime. First define what an instance is, a frame, and what exactly is concerned by such "objects".

With that, we can write a list of different objects all using the same scheme: empty boxes (means pure virtual methods and classes in generic libvvcl), really implemented in the specific part, and finally, the API "encapsulated".

The most difficult is to see where the API is used. But for all the parts, this is the same.

Finally, '''what is important is the design of vcl'''. Which '''patterns''' are used? What are the dependencies, how works the stack for the events, how works the scheduler, the timers too is very important, even fundamental for Aqua implementation. Will have a look at gsl mailing list, and other resources. Probably everything is already (randomly) written somewhere.

=== VCL organisation ===

Thank's to Philipp Lohmann for this short, but precise description:

Basically vcl is divided in the system dependent and the system independent part. The interface between these two is mostly the Sal interface (every interface name Sal*: SalInstance, SalFrame, SalGraphics, SalPrinter, etc.).

SalInstance is a factory that can create all the other abstracted interfaces of the system dependent part. It also provides the main loop SalInstance::Yield()

SalFrame abstracts any kind of system window.

SalVirtualDevice abstracts an offscreen window (e.g. a Pixmap on X11)

SalPrinter and SalInfoPrinter abstract the system print queues where SalInfoPrinter is for querying and SalPrinter for actual printing.

SalGraphics is an interface produced by either SalFrame, SalVirtualDevice or SalPrinter which is used for actual drawing operations (text, bitmaps, vector graphics)

SalSound is for sound playing.

SalBitmap provides memory for bitmap graphics as well as methods converting this memory to a system handle (e.g. a Pixmap on X11).

SalOpenGL provides OpenGL functionality if available.

SalTimer is an interface for periodically triggering the event queue (to timer implementation).

SalI18NImeStatus handles how the status window of an Input Method Editor (IME) should display (this is mainly X11 specific).

SalSystem has some system specific methods that did not belong anywhere else:-)

Of all these there interfaces is at least one implementation per system (Windows, X11 or Mac). The Unix implementation also has a plugin concept to allow for integration of different native toolkits (currently gtk and Qt) which became necessary for the implementation of Native Widget Framework (NWF) to display controls like their normal desktop counterparts.

Basically the independent part (what is beneath vcl/source directory) has generic methods for drawing, window handling and stuff which it brings into a suitable form and then delegates to the system specific implementation (located beneath vcl/win for Windows and vcl/unx for the X11 platforms).

[[User:Ericb|Ericb]] 16:12, 1 July 2006 (CEST)

===Sub-directories description ===

==== '''Organisation of vcl directories''' ====

[[Image:aquavcl_organisation_complete_02.jpg]]

==== '''Directories in vcl. Short description''' ====

''' aqua ''': The name Aqua means Apple look and feel, and is well known as [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html Aqua Human Interface Guidelines]. This look and feel means Mac OS X. The work was begun by (probably) P. luby, Dan Williams Herbert Duerr (most of fonts stuff) and Ed Peterlin. Currently in ruin, this directory does contain a lot of ideas to investigate. The most important part of needed changes for native version (3.0) will be done inside aqua dir inc: does contain all vcl relative includes [PART1]

''' prj ''': Does contain build.lst and d.lst build.lst give us dependencies: probably a lot for vcl, build 98th module over ~148. Everything graphical depends in vcl.

''' qa ''' does contain all quality assurancy stuff

'''source''': the most important:-) This directory contains common sources for all architectures and OS. Mainly: Windows, Unix: Linux , Mac OS X (X11), Solaris, including generic, kde and gtk plugins, and Aqua (Mac OS X without X11, work currently in progress).

Depending on the OS and the architecture, binaries are built or not.

''' test ''': This directory does contain all the needed stuff for tests. As example, in qa/testdocuments, you'll find three documents (one writer, one calc and one impress) for tests purpose.
Other available tests are about memcheck and persistent window state.

''' unx ''': this directory does contain all unixes stuff. We have to understand what is inside to implement aqua port. For example, a lot of classes/strutures and objects use Xlib calls we have to replace with Carbon/Cocoa call (at least at first time) for Mac OS X native port.

''' win ''': Doing Mac OS X native port, I first believed this directory was not interesting for us, but I was wrong: OpenOffice.org roots are inside this directory, and a lot of comments and resources are inside. Mainly interesting if Carbon is used.

'''workben''': Does contain a toy called "svdem". svdem is a binary, used for new implementations. For example, actual aqua development uses svdem intensively, to verify all important properties we need:

- display a window first (al least ...:))

- close cleanly this window

- display a point

- trace a line

- trace an area

- superpose two areas doing some important graphical operations, (like xor),

- display a character

- display a menu.

- intercept events correctly.

[FIXME] add more tests

[[User:Ericb|Ericb]] 13:21, 3 June 2006 (CEST)

=='''Naming convention''' ==

* Class names start with upper case letters, to improve readability.

* Implemented Class names are derived from the virtual classes but can of course take arbitrary names.
To increase readability, it's recommended to closely follow the base class name.

* '''Impl prefix: means Implementation details'''. The concerned class or method or function is not used outside of this module, so no external code (or other libraries) can see it.

'''[[ Events types using Carbon API (Mac OS X): ]]''' A lot of events have to be managed in runtime. Here is a short description

- do not freeze because bad event loops

- event types implementation: currently, they are defined in vcl/aqua/inc/aquavclevents.hxx

Apart: exact sense of hedabu? -> [FIXME] as far as I understood it: it is like "copy" to deliver software into the solver, with extra magic. The header files for example are manipulated so paths need not be exact. "headabu" is supposed to disappear little by little.

== '''What do we have to build in vcl?'''==

Two libraries, corresponding ressources (localized) and a toy so called « svdem »

'''Common part''':

in grey on right. The result will be a non architecture dependant library, built in all cases: for instance, libvcl680mxi.dylib on Mac Intel.

'''Specific part " a plugin " ''':

Light yellow: aqua part will only concern Mac OS X (non X11) the name will probably be libvcl_aqua680mxi.dylib

As you can see, win means windows part, in blue

For Unix build (Linux, Solaris or current Mac OS X X11), in purple.

Result will be:

libvclplug_PLUGIN680mxi.DLLSUFFIX , where PLUGIN can be iether gen (generic) or gtk (using gtk+) or kde (using qt), and DLLSUFFIX can be either .so (linux) or .dylib (Mac OS X) ...etc (I'm not sure for other cases).

Example: libvcl680mxi.dylib and libvclplug_aqua680mxi.dylib

'''In runtime''', libvclplug_aqua will be linked to libvcl680. the first one will contain the real implementation (respecting the API, e.g. Carbon) while the generic libvcl will only contain pure virtual methods ...etc like "empty boxes".

=== Current Aqua content ===

A more complete description of aqua (Mac OS X / no X11 specific): [[Image:Vcl_aqua_organisation_02_tree.jpg]]

==EXISTING objects to build in aqua==

===Sal APP "everything application"===

[FIXME] add all objects descriptions

==== saldata ====

* '''Defined in plugin exclusively''' (i.e. for headers)

Unix: unx/source/app/saldata.cxx (header in unx/inc)

'''Aqua: aqua/source/app/saldata.cxx (header in win/inc)'''

Windows: win/source/app/saldata.cxx (header in aqua/inc)

* Role: saldata contains various kind of data used by the implementation for the concerned platform. '''It is a bunch of global data collections reserved for the platform'''

It is just completely platform dependent, and nobody except this plugin can see it.

'''Saldata is something like a "second sal", but providing an abstraction regarding windowing and graphics''', while SAL module provides an abstraction more Operating System oriented)

e.g. : have a look at XRequest array in vcl/unx/source/app/saldata.cxx => all calls are for Xlib (X11). Ok, useless there, but interesting:-)

[FIXME]: use Windows implementation could be a good starting point. Nothing is the same, but the current aquavcl cws uses similar objects, and it works very correctly.

saldatax.cxx uses classes SalInstance, SalObject, SalFrame, SalVirtualDevice, SalPrinter and fontList.

Current list of possible objects who can be instantiated/released:

structure SalData: does contain pointers on all kind of objects from other classes used in saldata.

inline functions: [FIXME]: complete the description

- SetSalData:
- GetSalData:
- GetAppSalData:

==== salinst ====

=> implemented in vcl/aqua/source/app/salinst.cxx

Role:

* get environment, mutexes, instantiate AquaSalInstance (Ctor, Dtor),

* instantiates/releases a lot of other objects using Get() / CreateObject() / DestroyObject() methods.

Current list of possible objects who can be instantiated/released:

* VirtualDevice [FIXME]: exact role?

*Printer

- GetDefaultPrinter/ CreatePrinter() / DestroyPrinter - what a name ;-) -

- InfoPrinter (Get/Create/Delete)

- PrinterQueue (DeletePrinterQueueInfo / GetPrinterQueueInfo / GetPrinterQueueState)

* System (Create / Delete) [FIXME]: what means system here?

* Events:

AquaSalInstance::SetEventCallback()

AquaSalInstance::SetErrorEvenCallback()

AquaSalInstance::GetConnectionIdentifier()

* Menu / MenuItem:

AquaSalInstance::CreateMenu() / same for DestroyMenu()

AquaSalInstance::CreateMenuItem / same DestroyMenuItem()

* Sound:

AquaSalInstance::CreateSalSound() => object to a pointer of SalSound type

Note: AquaSalInstance::DestroySalSound is not implemented (?)

* Timer: CreateTimer() /

AquaSalInstance:: DestroyTimer() is not yet implemented (?)

Class MacImeStatus: inherits of SalI18NImeStatus

-> only there to see if there is a window to toggle into menubar [FIXME]??

AquaSalInstance::CreateI18NImeStatus(): instantiates MacImeStatus

'''For futher informations, see: ''' '''[[Content of salinst.cxx]]'''

([[User:Ericb|Ericb]] 16:11, 20 May 2006 (CEST) )

==== salmain ====

Role: if possible, runs the standard vcl application code SVMain()

([[User:Ericb|Ericb]] 16:15, 20 May 2006 (CEST))

==== salsound ====

==== salsys ====

==== saltimer ====

==== saltimer ====

The main problem with SalTimer is the code we use is obsolete. To remove this deprecated code, sevarl work have been tried

1) Pavel Janik, in issue 75228

works, but a serious problem is remaining (a thread issue, nothing anybody explained yet)

2) eric bacahrd ( code will be attached soon )

3) Michael Sicotte, who proposed to work on that, and continue Pavel implementation.

SalTimer description

AquaSalTimerproc

AquaSalTimer::Start()

AquaSalTimer::Stop()

AquaSalTimer::Restart()

AquaSalTimer::Installtask() // yet needed ?

=== Sal GDI (everything Graphical Display Interface) ===

====salgdinativewidgets====

[[native controls]]

==== salatslayout ====

==> implemented in vcl/aqua/source/gdi/salatslayout.cxx

- Handle text layouting :

* Use ATSUI (ATSUCreateTextLayoutFromPtr) to layout the text unicode char buffer
* Use ATSUI (ATSU..) to get informations about glyphs
* Populate different arrays (mpGlyph2Chars, mpChars2Glyph, mpCharsWidths, mpGlyphAdvances)
that are used in various methods.

==== salatsuiutils ====

==== salfontutils ====

==== salmathutils ====

==== sal bmp ====

==== salvd ====

==== salpixmaputils====

==== salprn ====

====salrectangle====

==== salvd ====

=== Sal Window===

==== salframe ====
Documentation in progress, from damiend :
[[User:Damiend|Damiend page]]

====salobj====

== TO BE IMPLEMENTED (missing in Aqua)==

===Audio===

====audioconvert====
(obsolete?)

====devaudio====
(obsolete?)

====native sound====

====salimpsound====

====vsound====

===i18n===

===keysymnames===

===saldisp===

===sm===

[FIXME]: is session manager usefull?

=='''Native Controls'''==

====Scrollbar====

'''Works as expected'''. The most important work is done

See : [[Mac_OS_X_Porting_-_Native_Controls#ScrollBar]]

====DrawThemeButton() documentation====

'''Started'''

See : [[Mac_OS_X_Porting_-_Native_Controls#ComboBox]]

Started
<pre>
DrawThemeButton
Draws a button.

OSStatus DrawThemeButton (
const Rect * inBounds,
ThemeButtonKind inKind,
const ThemeButtonDrawInfo * inNewInfo,
const ThemeButtonDrawInfo * inPrevInfo,
ThemeEraseUPP inEraseProc,
ThemeButtonDrawUPP inLabelProc,
UInt32 inUserData
);
Parameters
inBounds
A pointer to a structure of type Rect. Pass a rectangle specifying the boundary of the button, in local coordinates.

inKind
A value of type ThemeButtonKind. Pass a constant specifying the type of button to draw.
See “Theme Buttons” for descriptions of possible values.

inNewInfo
A pointer to a structure of type ThemeButtonDrawInfo. Before calling DrawThemeButton,
set the structure to contain the new state, value, and adornment for the button.
DrawThemeButton uses the information passed in the inNewInfo and inPrevInfo parameters
to apply transitional animation or sound effects as the button state changes, if such are
specified under the current theme.

inPrevInfo
A pointer to a structure of type ThemeButtonDrawInfo. If the button state is changing,
set the structure to contain the previous state, value, and adornment for the button,
to allow DrawThemeButton to apply any transitional effects. If the button state is not
changing, you can pass NULL.

inEraseProc
A value of type ThemeEraseUPP. If you have a custom background, use this parameter to pass
a universal function pointer to an application-defined function such as that described in
ThemeEraseProcPtr. DrawThemeButton calls this function to erase the background before drawing
the button. If you pass NULL, DrawThemeButton's default behavior is to erase the background
for you.

inLabelProc
A value of type ThemeButtonDrawUPP. If you pass a universal function pointer to an
application-defined function such as that described in ThemeButtonDrawProcPtr, DrawThemeButton
calls that function to draw the label of the button. If you pass NULL, no label is drawn.

inUserData
An unsigned 32-bit integer. Provide any data to be passed in to the callback functions specified in
the inLabelProc and inEraseProc parameters. Pass NULL if you do not wish to provide any data.

Return Value
A result code. See “Appearance Manager Result Codes”.

Discussion
The DrawThemeButton function draws a theme-compliant button. If a ThemeEraseProcPtr is
specified in the inEraseProc parameter, DrawThemeButton uses that function to erase the
background of the button before drawing the button. After the button is drawn, if a
ThemeButtonDrawProcPtr is specified in the inLabelProc parameter, DrawThemeButton calls
that function to draw the button’s label.

Note that DrawThemeButton also draws any appearance adornments for the button and that these
can extend beyond the button’s basic bounding rectangle, as specified in the inBounds parameter,
and may be of variable shape. You may therefore wish to call the function
GetThemeButtonBackgroundBounds to obtain the actual rectangle containing the pixels belonging
to a button under the current theme.

Version Notes
This function is available with Appearance Manager 1.1 and later.

Availability
Available in CarbonLib 1.0 and later when Appearance 1.1 or later is present.
Available in Mac OS X 10.0 and later.
Declared In
Appearance.h
</pre>

====HIComboBoxCreate() documentation====

<pre>
HIComboBoxCreate
Creates a combo box control.

OSStatus HIComboBoxCreate (
const HIRect* boundsRect,
CFStringRef text,
const ControlFontStyleRec* style,
CFArrayRef list,
OptionBits inAttributes,
HIViewRef* outComboBox
);
Parameters
boundsRect
The bounding box of the control.

text
The default text in the editable portion of the control. Can be NULL.

style
The font style of the both editable text and the text in the disclosure list. Can be NULL.

list
The default values available in the disclosure list. Can be NULL.

inAttributes
The default attributes of the combo box. For possible values, see “Combo Box Attributes”.

outComboBox
On exit, a pointer to a reference for the new control.

Discussion
The combo box can be used in compositing mode, as well as traditional Control Manager mode.
When created, this view is invisible. To see the view, you must show the view by calling HIViewSetVisible.
</pre>

== What is used for Linux, Windows, Mac OS X ...build ? ==

'''[[Description of the dependencies]]'''

'''[[Windows]]'''

'''[[MacOS X]]'''

'''[[Linux]]'''

'''[[Solaris]]'''

== Content of Aqua ==

'''[[Click here to see the complete list]]'''

'''Content of vcl/inc'''

Notes:

1) Where to find includes

<foo/bar.hxx> means you can find bar.hxx in the foo module. The new style file is foo/inc/foo/bar.hxx, old style is foo/inc/bar.hxx and sometimes the file is somewhere else in the tree or generated. The deliver process copies/generates the file into solver at solver/680/build_type/inc/foo. Good for fixing broken builds. ;-)

2)
suffix .h (for C calls or first version?) or .hxx (C++)

'''A) Family of includes''':

Looking more closely at the list brings to the fore (expression from dictionary ;-) ) that include names are
informatives. Most of the time, the name gives the function/role.
What is interesting is the files with name begining with "sal". sal means System Abstraction Layer + include's function (or explicit name).

Partial list, for example:

salatype.hxx

salbmp.hxx

salctrlhandle.hxx

salctype.hxx

salframe.hxx

salgdi.hxx

salgeom.hxx

sallayout.hxx (main header for fonts services)
...
salmenu
salnativewidgets
...etc

Other important families are "sv" and "uno" or "win" (window) prefixed. sal family will be analysed apart.

'''B) Includes of includes'''

Some includes are more important than other. To prove this, just have a look is sufficient: some are always needed, and some more rarely.

To verify, a simple test to do in vcl/inc:

egrep -H "#include" ./* | wc -l gives me 681 lines ! And some of them are the same...

To know more, the precedent command line can be modified to make appear the numerous call
to the same includes files.

egrep -H "#include" ./* | cut -d"#" -f2 | sort > liste.txt

The content of liste.txt is explicit: dllapi.h, sv.h and some other are very important, while some other includes are only one or two times used. We can see too that vos includes are numerous, even if vos is deprecated**

**see http://wiki.services.openoffice.org/wiki/Source_code_directories

I'm nearly sure that a complete analysis of just this result will give us a lot of information.

I propose to change the order of analysis starting with dllapi.h and sv.h.

[to be continued]

'''B1) "sal" includes family'''

[[salinst.hxx]] This seems to be the main include file

[[salatype.hxx]]

[[salctrlhandle.hxx]]

[[salctype.hxx]]

[[salframe.hxx]]

[[salgdi.hxx]]

[[salgeom.hxx]]

'''[[ sallayout.hxx ]]''' <-- see Native Fonts implementation

[[salgtype.hxx]]

[[vcl/inc/salobj.hxx]]

'''B2) Classicals includes'''

file: abstdlg.hxx [ means abstract dialog ]

This includes does contain the following classes definitions:

[FIXME] : choose a precise presentation template for classes

VclAbstractDialog,

VclAbstractTerminateDialog,

VclAbstractRefreshableDialog,

VclAbstractDialogFactory,

uses <tools/solar.h> , <tools/string.hxx> +

"dllapi.h"

Note : dllapi.h is very interesting because when we have to find (for example) a library suffix, SAL_DLLEXTENSSION can replace all suffixes (every OS's and archs). Just including sal/config.h does it !

Classes:

Window -> what? [FIXME]
ResId -> what?

Does contain the prototype of VclAbstractDialog, inherit of VCL_DLLPUBLIC

file: dllapi.h [ dll for dynamic linked library ]
Uses: <sal/config.h> and >sal/types/h>
includes: VCL_DLLPUBLIC macro

file: accel.h [ means accelerator ]

Classes:

Accelerator
{
}
ImplAccelEntry
{
public members:

Names

mnId
maKeyCode
mpAccel
mpAutoAccel
mbEnabled
}

function / returns / parameters

ImplGetKeyCode / void / KeyFuncType eFunc, ref rCode1 , ref rCode2, ref rCode3

file: accel.hxx

Uses: <sv.h> , "dllapi.h" ,<tools/resid.hxx>, <<tools/rc.hxx>

Classes:

ImplAccelData;
ImplAccelEntry;

== Important Links ==
'''[[Progressive implementation]]'''

'''Native Font server Implementation''' '''[[Mac OS X Porting - Native Fonts]]'''

'''Native Sound Implementation''': [[Mac OS X Porting - Native Audio and Video]]

'''Native Printing Implementation''': [[Mac OS X Porting - Native_Printing]]

'''Drag and Drop implementation''': [[Mac OS X Porting - Native Drag and drop]]

'''Data Acquisition''' : [[Mac OS X Porting - Data Acquisition]]

This work is part of http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s

[to be continued:-) ]

== Keyboard comparizon between OpenOffice.org / Mac OS X application ==

[FIXME] redo a cleanest array

{| style="vertical-align:top; text-align:centered; background-color:#F0F0F0;"
|- style="background-color:#99CCFF; font-weight:bold;"
| Modifier||+ key || Result || TextEdit returns
|-
|ALT|| a||æ ||æ
|-
|ALT||b||ß ||ß
|-
|ALT||c||© ||©
|-
|ALT||d||∂ ||∂
|-
|ALT||e||ê ||ê
|-
|ALT||f||ƒ ||ƒ
|-
|ALT||g ||ﬁ ||ﬁ
|-
|ALT||h ||Ì ||Ì
|-
|ALT||i ||î ||î
|-
|ALT||j ||Ï ||Ï
|-
|ALT||k ||È ||È
|-
|ALT||l ||¬ ||¬
|-
|ALT||m ||µ ||µ
|-
|ALT||n ||~ ||~
|-
|ALT||o ||œ ||œ
|-
|ALT||p ||π ||π
|-
|ALT||q ||‡ ||‡
|-
|ALT||r ||® ||®
|-
|ALT||s ||Ò ||Ò
|-
|ALT||t ||† ||†
|-
|ALT||u ||º ||º
|-
|ALT||v ||◊ ||◊
|-
|ALT||w ||‹ ||‹
|-
|ALT||x ||≈ ||≈
|-
|ALT||y ||Ú ||Ú
|-
|ALT||z ||Â ||Â
|-
|ALT||A ||Æ ||Æ
|-
|ALT||B ||∫ ||∫
|-
|ALT||C ||¢ ||¢
|-
|ALT||D||∆||∆
|-
|ALT||F ||· ||·
|-
|ALT||G ||ﬂ ||ﬂ
|-
|ALT||H ||Î ||Î
|-
|ALT||I ||Î ||Î
|-
|ALT||J ||Í ||Í
|-
|ALT||K ||Ë ||Ë
|-
|ALT||L || <pre>|</pre> ||<pre>|</pre>
|-
|ALT||M ||Ó ||Ó
|-
|ALT||N ||ı ||ı
|-
|ALT||O ||Œ ||Œ
|-
|ALT||P ||∏ ||∏
|-
|ALT||Q ||Ω ||Ω
|-
|ALT||R ||‚ ||‚
|-
|ALT||S ||∑ ||∑
|-
|ALT||T ||™ ||™
|-
|ALT||U ||ª ||ª
|-
|ALT||V ||√ ||√
|-
|ALT||W ||› ||›
|-
|ALT||X ||⁄ ||⁄
|-
|ALT||Y ||Ÿ ||Ÿ
|-
|ALT||Z ||Å ||Å
|-
|ALT||$ ||€ ||€
|-
|ALT||` ||@ ||@
|-
|ALT||£ ||# ||#
|-
|ALT||* ||¥ ||¥
|}

Sous réserve d'erreur ou omission [[User:Ericb|Ericb]] 00:05, 14 January 2007 (CET)

--[[User:Ericb|Ericb]] 15:00, 22 Jul 2005 (EDT)

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Summer of Code 2007

2007-03-29T08:11:07Z

Plipli: /* Mac OS X Address book integration (Aqua / X11) */

Similar to [[SummerOfCode2006|last year]], OpenOffice.org is participating in the [http://code.google.com/soc/ Google Summer of Code](tm) initiative sponsored by Google.

This page collects some suitable task suggestions we got many applications for. We would be glad to support a few projects. The review is in progress and results can be expected for
[http://code.google.com/support/bin/answer.py?answer=60325&topic=10729 April 11].

=Task Proposals=

==API==

===UNO specifications changes in Eclipse Integration===

This project aims at improving the way to develop OpenOffice.org extensions and UNO components using Eclipse. This project should help the developer to changes its specifications easily. This project could be parted into several smaller parts.

See [[EclipseIntegration_ToDo#IDL_files_modification_assistance | the Todo task description]] for further informations.

* Required skills/knowledge: Java, Grammar & Compilers
* Usefull skills: Eclipse API, JavaCC, UNO & UNO IDL

; Contact
: dev@api.openoffice.org
: CedricBosdo at openoffice.org

== Base ==

=== Joins in dBase Queries ===

Queries to dBase files can currently contain one table only. Scope of the project is to enhance Base' built-in simple query engine to be capable of executing statements line <code>SELECT table1.field1, table2.field2 FROM table1, table2</code>. The dBase driver, the text/csv driver, and the Spreadsheet driver would all benefit from this extension.

Be prepared to dig around here before starting the project, the project touches low-level core implementations, including some heavy-to-read STL stuff, so be prepared to invest some time before writing the first line of code.

* required skills C++, SQL knowledge
* useful skills: Lexx and Yacc
* Contact: mailto:dev@dba.openoffice.org
* Mentor: Ocke Janssen - Ocke.Janssen at Sun.Com

=== Dialogs with Form Functionality ===

When creating a form, the user always needs to bother with a Writer document. Very often, this is much too oversized. It would be sufficient to have a simple dialog which contains all the data access controls.

The advantage would be to not slay the user with things she does not bother – a writer document offers a lot of possibilities which are not relevant for a form. In some cases, a full writer document does even contradict to what users expect from a form – one thing to mention here is that documents are always freely sizable, which is nothing you expect from a carefully designed form, where controls are placed at concrete positions and have a fixed size.

The project is to
- extend the dialog runtime engine to (optionally) include data-aware form controls
- create a form designer for dialog-based forms (similar to the existing Basic Dialog IDE)
- implement persistence of dialog-based forms
- embed dialog-based forms into database documents (.odb)

Depending on more fine-grained planning, it might become apparent that not all of this can be done in the scope of a Google Summer of Code project, and reasonable milestones need to be defined.

* required skills C++, UNO
* useful skills: familiarity with OOo's database access and form API, as well as OOo's [http://api.openoffice.org/docs/common/ref/com/sun/star/awt/module-ix.html toolkit API]
* Contact: mailto:dev@dba.openoffice.org
* Mentor: Frank Schönheit - Frank.Schoenheit at Sun.Com

=== Embed Derby into OpenOffice.org Databases ===

OpenOffice.org Base features an abstract mechanism to embed database backend files into OOo databases (.odb). Currently, this is implemented for [http:///hsqldb.org HSQLDB], which is used as OOo's default database engine.

To allow this feature for other engines, one must:

* virtualize the engine's file access, so that it re-routes all its file operations through an abstract API.
* implement this API on the OOo Base side

The project is to do those implementations for [http://db.apache.org/derby Apache Derby database].

* required skills Java, C++
* useful skills: OOo's database access API, OOo's component technology (UNO)
* Contact: mailto:dev@dba.openoffice.org
* Mentor: Ocke Janssen - Ocke.Janssen at Sun.Com

==Calc==

===Integration of R into Calc===

Create an add-on component that allows a Calc user to let the [http://www.r-project.org/ R environment] do calculations on data from Calc cells and put the results into the spreadsheet again.

This should include a dialog to select input parameters and options, and allow results to be values or graph images. Note that the incompatible licenses (R is under GPL) have to be taken care of, possibly by starting R as a separate process.

Some more thoughts on the subject have been collected at [[Statistical Data Analysis Tool#Third Party Library Integration]].

* Required skills/knowledge: Some familiarity with statistical methods

; Contact
: dev@sc.openoffice.org
: Niklas.Nebel at sun.com

: Leonard Mada
: (on statistics and R syntax)
: discoleo at openoffice.org

===Watch Window===

A Watch Window is a separate, small window that remains "on top" and enables users to monitor a selected set of cells, see [http://www.openoffice.org/issues/show_bug.cgi?id=28386 issue 28386].

This could be implemented as an add-on component with a modeless dialog containing the list of watched cells as well as the UI to add or remove cells.

* Required skills/knowledge: Java or C++

; Contact
: dev@sc.openoffice.org
: Niklas.Nebel at sun.com

===Non-Linear Optimizer Development for Optimization Solver===
This task involves developing a new optimizer to solve general constrait non-linear model for the [[Optimization Solver]] component. There is now an independent optimizer testing & development framework for non-linear optimizer, so the applicant would not need to understand the entire OO.o code base.

Note that the code for [[Optimization Solver]] is still in the process of upstreaming, so the applicant would be working on a specific branch that contains the [[scsolver]] module.

* Required skills/knowledge: C++, some familiarity with operations research

; Contact
: dev@sc.openoffice.org
: kyoshida at novell dot com
: jody at novell dot com

===Unit Testing Framework for Optimization Solver===

The [[Optimization Solver]] component needs a unit-testing framework for its linear optimizer. This task would involve collecting a load of test cases (small and large) with known solutions, and write an automated unit-testing program for the linear portion of the optimizer code.

* Required skills/knowledge: C++

; Contact
: dev@sc.openoffice.org
: kyoshida at novell dot com
: jody at novell dot com

===Additional AutoFilter Functionality===

Add core and user interface support for additional forms of filtering
* Date based filters (eg current year/quarter)
* Multiple items without falling back on logical OR.
* Statistical filters (eg within N stddev of mean)

* Required skills/knowledge: C++, Familiarity with OOo frameworks.

; Contact
: mailto:dev@sc.openoffice.org
: jody at novell dot com

===Move Older Spreadsheet formats into an UNO Component===

Support for several formats still lives in the core calc module, and bloat it with little used functionality.
Moving the antiquated filters into a distinct component would be good introduction to UNO and the spreadsheet code.
If time permits the new component could have support for other simple spreadsheet formats, such as Applix.

* Required skills/knowledge: C++, Familiarity with OOo frameworks.

; Contact
: mailto:dev@sc.openoffice.org
: jody at novell dot com

==Extensions==

===OOo connector for External IDE for OOo scripting languages===

This project will solve the problem of lack of IDE for scripting languages in OOo. Scripts can be seen as macros in various languages and are complementary to Extensions.
Actually, only OOoBasic has its IDE embedded in OOo. Javascript and Beanshell have limited ones and python nothing. To avoid implementing different IDE for various languages into OOo, the proposed choice is to provide a connector to any external IDE

The project is dived into 2 complementary parts :
* defining and implementing common tools at OOo side to put the scipts at the correct place and manage OOo scripts menus
* implement an Eclipse extension as an IDE that could handle scripts in python language, using the previously defined OOo tools.

; Requirements
* Required skills/knowledge: java, python, UNO
* Usefull skills: Eclipse API, OOo API, IDE general knowledge

; Contact
: dev@extensions.openoffice.org
: LaurentGodard@openoffice.org

===OOo connector that allows users to interact with the main applications of the Suite in their cellphones===

Development of a Open Office plugin that makes possible inquiring for bluetooth devices in the area and then send, via OBEX protocol, a MIDP 2.0 java mobile application to a choosed device between the ones that have been found previously. In addition the plugin can start a bluetooth server that will listen for received messages, where this server will have an unique identifier, which is the same that was inserted in the sent mobile application.

This mobile JME application will allow user to navigate thought the system directories and the files available in a directory will be filtered by OO files. If the user selects one of the available OO files in the folder, the associated OO application will be opened at the target computer and the mobile application will show an device adapted interface, making this user able to interact with the Open Office applications at that computer: In Impress will be possible to control slide presentation in a slideshow, while a preview of the page is being shown at the device screen; In Calc will be possible to edit rows and columns and so create new spreadsheets; For Writer will be possible to read documents, edit and create new ones.

; Requirements
* Required skills/knowledge: XML, JSE, JME, UNO Api
* Usefull skills: Bluetooth Stack Protocol, BlueZ

; Contact
: brunogh at gmail.com
: lucastorri at gmail.com

=== Easy Language/Linguistics Switcher ===

In countries like India where each person know about 2/3 Indian languages and uses 2/3 scripts when s/he creates documents, easy access to language settings become very necessary. This project aims to provide an intuitive interface to control the install linguitic components for a particular language. Secondly input method control from inside the OpenOffice could also be incorporated.

* Required skills/knowledge: C++/Java
* Useful skills: Basic UNO API knowledge

; Contact
: RKVS Raman (rkvsraman@openoffice.org )

==Framework==

===Shell Extensions for Desktop file search and showing meta data in windows explorer needs to be rewritten for Vista===

Vista changed his mechanism to integrate those shell extensions incompatible. Extensions valid for Win98/2000/XP doesnt work any more. A set of new interfaces was designed. But they are available on Vista only. So OOo has to support two sets of shell extensions: one set for Win98/2000/XP and a new set for Vista and might following windows versions. For this project the new Vista extensions has to be implemented only.
See [http://www.openoffice.org/issues/show_bug.cgi?id=71112 71112] and [http://www.openoffice.org/issues/show_bug.cgi?id=70944 70944] for further informations.

* Required skills/knowledge: C++
* Useful skills: Windows API knowledge
* Requirements: Windows Vista 32 Bit

; Contact
: dev@framework.openoffice.org, Andreas.Schluens at sun.com

===Status bar control to display/change the language===

Currently the Writer lacks means to display the language in use. There's also no easy way to change the language as the user has to use the menu. A status bar control would help to solve these problems. It should help to determine about the language used at the cursor position or the document. The control should be implemented using existing UNO APIs.

* Required skills/knowledge: C++
* Useful skills: Basic UNO API knowledge

; Contact
: dev@framework.openoffice.org, Carsten.Driesner at sun.com
: dev@sw.openoffice.org, Thomas.Lange at sun.com

===Improving UI editing / coupling===

Currently all dialogs (along with most translated strings) are stored in a rather unusual binary resource file format, that has not had much love in the last decade. We need to write some new code that separates the process of designing & laying out the UI from the code - to allow UE to make our UI more beautiful, and allow future re-factoring. The existing Basic GUI dialog editor and it's XML format should be re-used, a simple C++ compatibility API created, and a number of dialogs converted to the new format.

* Required skills/knowledge: C++
* Useful skills: courage, stickability, X-rated code reading

; Contact
: michael.meeks at novell.com
: hfiguiere at novell.com

=== OpenOffice.org Based Workflow Framework ===

The one feature that is now begging for attention from OpneOffice.org is the colloboration and workflow. The workflow system should leverage on the Xforms support in OpenOffice.org and combine it with other Open Source Products like Shark ( http://www.enhydra.org/workflow/shark/index.html ) and JaWe ( http://www.enhydra.org/workflow/jawe/index.html ) to create an integrated Xforms based workflow system. The product should have a centralized server component and a client component. The server component interfaces with Process repositories and Process Instance repositories and has Java based Administration and Definition tools. The client component could be a toolbar which sits as an addon into the office suite.
The goal of this project is to provide document workflow from within OpenOffice.org.

; Tasks
* Make a prototype of docment workflow.

; Required skills/knowledge:
* Java/J2EE
* C/C++
* knowledge of XForms Document Model

; Contact
: RKVS Raman (rkvsraman@openoffice.org)

==Graphics==

===Draw/Impress: SVG Import Filter===

[http://www.w3.org/Graphics/SVG/ SVG (Scalable Vector Graphics)] is a vector graphics format that describes 2D graphics in XML.

There's no native SVG import filter for OOo. There exists an [http://www.ipd.uka.de/~hauma/svg-import/ external one], but unfortunately it has very strong dependencies - [http://java.sun.com/javase/downloads/index.jsp Java 5.0], and [http://xmlgraphics.apache.org/batik/ Batik]. The goal of this task is to create a new implementation that does not require any too big libraries.

A proof of concept implementation written in C++ using the [http://wiki.services.openoffice.org/wiki/Uno UNO] [http://api.openoffice.org/docs/common/ref/com/sun/star/drawing/module-ix.html Drawing API] and a lighweight [http://cairographics.org/libsvg libsvg library] exists [http://svn.gnome.org/viewcvs/ooo-build/trunk/patches/src680/svg-import.diff here], but it needs a lot of work to be really usable. Another problem is that libsvg does not seem to be too actively maintained; so the real implementation should use OOo's [http://wiki.services.openoffice.org/wiki/FastParser internal XML parser].

More information is available in [http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2006-10.html#2006-10-02T17_14_44.htm Kendy's blog].

* Required skills/knowledge: C++, XML knowledge is a plus

; Contact
: Jan Holesovsky - kendy at openoffice org
: Fridrich Strba - fridrich_strba at openoffice org

===Impress: OpenGL rendered transitions===
The goal is to add 3D transitions to the Impress application. Transition is an animation where one page is visible in the beginning and another in the end. It is used during presentation slideshow to switch pages.

In the process of implementing OpenGL transitions an UNO API should be added to slideshow code, so that OpenGL transitions engine might be created as standalone UNO component. Current transitions should be refactored to another UNO component.

The engine will get the previous and next pages and should render the transition at given speed.

The participant should also implement at least 5 OpenGL transitions, rendered by the UNO component.

* Reguired skills/knowledge: C++, OpenGL. familiarity with UNO is welcomed

;Contact:
:mailto:dev@graphics.openoffice.org
:Thorsten Behrens - thb at openoffice org
:Radek Doulik - radekdoulik at openoffice org

===Impress: Import Apple Keynote presentations===
Write an importer to import XML based Apple Keynote presentation files.

An incomplete format documentation is [http://developer.apple.com/documentation/AppleApplications/Conceptual/iWork2-0_XML/Chapter02/chapter_2_section_1.html#//apple_ref/doc/uid/TP40002479-CH203-DontLinkElementID_65 available on ADC], therefore reverse engineering will be needed. Since the file format change accross the various versions, [http://developer.apple.com/appleapplications/keynote-apxl.html version 1.0] can also be opted.

* Required skills: C++. Familiarity with UNO is welcome.

;Contact:
:mailto:dev@graphics.openoffice.org
:Hubert Figuiere - hub AT openoffice org

==ODF Toolkit==

=== Tools and best practice samples for ODF creation and manipulation===

We already have some code snippets in Java and C# and looking for help to extend these tool sets or to provide tool sets in other languages. These tool sets are designed to offer basic ODF functionality even outside of OO.o.

* Required skills/knowledge: Java or C# or Perl or C++ ...
* Useful skills: ODF, XML

; Contact
: dev@odftoolkit.openoffice.org,
: Dieter Loeschky at sun.com

== Porting: Mac OS X native port ==

=== '''Complete User Interface respecting Aqua Human Interface Guidelines (Aqua Only)''' ===

*Concerns: OpenOffice.org 2.x for Mac OS X Aqua only

*Skills: Knowledge of languages C/C++ Mac OS X APIs and Application frameworks like Carbon

Original OpenOffice.org vcl widgets are not Aqua HIG compliant, and we need to implement all controls, respecting Aqua Human Interface Guidelines, some will use HIView, or HITheme or even other part of Carbon API.

*Tasks: some controls are already implemented, but some are still missing.

The job consists in write the code and implement:

- tabs (implement and bind the TabitemValue class, using Carbon API)

- spinbuttons (implement and bind SpinbuttonValue class, using Carbon API)

- comboboxes (implement and use HICombobox)

- listboxes (work already started)

- texts in comboboxes / listboxes (better task definition to be completed)

- other types of controls: highlight, respect dimensions/spacing ..etc

- Windows background (using Aqua theme)

;Proposed by: Eric Bachard
;Contact: mac@porting.openoffice.org
;Mentor: Eric Bachard ( ericb at openoffice dot org )

=== Mac OS X native printing (Aqua only) ===

Concerns: OpenOffice.org 2.x for Mac OS X Aqua only

Objective: currently, the native printing implementation is missing on Aqua port and needs to be implemented.

The objective is to use the same box users have in any Mac application.

Skills: Knowledge of languages C/C++ Mac OS X APIs and Application frameworks like Carbon and /or Cocoa

Tasks:

Familiarize with the Mac OS X printing APIs

Familiarize with the current OOo printing API

Expected: Write code to Implement native printing with Aqua version of OpenOffice.org:

; Contact
: mac@porting.openoffice.org
: fheckl at openoffice dot org

;Proposed by: Florian Heckl

;Mentor: Florian Heckl

=== Mac OS X Address book integration (Aqua / X11) ===

Synopsis: OOo currently is integrated with the Mozilla address book but not with the native Mac OS X address book. This is annoying for Mac OS X user. For better system integration it would be desirable to integrate with the Mac OS X address book.

Concerns: OpenOffice.org 2.x for Mac OS X (both Aqua and X11 versions)

;Skills: Knowledge of languages C/C++, Mac OS X APIs and Application frameworks like Carbon or Cocoa for instance, knowledge of the Mac OS X address book APIs

;Tasks:

Familiarize with the Mac OS X address book APIs

Familiarize with the current OOo Mozilla address book integration

Make a prototype for OOo Mac OS X address book integration

Document all produced code and aspects, Extend the principles to support docuemnt (text/media) Drag'n Drop.

;Contact
mac@porting.openoffice.org

;Mentor: Sebastien Plisson

==VBA==

===Word macro compatibility===

Recently Sun and Novell announced to pool resources to provide VBA macro compatability see [http://blogs.sun.com/GullFOSS/entry/sun_and_novell_work_together here].

Currently work in the project is concentrated on providing Excel support by
* providing the framework for the compatibiltiy api via a plugable component
* modifying the basic engine to support more compatibility features
* porting the [http://wiki.services.openoffice.org/wiki/Helperapi helperapi] code (for excel) to c++ (see. [http://wiki.services.openoffice.org/wiki/VBA here] & [http://wiki.services.openoffice.org/wiki/Porting_notes here])

Tasks

* extend the base framework by developing helper objects and implementations to be used by both the excel and writer compatibility object implementations
* port the existing (word) helper api objects from Java to C++

Required skills/knowledge

* C++
* Java
useful skills:

* knowledge of OOo's writer access API
* knowledge of OOo's component technology (UNO)
* experience with VBA macros and Word VBA api

Mentor/Contact
* noel.power at novell dot com

== Writer ==

===Writer: Better "Notes" functionality===

The "Notes" functionality in Writer could be better in terms of usability and does not look very appealing.

* Required skills/knowledge: C++

; Contact
: dev@sw.openoffice.org
: Mathias.Bauer at sun.com

; Resources
[http://blogs.linux.ie/caolan/2007/03/12/notesmarginnotes-in-sw/ hopefully helpful illustrative patch]

===MS Works Import Filter===

Unlike its proprietary derivatives, OpenOffice.org lacks MS Works import filter. The creation of MS Works import filter is one of functionalities requested by our users. There is a basic import filter work started and the result is to be found in CWS wpsimport01. This filter, based on recently started libwps[http://libwps.sourceforge.net] library is offering only limited number of features converted. It is desirable to build on this work and improve this library/filter so that the quality meets industry standards.

* Required skills/knowledge: C++, solid knowledge of MS Works wordprocessing document file-format and of libwps library.

; Contact
: mailto:dev@sw.openoffice.org
: fridrich_strba at openoffice.org
: freuter at novell.com

===RTF Generator===

The current RTF export of OpenOffice.org is not as good as the export to the Word (.doc) format. Parsing the generated Word format stream with a Word tokenizer and handing over the generated events to an RTF generator would lead to an RTF export filter with the same quality as the binary Word export filter. Remark: the tokenizer itself isn't complete today but in its current state covers enough parts of the Word format to make this a valuable project for the planned time span.

* Required skills/knowledge: C++, some knowledge about the Word file format would be a plus

; Contact
: dev@sw.openoffice.org
: Henning.Brinkmann at sun.com

=== Logging framework ===

During the import/export process from alien file formats there might be some features which can not be mapped entirely.
The goal of this project is to provide a loggin framework for the new domainmapper of the writer filter project, which
allow the domainmapper to notify the user of such mapping problems.

* Required skills/knowledge: C++

; Contact
: mailto:dev@sw.openoffice.org
: Florian Reuter (freuter at novell.com)
: Fridrich Strba (fridrich_strba at openoffice org)

=== UOF import filter ===

Specification for the Chinese office file format based on XML (UOF for short) is a National Standard of the People’s Republic of China. The open source project " ODF‑UOF Converter" hosted by Peking University have been finished in October, 2006. More information is available in http://odf-to-uof.sourceforge.net/index.html.

The goal of this project is to provide interoperability with UOF documents.

; Tasks
* Make a prototype of UOF import filter for OOo.

; Required skills/knowledge:
* C++
* knowledge of ODF, UOF
* knowledge of OOo's xml filter

; Contact
: mailto:dev@sw.openoffice.org
: Fong Lin (pflin@novell.com)
: Jian Hua (jjiao@novell.com)

=New Tasks=

If you have a task that is challenging enough, and there is an OpenOffice.org Project Member willing to mentor the task, feel free to coordinate with the appropriate project lead. If the appropriate project has been found and it supports the task, add it below and make sure the mentor applies with the web app.

Each entry should contain the task description, required skills, project mailing list for discussion and personal contact. Links to the [[To-Dos]] are appreciated provided that the task is well described there ;-)

===Example entry===

This is just an example - the real entry must not start with a space at the beginning
of the line.
A full description of the task should be here; one that will help to see that this task
is important, and interesting to hack on. Alternatively it could be an exact link to
the description that is already in [[To-Dos]].

* Required skills/knowledge: Language, technology1, technology2, ...

; Contact
: dev@project.openoffice.org
: The.Mentor at organization com

=Advise for Student Applications=

'''The application period is over.'''

Mentoring capacities are limited, so we depend on your dedication during the preparation of the detailed specification and description of the outcome.

Please review the [http://code.google.com/support/bin/topic.py?topic=10442 FAQ]
and the
[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants guide to the web app]. Be sure to take the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents advice for students] seriously.
Don't hesitate to raise questions about tasks on the project mailing list mentioned in the task description before you send your application. We are glad to receive many qualified submissions touching on the information mentioned in the [http://code.google.com/support/bin/answer.py?answer=60306&topic=10727 knowledge base].

And then - '''[http://code.google.com/soc/student_step1.html apply]''' for an OpenOffice.org task.

Thanks and Good luck!

Summer of Code 2007

2007-03-28T19:33:46Z

Plipli: /* Mac OS X Address book integration (Aqua / X11) */

Similar to [[SummerOfCode2006|last year]], OpenOffice.org is participating in the [http://code.google.com/soc/ Google Summer of Code](tm) initiative sponsored by Google.

This page collects some suitable task suggestions we got many applications for. We would be glad to support a few projects. The review is in progress and results can be expected for
[http://code.google.com/support/bin/answer.py?answer=60325&topic=10729 April 11].

=Task Proposals=

==API==

===UNO specifications changes in Eclipse Integration===

This project aims at improving the way to develop OpenOffice.org extensions and UNO components using Eclipse. This project should help the developer to changes its specifications easily. This project could be parted into several smaller parts.

See [[EclipseIntegration_ToDo#IDL_files_modification_assistance | the Todo task description]] for further informations.

* Required skills/knowledge: Java, Grammar & Compilers
* Usefull skills: Eclipse API, JavaCC, UNO & UNO IDL

; Contact
: dev@api.openoffice.org
: CedricBosdo at openoffice.org

== Base ==

=== Joins in dBase Queries ===

Queries to dBase files can currently contain one table only. Scope of the project is to enhance Base' built-in simple query engine to be capable of executing statements line <code>SELECT table1.field1, table2.field2 FROM table1, table2</code>. The dBase driver, the text/csv driver, and the Spreadsheet driver would all benefit from this extension.

Be prepared to dig around here before starting the project, the project touches low-level core implementations, including some heavy-to-read STL stuff, so be prepared to invest some time before writing the first line of code.

* required skills C++, SQL knowledge
* useful skills: Lexx and Yacc
* Contact: mailto:dev@dba.openoffice.org
* Mentor: Ocke Janssen - Ocke.Janssen at Sun.Com

=== Dialogs with Form Functionality ===

When creating a form, the user always needs to bother with a Writer document. Very often, this is much too oversized. It would be sufficient to have a simple dialog which contains all the data access controls.

The advantage would be to not slay the user with things she does not bother – a writer document offers a lot of possibilities which are not relevant for a form. In some cases, a full writer document does even contradict to what users expect from a form – one thing to mention here is that documents are always freely sizable, which is nothing you expect from a carefully designed form, where controls are placed at concrete positions and have a fixed size.

The project is to
- extend the dialog runtime engine to (optionally) include data-aware form controls
- create a form designer for dialog-based forms (similar to the existing Basic Dialog IDE)
- implement persistence of dialog-based forms
- embed dialog-based forms into database documents (.odb)

Depending on more fine-grained planning, it might become apparent that not all of this can be done in the scope of a Google Summer of Code project, and reasonable milestones need to be defined.

* required skills C++, UNO
* useful skills: familiarity with OOo's database access and form API, as well as OOo's [http://api.openoffice.org/docs/common/ref/com/sun/star/awt/module-ix.html toolkit API]
* Contact: mailto:dev@dba.openoffice.org
* Mentor: Frank Schönheit - Frank.Schoenheit at Sun.Com

=== Embed Derby into OpenOffice.org Databases ===

OpenOffice.org Base features an abstract mechanism to embed database backend files into OOo databases (.odb). Currently, this is implemented for [http:///hsqldb.org HSQLDB], which is used as OOo's default database engine.

To allow this feature for other engines, one must:

* virtualize the engine's file access, so that it re-routes all its file operations through an abstract API.
* implement this API on the OOo Base side

The project is to do those implementations for [http://db.apache.org/derby Apache Derby database].

* required skills Java, C++
* useful skills: OOo's database access API, OOo's component technology (UNO)
* Contact: mailto:dev@dba.openoffice.org
* Mentor: Ocke Janssen - Ocke.Janssen at Sun.Com

==Calc==

===Integration of R into Calc===

Create an add-on component that allows a Calc user to let the [http://www.r-project.org/ R environment] do calculations on data from Calc cells and put the results into the spreadsheet again.

This should include a dialog to select input parameters and options, and allow results to be values or graph images. Note that the incompatible licenses (R is under GPL) have to be taken care of, possibly by starting R as a separate process.

Some more thoughts on the subject have been collected at [[Statistical Data Analysis Tool#Third Party Library Integration]].

* Required skills/knowledge: Some familiarity with statistical methods

; Contact
: dev@sc.openoffice.org
: Niklas.Nebel at sun.com

: Leonard Mada
: (on statistics and R syntax)
: discoleo at openoffice.org

===Watch Window===

A Watch Window is a separate, small window that remains "on top" and enables users to monitor a selected set of cells, see [http://www.openoffice.org/issues/show_bug.cgi?id=28386 issue 28386].

This could be implemented as an add-on component with a modeless dialog containing the list of watched cells as well as the UI to add or remove cells.

* Required skills/knowledge: Java or C++

; Contact
: dev@sc.openoffice.org
: Niklas.Nebel at sun.com

===Non-Linear Optimizer Development for Optimization Solver===
This task involves developing a new optimizer to solve general constrait non-linear model for the [[Optimization Solver]] component. There is now an independent optimizer testing & development framework for non-linear optimizer, so the applicant would not need to understand the entire OO.o code base.

Note that the code for [[Optimization Solver]] is still in the process of upstreaming, so the applicant would be working on a specific branch that contains the [[scsolver]] module.

* Required skills/knowledge: C++, some familiarity with operations research

; Contact
: dev@sc.openoffice.org
: kyoshida at novell dot com
: jody at novell dot com

===Unit Testing Framework for Optimization Solver===

The [[Optimization Solver]] component needs a unit-testing framework for its linear optimizer. This task would involve collecting a load of test cases (small and large) with known solutions, and write an automated unit-testing program for the linear portion of the optimizer code.

* Required skills/knowledge: C++

; Contact
: dev@sc.openoffice.org
: kyoshida at novell dot com
: jody at novell dot com

===Additional AutoFilter Functionality===

Add core and user interface support for additional forms of filtering
* Date based filters (eg current year/quarter)
* Multiple items without falling back on logical OR.
* Statistical filters (eg within N stddev of mean)

* Required skills/knowledge: C++, Familiarity with OOo frameworks.

; Contact
: mailto:dev@sc.openoffice.org
: jody at novell dot com

===Move Older Spreadsheet formats into an UNO Component===

Support for several formats still lives in the core calc module, and bloat it with little used functionality.
Moving the antiquated filters into a distinct component would be good introduction to UNO and the spreadsheet code.
If time permits the new component could have support for other simple spreadsheet formats, such as Applix.

* Required skills/knowledge: C++, Familiarity with OOo frameworks.

; Contact
: mailto:dev@sc.openoffice.org
: jody at novell dot com

==Extensions==

===OOo connector for External IDE for OOo scripting languages===

This project will solve the problem of lack of IDE for scripting languages in OOo. Scripts can be seen as macros in various languages and are complementary to Extensions.
Actually, only OOoBasic has its IDE embedded in OOo. Javascript and Beanshell have limited ones and python nothing. To avoid implementing different IDE for various languages into OOo, the proposed choice is to provide a connector to any external IDE

The project is dived into 2 complementary parts :
* defining and implementing common tools at OOo side to put the scipts at the correct place and manage OOo scripts menus
* implement an Eclipse extension as an IDE that could handle scripts in python language, using the previously defined OOo tools.

; Requirements
* Required skills/knowledge: java, python, UNO
* Usefull skills: Eclipse API, OOo API, IDE general knowledge

; Contact
: dev@extensions.openoffice.org
: LaurentGodard@openoffice.org

===OOo connector that allows users to interact with the main applications of the Suite in their cellphones===

Development of a Open Office plugin that makes possible inquiring for bluetooth devices in the area and then send, via OBEX protocol, a MIDP 2.0 java mobile application to a choosed device between the ones that have been found previously. In addition the plugin can start a bluetooth server that will listen for received messages, where this server will have an unique identifier, which is the same that was inserted in the sent mobile application.

This mobile JME application will allow user to navigate thought the system directories and the files available in a directory will be filtered by OO files. If the user selects one of the available OO files in the folder, the associated OO application will be opened at the target computer and the mobile application will show an device adapted interface, making this user able to interact with the Open Office applications at that computer: In Impress will be possible to control slide presentation in a slideshow, while a preview of the page is being shown at the device screen; In Calc will be possible to edit rows and columns and so create new spreadsheets; For Writer will be possible to read documents, edit and create new ones.

; Requirements
* Required skills/knowledge: XML, JSE, JME, UNO Api
* Usefull skills: Bluetooth Stack Protocol, BlueZ

; Contact
: brunogh at gmail.com
: lucastorri at gmail.com

=== Easy Language/Linguistics Switcher ===

In countries like India where each person know about 2/3 Indian languages and uses 2/3 scripts when s/he creates documents, easy access to language settings become very necessary. This project aims to provide an intuitive interface to control the install linguitic components for a particular language. Secondly input method control from inside the OpenOffice could also be incorporated.

* Required skills/knowledge: C++/Java
* Useful skills: Basic UNO API knowledge

; Contact
: RKVS Raman (rkvsraman@openoffice.org )

==Framework==

===Shell Extensions for Desktop file search and showing meta data in windows explorer needs to be rewritten for Vista===

Vista changed his mechanism to integrate those shell extensions incompatible. Extensions valid for Win98/2000/XP doesnt work any more. A set of new interfaces was designed. But they are available on Vista only. So OOo has to support two sets of shell extensions: one set for Win98/2000/XP and a new set for Vista and might following windows versions. For this project the new Vista extensions has to be implemented only.
See [http://www.openoffice.org/issues/show_bug.cgi?id=71112 71112] and [http://www.openoffice.org/issues/show_bug.cgi?id=70944 70944] for further informations.

* Required skills/knowledge: C++
* Useful skills: Windows API knowledge
* Requirements: Windows Vista 32 Bit

; Contact
: dev@framework.openoffice.org, Andreas.Schluens at sun.com

===Status bar control to display/change the language===

Currently the Writer lacks means to display the language in use. There's also no easy way to change the language as the user has to use the menu. A status bar control would help to solve these problems. It should help to determine about the language used at the cursor position or the document. The control should be implemented using existing UNO APIs.

* Required skills/knowledge: C++
* Useful skills: Basic UNO API knowledge

; Contact
: dev@framework.openoffice.org, Carsten.Driesner at sun.com
: dev@sw.openoffice.org, Thomas.Lange at sun.com

===Improving UI editing / coupling===

Currently all dialogs (along with most translated strings) are stored in a rather unusual binary resource file format, that has not had much love in the last decade. We need to write some new code that separates the process of designing & laying out the UI from the code - to allow UE to make our UI more beautiful, and allow future re-factoring. The existing Basic GUI dialog editor and it's XML format should be re-used, a simple C++ compatibility API created, and a number of dialogs converted to the new format.

* Required skills/knowledge: C++
* Useful skills: courage, stickability, X-rated code reading

; Contact
: michael.meeks at novell.com
: hfiguiere at novell.com

=== OpenOffice.org Based Workflow Framework ===

The one feature that is now begging for attention from OpneOffice.org is the colloboration and workflow. The workflow system should leverage on the Xforms support in OpenOffice.org and combine it with other Open Source Products like Shark ( http://www.enhydra.org/workflow/shark/index.html ) and JaWe ( http://www.enhydra.org/workflow/jawe/index.html ) to create an integrated Xforms based workflow system. The product should have a centralized server component and a client component. The server component interfaces with Process repositories and Process Instance repositories and has Java based Administration and Definition tools. The client component could be a toolbar which sits as an addon into the office suite.
The goal of this project is to provide document workflow from within OpenOffice.org.

; Tasks
* Make a prototype of docment workflow.

; Required skills/knowledge:
* Java/J2EE
* C/C++
* knowledge of XForms Document Model

; Contact
: RKVS Raman (rkvsraman@openoffice.org)

==Graphics==

===Draw/Impress: SVG Import Filter===

[http://www.w3.org/Graphics/SVG/ SVG (Scalable Vector Graphics)] is a vector graphics format that describes 2D graphics in XML.

There's no native SVG import filter for OOo. There exists an [http://www.ipd.uka.de/~hauma/svg-import/ external one], but unfortunately it has very strong dependencies - [http://java.sun.com/javase/downloads/index.jsp Java 5.0], and [http://xmlgraphics.apache.org/batik/ Batik]. The goal of this task is to create a new implementation that does not require any too big libraries.

A proof of concept implementation written in C++ using the [http://wiki.services.openoffice.org/wiki/Uno UNO] [http://api.openoffice.org/docs/common/ref/com/sun/star/drawing/module-ix.html Drawing API] and a lighweight [http://cairographics.org/libsvg libsvg library] exists [http://svn.gnome.org/viewcvs/ooo-build/trunk/patches/src680/svg-import.diff here], but it needs a lot of work to be really usable. Another problem is that libsvg does not seem to be too actively maintained; so the real implementation should use OOo's [http://wiki.services.openoffice.org/wiki/FastParser internal XML parser].

More information is available in [http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2006-10.html#2006-10-02T17_14_44.htm Kendy's blog].

* Required skills/knowledge: C++, XML knowledge is a plus

; Contact
: Jan Holesovsky - kendy at openoffice org
: Fridrich Strba - fridrich_strba at openoffice org

===Impress: OpenGL rendered transitions===
The goal is to add 3D transitions to the Impress application. Transition is an animation where one page is visible in the beginning and another in the end. It is used during presentation slideshow to switch pages.

In the process of implementing OpenGL transitions an UNO API should be added to slideshow code, so that OpenGL transitions engine might be created as standalone UNO component. Current transitions should be refactored to another UNO component.

The engine will get the previous and next pages and should render the transition at given speed.

The participant should also implement at least 5 OpenGL transitions, rendered by the UNO component.

* Reguired skills/knowledge: C++, OpenGL. familiarity with UNO is welcomed

;Contact:
:mailto:dev@graphics.openoffice.org
:Thorsten Behrens - thb at openoffice org
:Radek Doulik - radekdoulik at openoffice org

===Impress: Import Apple Keynote presentations===
Write an importer to import XML based Apple Keynote presentation files.

An incomplete format documentation is [http://developer.apple.com/documentation/AppleApplications/Conceptual/iWork2-0_XML/Chapter02/chapter_2_section_1.html#//apple_ref/doc/uid/TP40002479-CH203-DontLinkElementID_65 available on ADC], therefore reverse engineering will be needed. Since the file format change accross the various versions, [http://developer.apple.com/appleapplications/keynote-apxl.html version 1.0] can also be opted.

* Required skills: C++. Familiarity with UNO is welcome.

;Contact:
:mailto:dev@graphics.openoffice.org
:Hubert Figuiere - hub AT openoffice org

==ODF Toolkit==

=== Tools and best practice samples for ODF creation and manipulation===

We already have some code snippets in Java and C# and looking for help to extend these tool sets or to provide tool sets in other languages. These tool sets are designed to offer basic ODF functionality even outside of OO.o.

* Required skills/knowledge: Java or C# or Perl or C++ ...
* Useful skills: ODF, XML

; Contact
: dev@odftoolkit.openoffice.org,
: Dieter Loeschky at sun.com

== Porting: Mac OS X native port ==

=== '''Complete User Interface respecting Aqua Human Interface Guidelines (Aqua Only)''' ===

*Concerns: OpenOffice.org 2.x for Mac OS X Aqua only

*Skills: Knowledge of languages C/C++ Mac OS X APIs and Application frameworks like Carbon

Original OpenOffice.org vcl widgets are not Aqua HIG compliant, and we need to implement all controls, respecting Aqua Human Interface Guidelines, some will use HIView, or HITheme or even other part of Carbon API.

*Tasks: some controls are already implemented, but some are still missing.

The job consists in write the code and implement:

- tabs (implement and bind the TabitemValue class, using Carbon API)

- spinbuttons (implement and bind SpinbuttonValue class, using Carbon API)

- comboboxes (implement and use HICombobox)

- listboxes (work already started)

- texts in comboboxes / listboxes (better task definition to be completed)

- other types of controls: highlight, respect dimensions/spacing ..etc

- Windows background (using Aqua theme)

;Proposed by: Eric Bachard
;Contact: mac@porting.openoffice.org
;Mentor: Eric Bachard ( ericb at openoffice dot org )

=== Mac OS X native printing (Aqua only) ===

Concerns: OpenOffice.org 2.x for Mac OS X Aqua only

Objective: currently, the native printing implementation is missing on Aqua port and needs to be implemented.

The objective is to use the same box users have in any Mac application.

Skills: Knowledge of languages C/C++ Mac OS X APIs and Application frameworks like Carbon and /or Cocoa

Tasks:

Familiarize with the Mac OS X printing APIs

Familiarize with the current OOo printing API

Expected: Write code to Implement native printing with Aqua version of OpenOffice.org:

; Contact
: mac@porting.openoffice.org
: fheckl at openoffice dot org

;Proposed by: Florian Heckl

;Mentor: Florian Heckl

=== Mac OS X Address book integration (Aqua / X11) ===

Synopsis: OOo currently is integrated with the Mozilla address book but not with the native Mac OS X address book. This is annoying for Mac OS X user. For better system integration it would be desirable to integrate with the Mac OS X address book.

Concerns: OpenOffice.org 2.x for Mac OS X (both Aqua and X11 versions)

;Skills: Knowledge of languages C/C++, Mac OS X APIs and Application frameworks like Carbon or Cocoa for instance, knowledge of the Mac OS X address book APIs

;Tasks:

Familiarize with the Mac OS X address book APIs

Familiarize with the current OOo Mozilla address book integration

Make a prototype for OOo Mac OS X address book integration

;Contact
mac@porting.openoffice.org

;Mentor: Sebastien Plisson

==VBA==

===Word macro compatibility===

Recently Sun and Novell announced to pool resources to provide VBA macro compatability see [http://blogs.sun.com/GullFOSS/entry/sun_and_novell_work_together here].

Currently work in the project is concentrated on providing Excel support by
* providing the framework for the compatibiltiy api via a plugable component
* modifying the basic engine to support more compatibility features
* porting the [http://wiki.services.openoffice.org/wiki/Helperapi helperapi] code (for excel) to c++ (see. [http://wiki.services.openoffice.org/wiki/VBA here] & [http://wiki.services.openoffice.org/wiki/Porting_notes here])

Tasks

* extend the base framework by developing helper objects and implementations to be used by both the excel and writer compatibility object implementations
* port the existing (word) helper api objects from Java to C++

Required skills/knowledge

* C++
* Java
useful skills:

* knowledge of OOo's writer access API
* knowledge of OOo's component technology (UNO)
* experience with VBA macros and Word VBA api

Mentor/Contact
* noel.power at novell dot com

== Writer ==

===Writer: Better "Notes" functionality===

The "Notes" functionality in Writer could be better in terms of usability and does not look very appealing.

* Required skills/knowledge: C++

; Contact
: dev@sw.openoffice.org
: Mathias.Bauer at sun.com

; Resources
[http://blogs.linux.ie/caolan/2007/03/12/notesmarginnotes-in-sw/ hopefully helpful illustrative patch]

===MS Works Import Filter===

Unlike its proprietary derivatives, OpenOffice.org lacks MS Works import filter. The creation of MS Works import filter is one of functionalities requested by our users. There is a basic import filter work started and the result is to be found in CWS wpsimport01. This filter, based on recently started libwps[http://libwps.sourceforge.net] library is offering only limited number of features converted. It is desirable to build on this work and improve this library/filter so that the quality meets industry standards.

* Required skills/knowledge: C++, solid knowledge of MS Works wordprocessing document file-format and of libwps library.

; Contact
: mailto:dev@sw.openoffice.org
: fridrich_strba at openoffice.org
: freuter at novell.com

===RTF Generator===

The current RTF export of OpenOffice.org is not as good as the export to the Word (.doc) format. Parsing the generated Word format stream with a Word tokenizer and handing over the generated events to an RTF generator would lead to an RTF export filter with the same quality as the binary Word export filter. Remark: the tokenizer itself isn't complete today but in its current state covers enough parts of the Word format to make this a valuable project for the planned time span.

* Required skills/knowledge: C++, some knowledge about the Word file format would be a plus

; Contact
: dev@sw.openoffice.org
: Henning.Brinkmann at sun.com

=== Logging framework ===

During the import/export process from alien file formats there might be some features which can not be mapped entirely.
The goal of this project is to provide a loggin framework for the new domainmapper of the writer filter project, which
allow the domainmapper to notify the user of such mapping problems.

* Required skills/knowledge: C++

; Contact
: mailto:dev@sw.openoffice.org
: Florian Reuter (freuter at novell.com)
: Fridrich Strba (fridrich_strba at openoffice org)

=== UOF import filter ===

Specification for the Chinese office file format based on XML (UOF for short) is a National Standard of the People’s Republic of China. The open source project " ODF‑UOF Converter" hosted by Peking University have been finished in October, 2006. More information is available in http://odf-to-uof.sourceforge.net/index.html.

The goal of this project is to provide interoperability with UOF documents.

; Tasks
* Make a prototype of UOF import filter for OOo.

; Required skills/knowledge:
* C++
* knowledge of ODF, UOF
* knowledge of OOo's xml filter

; Contact
: mailto:dev@sw.openoffice.org
: Fong Lin (pflin@novell.com)
: Jian Hua (jjiao@novell.com)

=New Tasks=

If you have a task that is challenging enough, and there is an OpenOffice.org Project Member willing to mentor the task, feel free to coordinate with the appropriate project lead. If the appropriate project has been found and it supports the task, add it below and make sure the mentor applies with the web app.

Each entry should contain the task description, required skills, project mailing list for discussion and personal contact. Links to the [[To-Dos]] are appreciated provided that the task is well described there ;-)

===Example entry===

This is just an example - the real entry must not start with a space at the beginning
of the line.
A full description of the task should be here; one that will help to see that this task
is important, and interesting to hack on. Alternatively it could be an exact link to
the description that is already in [[To-Dos]].

* Required skills/knowledge: Language, technology1, technology2, ...

; Contact
: dev@project.openoffice.org
: The.Mentor at organization com

=Advise for Student Applications=

'''The application period is over.'''

Mentoring capacities are limited, so we depend on your dedication during the preparation of the detailed specification and description of the outcome.

Please review the [http://code.google.com/support/bin/topic.py?topic=10442 FAQ]
and the
[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants guide to the web app]. Be sure to take the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents advice for students] seriously.
Don't hesitate to raise questions about tasks on the project mailing list mentioned in the task description before you send your application. We are glad to receive many qualified submissions touching on the information mentioned in the [http://code.google.com/support/bin/answer.py?answer=60306&topic=10727 knowledge base].

And then - '''[http://code.google.com/soc/student_step1.html apply]''' for an OpenOffice.org task.

Thanks and Good luck!

Mac OS X Implementing HIView

2007-03-25T07:50:31Z

Plipli: /* VCL / AQUA traces deductions (plipli) */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

HI* events definitions in aquavclevents.hxx

Event handler implementation in HandleHIViewEvent()

The use of HandleHIViewEvent() in AquaSalFrame::CreateNewSystemWindow()

The use of HI* controls, in vcl, when ::CreateNewSystemWindow() is used, calling HandleHIViewEvent(), when HI* events are detected in the frame.

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== Reengineer Events handling (plipli) ==

Main files : salframe.cxx, salframe.h, aquavclevents.hxx

Description :

In OOo, the class SalFrame defines the object containing :
- a window
- other objects related to window management system

AquaSalFrame is the native implementation of VCL Salframe.

== VCL / AQUA traces deductions (ericb) ==
1)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

User:Ericb

2007-03-25T07:28:51Z

Plipli: /* '''Mac OS X Implementing HIView''' */

==Public Documentation License Notice==

The contents of this Documentation (excepted Native Port Roadmap),are subject to the Public Documentation License Version 1.0 (the "License"); you may only use this Documentation if you comply with the terms of this License. A copy of the License is available at http://www.openoffice.org/licenses/PDL.html.
The Original Documentation is "Mac OS X native port". The Initial Writer of the Original Documentation is (JCA) Eric Bachard (C) 2005-2006. All Rights Reserved. (Initial Writer contact(s): ericb@openoffice.org.)

=='''Mac OS X Native port'''==

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">
'''The first Mac OS X native port objective is make OpenOffice.org run without X11 use, to make it a real Mac application.'''

'''The second one is respect Aqua Human interface Guidelines'''

''' This is a long term work, and every help and/or contributions, like donations** are welcome.'''
</div>

**see http://contributing.openoffice.org/index.html

=='''Native Port Roadmap'''==

==='''2006'''===

* June 2006: work in progress

- Basis: frame, instances, threads, drawing, painting, resizing (Stephan Schaefer, Tino Rachui)

Done:
implement threads
create, manage instance
create, manage windows (including parents)
create, manage events
create manage drawing, resizing
create, add menus (Pavel Janik)
toggle window fullscreen (Pierre de Filippis)
make font server work (Stephan Schaefer)

* Current status font support (Stephan Schaefer, 2006/07/28): the following features are basically working now
** font selection
** font size
** simple font attributes (bold, italic)

Next step: document first part, and propose design

- native filepicker (Pavel Janik, Florian Heckl)

- native printing implementation (Oliver?)

- native font implementation (Eric Bachard)

* September 2006:

- first proofs of concept: fonts, filepicker .. (more?)
- show the results (OOoCon 2006?)

==='''2007'''===

* January 2007: first alpha implementation

=='''Strategy for native port'''==

'''Possible Actions''':

Identify us:

#Complete the arrays below
#Update photos on frapr.com?

Share the work:

#Divide the work between little Teams
#Update Todo list regularly -> needs some love these days ... [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s]

Help:

#Teach tools between us
#Do a debug party on IRC
#write documentation

Meet us:

#IRC
#Mac Meeting (like nov2005 in Hamburg?)

Inform:

#Update website regularly
#Blogs

'''WHO''':

Mac Team:

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
|Developer \ skills || build || write code || code review || debug/trace (higher is better) || contribute to documentation ||
|-
|ericb|| x || x || || 1 || x ||
|-
|pjanik|| || || || || ||
|-
|ssa|| || || || || ||
|-
|maho|| || || || || ||
|-
|tinor|| || || || || ||
|-
|schmidtm|| || || || || ||
|-
|ebischoff|| || || || || ||
|-
|obr|| || || || || ||
|-
|cl|| || || || || ||
|-
|aliscafo|| || || || || ||
|-
|fheckl|| || || || || ||
|-
|Fridrich|| || || || || ||
|-
|plipli|| || x || || || x ||
|-
|}

'''Other resources''':

fonts: ?

events: ?

QA: James McKenzie leads QA for the Mac OS X port of OpenOffice.org and is looking for volunteers to spread this effort over several people and needs people from all over the world to test various languages.

graphical: ?

Communication: ?

'''WHAT''': Status of most important tasks

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
| Task || Names|| Urgency (1=higher)|| Work in Progress || Done || Code review || Debug || Integration ||
|-
|Get rid of X11||done || 1 || x || x || || || ||
|-
|Bundle|| || 1 || x || || || || | ||
|-
|Drawing|| || 1 || x || || || || || ||
|-
|Fonts||plipli || 1 || x || || || || || ||
|-
|Events management|| || 2 || x || || || || || ||
|-
|Controls (see list) ||ericb, aliscafo || 2 || x || || || || || ||
|-
|Native FilePicker||Florian Heckl, Pavel Janik || 3 || x || x || || || || ||
|-
|Native Printing||Yvan Barthelemy || 3 || x || || || || || ||
|-
|Native SpellChecker|| || 4 || || || || || || ||
|-
|Player||Mox Soini || 4 || x || || || || || ||
|}

Other tasks:

Help for writing bug lists, status of bugs ..etc

Write howto use gdb, leaks, other tools

'''WHEN''':

From Christian Lippka (last meeting, 25th of august 2006):
Aug 26 00:21:38 ChristianL
from my point of view what is missing for point 1:
text layout, complete font support, keyboard support,
fixing repaint issues, having aqua install and run out of the box

'''September 2006'''

Present the current state of the project at the 2006 OpenOffice conference in Lyon and Paris

'''Late 2006'''

fix OpenOffice.org launch
fix drawing (repainting)
Implement missing methods and fix most important bugs (mainly the one leading to crash) in:
ATS
Salgraphics
Salinstance

'''January or February 2007'''

make Java work (works partially)
make intensive debug
present something working as alpha

'''June 2007 '''

Implementation of:
native filepicker
native printing

== '''Become a Domain Developer for Mac OS X port''' ==

People regularly contributing to Mac OS x port with regular and quality patches are, after proposal, invited to become a [[DomainDeveloper]].

The purpose of this document is to clearly define all the steps to become a [[DomainDeveloper]].

Preliminary : step 1 in [[Commit_Rights]] must be completed and checked, and you must be in the list of [[http://www.openoffice.org/FAQs/faq-licensing.html#jca1 JCA Licensed people]]

=== Steps for ssh2 key to be uploaded ===

==== Create the key ====

Everything is described here : [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

==== Upload the key ====

You must create an issue, like described below :

Component : www

Sub Component : openoffice.org cvs

Title : CVS Commit access request

Add louis ( Louis Suarez Potts) or st ( Stefan Taxhet ) on CC

Upload your ssh2 public key respecting the process ( Attach a DSA key, not an RSA )

A project lead will confirm your request

Then the support will upload your key

Once done the issue is set to Fixed , and the next step has to be verified before '''you''' close it.

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75291 Upload SSH2 Key for Etsushi Kato]]

==== Verify it works ====

You now can try to connect via tunnel, and follow instructions given [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

If something goes wrong, ask for help to support, with a maximum of details, to solve the problem.

Once it works, the issue can be closed, and you can e.g. test downloading a module from tunnel repository :

First create a tunnel with the command:
<pre>
ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org
</pre>

Then in a new window:

<pre>
export CVSROOT=":pserver:your_login@localhost:/cvs"

cvs login ( enter )

(your password )

mkdir TEST

cd TEST

cvs -z4 co -r SRC680_m205 vcl

cd vcl

cat CVS/Root -> should indicate : your local repository
</pre>

=== Ask for CVS access for all modules required ===

Two steps : create an issue is mandatory because the concerned project is tools, and because people can have only ssh2 key without being [[DomainDeveloper]].

==== Create an issue ====

You must create an issue, described below :

Component : tools

Sub Component : www

Title : CVS access to all modules required

Assigned to mh + CC for ericb and/or pjanik

Present yourself quickly, and ask the access

A project lead will confirm

An admin will confirm this is ok, and set the issue to Fixed

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75494 CVS Access all modules for Etsushi Kato]]

==== Verify ====

Create the tunnel :

open a terminal and type :

ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org

once logged in, open a new terminal, and do ( for example ):
<pre>
cd $OOO_SRC_ROOT/

source MacOSXPPCEnv.Set.sh { source MacOSXX86Env.Set.sh for Mac Intel }

cd vcl ( for example )

IMPORTANT : be sure vcl has been checked from tunnel, not from anoncvs ( cat CVS/Root will give you the answer )

export CWS_WORK_STAMP=aquavcl01 # Only needed for working with [[EIS]], can change for a different CWS ;)

cd aqua/source/gdi

add your changes to your_file.cxx, then commit :

cvs commit -m "#i75689# bla bla ... the reason of the modification(s)" your_file.cxx # The #i75689# is an issue number in the tracker

cvs update

If nothing is wrong, cvs update should not return M for your_file.cxx, means the commit is successfull.
</pre>
In case of problem, use the issue until it is fixed

<big>'''Welcome aboard :)'''</big>

=='''2nd Mac porters meeting'''==

This section has been moved to [[2nd Mac porters meeting]]

=='''IRC Mac port meetings'''==

This section has been moved to [[MacOSXPortMeetings]].

== '''Mac OS X (X11) Quality Assurance'''==

This section has been moved to [[Mac OS X ( X11) Quality Assurance]]

== '''Mac OS X Implementing HIView and Carbon events'''==

This section has been moved to [[Mac OS X Implementing HIView ]]

== '''Debug OpenOffice.org using XCode '''==

[[ MacOSX Debug OpenOffice.org using XCode]]

=='''Description of the Native Port problem'''==

=== How does OpenOffice.org work on Mac OS X? ===

Currently, on Mac OS X, OpenOffice.org uses X11, as "client": X11 is a graphical server, coming from Unix world, and able to run under Linux, *BSD, Solaris, Mac OS X.

- X11 is run as an application, managed like other Apple applications.
- All unix like applications are managed by X11, and from Aqua environment, only X11 is seen as only one applicatiion,
even if other Unix/Linux (e.g.) applications are runing.

OpenOffice.org asks X11 to display a window, waits for X11 acknowledgment, and OpenOffice.org displays the window. All transactions use the network, locally or not. the same mechanism is used for everything to be displayed.

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=== Issues and known problems ===

All events are managed by OpenOffice.org and X11, using the Xlib

Only .ttf fonts type is currently available. Note: '''system fonts are available '''

The rendering is made by X11, not by Mac OS X rendering engine.

X11 and all its clients are seen as one application only: drag and drop protocol does not work because of that (solution: Pasteboard Manager)

==== Other links ====

http://wiki.services.openoffice.org/wiki/List_of_OpenOffice.org_Mac_OS_X_issues_and_problems#

http://wiki.services.openoffice.org/wiki/Printing_problems_with_OpenOffice.org_2.0_for_Mac_OS_X#Reporting_printing_problems

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

== What do we have to do?==

* (in progress) : Implement direct access to Apple graphical engine, using Apple API: Quartz2D/CoreGraphics (and replacing Xlib use)

like: instantiate, manage events and threads for a graphical instance + all needed objects, drawing: manage all drawing cases

* (in progress) : Implement native events management, using CarbonEventManager (replacing Xlib management)

* (in progress) : Implement native font use, using Apple Type Server and ATSUI (for Unicode Imagery) (replacing X11 management)

Work in progress: [[Mac OS X Porting - Native Fonts]]

* Implement native sound, using QuickTime (replacing Java Media Framework): [[Mac OS X Porting - Native Audio and Video]]

* Implement native Drag and drop, Implementing Pasteboard Manager: [[Mac OS X Porting - Native Drag and drop]]

* (done experimental) Implement Native Filepicker

* Implement Native Printing: current uses cups, but native printing is mandatory: [[Mac OS X Porting - Native_Printing]]

* Implement Apple Spellchecker

--[[User:Plipli|Plipli]] 09:27, 25 March 2007 (CEST)

=='''Where is located the code to be modified?'''==

Most of the changes are located in vcl (Visual Class Layer), for everything graphical, events, fonts, rendering and printing.

Other, for sound and movies will be in avmedia (where the player is implemented in OpenOffice.org sources).

For drag and drop, dtrans is concerned (Pasteboard Manager implementation)

[FIXME]: Filepicker? Apple Spellchecker?

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=='''How will the new implementation be tested?==

Currently, all openOffice.org code can be compiled without using the Xlib. but of course, a lot of features are missing,

and the final package simply won't work

In vcl module", a '''toy''' called svdem is built at buildtime. This binary is linked to libvcl* and so all new stuff can be tested.

e.g. : draw anti-aliased lines works well.

Everything implemented in aqua vcl code will be included in libvclplug_aqua, and svdem source code will contain a specific part to proceed tests.

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">

'''The magic is: when all needed features will work with svdem, it will work in the new version of OpenOffice.org !!'''

</div>

[FIXME]: add more complete list of features to implement and test.

== AquaVCL 01 cws ==

[[http://qa.openoffice.org/issues/buglist.cgi?keywords=aqua Top 10 of Aqua issues]]

[[Aquavcl01 tasks]]

===Changelog ===

====Work in progresss : alpha 0.6 ====

Started (19th March ) :

Michael Sicotte proposed to investigate in timers, and continue [[http://www.openoffice.org/issues/show_bug.cgi?id=75228 Pavel's work]] : objective is to replace obsolete code. ( 23th March)

[experimental] plipli proposed a patch for a new salframe implementation, using HIView + optionally compositing (21th March )

[commit scheduled] Michael Sicotte proposed a complete patch for invert() ( SAL_INVERT SAL_INVERT_50 and SAL_INVERT_TRACKFRAME ) (20th March )

Tino proposed to work on code cleanup in salatsuifontutils.cxx, removing obsolete code

ismael and michael work on invert() + drawAlphaRect()

Damien started to work on drawEPS()

plipli and ericb work on refresh

==== alpha 0.5====

Top 10 Summary : 7 issues over 10 are fixed or very close to be :

'''time to code review, tracing, and search for memory leaks'''

[done] Unicode input in salframe ( ekato ) ( 19th March )

[experimental, works partially] beginning of HIView + HIComboxes works (text still missing) (ericb + plipli) ( 14th March )

[done] replace NewRgn() in salframe (ericb (11th March )

[experimental, but very interesting] Improved native windows ( ismael ) ( 7th March )

====alpha 0.4====

'''[Informative]''' build runs with Leopard 9A377a ( fheckl ) ( 7th March )

Refresh screen issues (plipli) (4th to 10th March )

'''[informative]''' plipli announced progress with refresh screen issues ( 28th February )

[experimental, not yet commited] Proxy configuration from system ( pjanik) ( 28th February )

[done] highlighted native button ( pjanik) ( 27th February )

Native File Picker works ( fheckl / pjanik ) ( 23th February )

====alpha 0.3====

Cursor does appear -> invert() + setting a setBlinkTime value in UpdateSettings() (pjanik /ericb )

[done] mirroring negative images (ismael) + DrawAlphaBitmap() + CreateWithMask()

pjanik patch for Focus Events

[done] scrolling works ( pjanik ) (17th February )

[done ] carret works ( plipli) (17th February )

[done] checkbuttons fix for checkmarks (ericb) ( 17th February )

'''[Informative]''' Pavel Janik propose to solve offScreen buffer using HIView ( 17th February )

[experimental, never commited] patch for macosxrc.txt use + UpdateSettings() use in salframe.cxx ( ericb ( 16th February )

Michael Sicotte joined the Team ( 15th February )

invert() : first try (ericb) ( 13th february )

====alpha 0.2====

[12th February 2007 ]

[done] calc does not start : bug identified by tino , first workaround (ericb) [[http://www.openoffice.org/issues/show_bug.cgi?id=73691 issue 73691]]

[done] bitmaps in native popup menus (ismael)

[done] replace obsolete code for HandleWindowPaintEvent(), newRgn() .. etc (ericb) (12th February)

correct salatslayout patch (plipli) ( 11th February)

'''[Informative]''' Michel Renon proposed a summary about his work on fonts issues

[patch] Pavel fixed several menu crashes (09th February )

'''[Informative]''' : Pavel posted a mail about several crashes origin

patch for radioboxes and checkboxes ( ericb ) (9th February)

first complete patch for salatslayout.cxx ( plipli) ( 9th February )

[done] most important crashes fixed ( pjanik) ( 09th february )

Modified baseline for 2.2. : Mac OS X10.4 -> Aqua will be 10.4 and 10.5 compatible only ( ericb)

first try with multi line sallayout (plipli ) ( 08th February )

Damien Duportal joined the Team ( 7th February )

[done] scrollbar changes (ericb ) ( 4th February )

====alpha 0.1====

create Top 10 of issues before alpha 3rd February 2007 : See : [[http://porting.openoffice.org/mac/news/2007/20070203toptenbeforealpha.html Top 10 of issues]]

[experimental, not commited] patch for TPT() implementation (ericb) ( 2nd February 2007 )

Pavel Janik proposed to implement TransformProcessType() ( 2nd February 2007 )

[not commited] implement UpdateSettings() (ericb)

Pavel Janik resynchronized aquavel01 cws with m202 ( 2nd February 2007 )

====alpha 0.03====

Michel Renon joined the Team (1st February )

[done] fix checkbuttons and radiobuttons issues: offsets, redrawing of the check marks ( ericb)

[done] fix scrollbar buttons (implement correct methods to retrieve dimensions)

[done] implement mapfiles for Mac OS X (Stephan Bergmann, Daniel Boelzle, Tino Rachui , Pavel Janik)

====alpha 0.02====

[done] modify libsalsystools.dylib to be correctly loaded with the bundle (ericb, + pjanik)

[done] add mouse drag events ( pjanik )

====alpha 0.01====

[done] add new feature for Aqua windows, to allow QuickTime player use( mox )

[done] replace obsolete code in salframe.cxx with (ericb)

[done] fix correct size for main window (GetOptimaWindowSize() ) (ericb)

[done] fix alpha channel in pixmaps (ismael)

====alpha 0.0====

[done] pushbutton where not correctly drawn (ericb)

[done] fix missing mouse events (pjanik)

[done] fix nRepeat in text entry (ssa)

2nd Mac porters Meeting

===Work in progress ===

URGENT :

Top of issues causing crashes : event issue when tips is enabled causes crashes ( well known window / handler / window desctructor / event loop bug )

Salatsuifontutils : replace old code, track leaks : tino

[done] Bitmaps : ( isma87)

[running] Crashes : (tino, pjanik, ericb, isma87, plipli )

[???] Drag and drop : (vijay)

[???] Printing (ybart)

Florian Heckl proposed a subject for Google Summer of Code about native printing

Drawing/ windowing ( plipli / ericb ) -> mainly refresh

[done] Implement cursor

[started] Native Controls (ericb)

[work in progress] partial multiline sallayout (plipli )

To do :

(started, Oliver) - modify the tree to make the bundle start without hack ( issue fixed during buildtime)

(started, Florian Heckl) verify Native FilePicker implementation ( works , tested in Hamburg )

[done] Ismael Merzaq) implement blit functions in salgdi ( important fix: probably apha version to be tested once done)

[done] Sebastien Plisson- update the missing functions list ( fonts ... ask hdu & cl

[started] ericb, Mox Soini, Sebastien Plisson, Tino Rachui, Pavel janik continue to replace obsolete code

fix crashes with menus (started : tino )

== '''Sort of documentation about VCL around Native Mac OS X port''' ==

Do we really need to understand how it works? ;-)

vcl content:

ls -laR | wc -l
1750

-> Uff 1750 files to analyse :-/

Our purpose is to describe the vcl organisation. The content of vcl is so important, that at the begining, the content will looks a bit confused. e.g. class names ..etc have nothing to do, only description with words and sense, but this will need some time before we can understand everything.

How analyse with more efficiency? After some months to anlalyse '''"horizontaly"''', it appears that list all the content of a directory is not the solution. Of course, we learned a lot, but we now have to complete with '''"orthogonal"''' method (compared to the previous one). The first method wasn't obviously not the good/best way to describe vcl.

[FIXME] a different approach (will ask confirmation to Philipp Lohman), could be a description of how it work in runtime. First define what an instance is, a frame, and what exactly is concerned by such "objects".

With that, we can write a list of different objects all using the same scheme: empty boxes (means pure virtual methods and classes in generic libvvcl), really implemented in the specific part, and finally, the API "encapsulated".

The most difficult is to see where the API is used. But for all the parts, this is the same.

Finally, '''what is important is the design of vcl'''. Which '''patterns''' are used? What are the dependencies, how works the stack for the events, how works the scheduler, the timers too is very important, even fundamental for Aqua implementation. Will have a look at gsl mailing list, and other resources. Probably everything is already (randomly) written somewhere.

=== VCL organisation ===

Thank's to Philipp Lohmann for this short, but precise description:

Basically vcl is divided in the system dependent and the system independent part. The interface between these two is mostly the Sal interface (every interface name Sal*: SalInstance, SalFrame, SalGraphics, SalPrinter, etc.).

SalInstance is a factory that can create all the other abstracted interfaces of the system dependent part. It also provides the main loop SalInstance::Yield()

SalFrame abstracts any kind of system window.

SalVirtualDevice abstracts an offscreen window (e.g. a Pixmap on X11)

SalPrinter and SalInfoPrinter abstract the system print queues where SalInfoPrinter is for querying and SalPrinter for actual printing.

SalGraphics is an interface produced by either SalFrame, SalVirtualDevice or SalPrinter which is used for actual drawing operations (text, bitmaps, vector graphics)

SalSound is for sound playing.

SalBitmap provides memory for bitmap graphics as well as methods converting this memory to a system handle (e.g. a Pixmap on X11).

SalOpenGL provides OpenGL functionality if available.

SalTimer is an interface for periodically triggering the event queue (to timer implementation).

SalI18NImeStatus handles how the status window of an Input Method Editor (IME) should display (this is mainly X11 specific).

SalSystem has some system specific methods that did not belong anywhere else:-)

Of all these there interfaces is at least one implementation per system (Windows, X11 or Mac). The Unix implementation also has a plugin concept to allow for integration of different native toolkits (currently gtk and Qt) which became necessary for the implementation of Native Widget Framework (NWF) to display controls like their normal desktop counterparts.

Basically the independent part (what is beneath vcl/source directory) has generic methods for drawing, window handling and stuff which it brings into a suitable form and then delegates to the system specific implementation (located beneath vcl/win for Windows and vcl/unx for the X11 platforms).

[[User:Ericb|Ericb]] 16:12, 1 July 2006 (CEST)

===Sub-directories description ===

==== '''Organisation of vcl directories''' ====

[[Image:aquavcl_organisation_complete_02.jpg]]

==== '''Directories in vcl. Short description''' ====

''' aqua ''': The name Aqua means Apple look and feel, and is well known as [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html Aqua Human Interface Guidelines]. This look and feel means Mac OS X. The work was begun by (probably) P. luby, Dan Williams Herbert Duerr (most of fonts stuff) and Ed Peterlin. Currently in ruin, this directory does contain a lot of ideas to investigate. The most important part of needed changes for native version (3.0) will be done inside aqua dir inc: does contain all vcl relative includes [PART1]

''' prj ''': Does contain build.lst and d.lst build.lst give us dependencies: probably a lot for vcl, build 98th module over ~148. Everything graphical depends in vcl.

''' qa ''' does contain all quality assurancy stuff

'''source''': the most important:-) This directory contains common sources for all architectures and OS. Mainly: Windows, Unix: Linux , Mac OS X (X11), Solaris, including generic, kde and gtk plugins, and Aqua (Mac OS X without X11, work currently in progress).

Depending on the OS and the architecture, binaries are built or not.

''' test ''': This directory does contain all the needed stuff for tests. As example, in qa/testdocuments, you'll find three documents (one writer, one calc and one impress) for tests purpose.
Other available tests are about memcheck and persistent window state.

''' unx ''': this directory does contain all unixes stuff. We have to understand what is inside to implement aqua port. For example, a lot of classes/strutures and objects use Xlib calls we have to replace with Carbon/Cocoa call (at least at first time) for Mac OS X native port.

''' win ''': Doing Mac OS X native port, I first believed this directory was not interesting for us, but I was wrong: OpenOffice.org roots are inside this directory, and a lot of comments and resources are inside. Mainly interesting if Carbon is used.

'''workben''': Does contain a toy called "svdem". svdem is a binary, used for new implementations. For example, actual aqua development uses svdem intensively, to verify all important properties we need:

- display a window first (al least ...:))

- close cleanly this window

- display a point

- trace a line

- trace an area

- superpose two areas doing some important graphical operations, (like xor),

- display a character

- display a menu.

- intercept events correctly.

[FIXME] add more tests

[[User:Ericb|Ericb]] 13:21, 3 June 2006 (CEST)

=='''Naming convention''' ==

* Class names start with upper case letters, to improve readability.

* Implemented Class names are derived from the virtual classes but can of course take arbitrary names.
To increase readability, it's recommended to closely follow the base class name.

* '''Impl prefix: means Implementation details'''. The concerned class or method or function is not used outside of this module, so no external code (or other libraries) can see it.

'''[[ Events types using Carbon API (Mac OS X): ]]''' A lot of events have to be managed in runtime. Here is a short description

- do not freeze because bad event loops

- event types implementation: currently, they are defined in vcl/aqua/inc/aquavclevents.hxx

Apart: exact sense of hedabu? -> [FIXME] as far as I understood it: it is like "copy" to deliver software into the solver, with extra magic. The header files for example are manipulated so paths need not be exact. "headabu" is supposed to disappear little by little.

== '''What do we have to build in vcl?'''==

Two libraries, corresponding ressources (localized) and a toy so called « svdem »

'''Common part''':

in grey on right. The result will be a non architecture dependant library, built in all cases: for instance, libvcl680mxi.dylib on Mac Intel.

'''Specific part " a plugin " ''':

Light yellow: aqua part will only concern Mac OS X (non X11) the name will probably be libvcl_aqua680mxi.dylib

As you can see, win means windows part, in blue

For Unix build (Linux, Solaris or current Mac OS X X11), in purple.

Result will be:

libvclplug_PLUGIN680mxi.DLLSUFFIX , where PLUGIN can be iether gen (generic) or gtk (using gtk+) or kde (using qt), and DLLSUFFIX can be either .so (linux) or .dylib (Mac OS X) ...etc (I'm not sure for other cases).

Example: libvcl680mxi.dylib and libvclplug_aqua680mxi.dylib

'''In runtime''', libvclplug_aqua will be linked to libvcl680. the first one will contain the real implementation (respecting the API, e.g. Carbon) while the generic libvcl will only contain pure virtual methods ...etc like "empty boxes".

=== Current Aqua content ===

A more complete description of aqua (Mac OS X / no X11 specific): [[Image:Vcl_aqua_organisation_02_tree.jpg]]

==EXISTING objects to build in aqua==

===Sal APP "everything application"===

[FIXME] add all objects descriptions

==== saldata ====

* '''Defined in plugin exclusively''' (i.e. for headers)

Unix: unx/source/app/saldata.cxx (header in unx/inc)

'''Aqua: aqua/source/app/saldata.cxx (header in win/inc)'''

Windows: win/source/app/saldata.cxx (header in aqua/inc)

* Role: saldata contains various kind of data used by the implementation for the concerned platform. '''It is a bunch of global data collections reserved for the platform'''

It is just completely platform dependent, and nobody except this plugin can see it.

'''Saldata is something like a "second sal", but providing an abstraction regarding windowing and graphics''', while SAL module provides an abstraction more Operating System oriented)

e.g. : have a look at XRequest array in vcl/unx/source/app/saldata.cxx => all calls are for Xlib (X11). Ok, useless there, but interesting:-)

[FIXME]: use Windows implementation could be a good starting point. Nothing is the same, but the current aquavcl cws uses similar objects, and it works very correctly.

saldatax.cxx uses classes SalInstance, SalObject, SalFrame, SalVirtualDevice, SalPrinter and fontList.

Current list of possible objects who can be instantiated/released:

structure SalData: does contain pointers on all kind of objects from other classes used in saldata.

inline functions: [FIXME]: complete the description

- SetSalData:
- GetSalData:
- GetAppSalData:

==== salinst ====

=> implemented in vcl/aqua/source/app/salinst.cxx

Role:

* get environment, mutexes, instantiate AquaSalInstance (Ctor, Dtor),

* instantiates/releases a lot of other objects using Get() / CreateObject() / DestroyObject() methods.

Current list of possible objects who can be instantiated/released:

* VirtualDevice [FIXME]: exact role?

*Printer

- GetDefaultPrinter/ CreatePrinter() / DestroyPrinter - what a name ;-) -

- InfoPrinter (Get/Create/Delete)

- PrinterQueue (DeletePrinterQueueInfo / GetPrinterQueueInfo / GetPrinterQueueState)

* System (Create / Delete) [FIXME]: what means system here?

* Events:

AquaSalInstance::SetEventCallback()

AquaSalInstance::SetErrorEvenCallback()

AquaSalInstance::GetConnectionIdentifier()

* Menu / MenuItem:

AquaSalInstance::CreateMenu() / same for DestroyMenu()

AquaSalInstance::CreateMenuItem / same DestroyMenuItem()

* Sound:

AquaSalInstance::CreateSalSound() => object to a pointer of SalSound type

Note: AquaSalInstance::DestroySalSound is not implemented (?)

* Timer: CreateTimer() /

AquaSalInstance:: DestroyTimer() is not yet implemented (?)

Class MacImeStatus: inherits of SalI18NImeStatus

-> only there to see if there is a window to toggle into menubar [FIXME]??

AquaSalInstance::CreateI18NImeStatus(): instantiates MacImeStatus

'''For futher informations, see: ''' '''[[Content of salinst.cxx]]'''

([[User:Ericb|Ericb]] 16:11, 20 May 2006 (CEST) )

==== salmain ====

Role: if possible, runs the standard vcl application code SVMain()

([[User:Ericb|Ericb]] 16:15, 20 May 2006 (CEST))

==== salsound ====

==== salsys ====

==== saltimer ====

=== Sal GDI (everything Graphical Display Interface) ===

====salgdinativewidgets====

[[native controls]]

==== salatslayout ====

==> implemented in vcl/aqua/source/gdi/salatslayout.cxx

- Handle text layouting :

* Use ATSUI (ATSUCreateTextLayoutFromPtr) to layout the text unicode char buffer
* Use ATSUI (ATSU..) to get informations about glyphs
* Populate different arrays (mpGlyph2Chars, mpChars2Glyph, mpCharsWidths, mpGlyphAdvances)
that are used in various methods.

==== salatsuiutils ====

==== salfontutils ====

==== salmathutils ====

==== sal bmp ====

==== salvd ====

==== salpixmaputils====

==== salprn ====

====salrectangle====

==== salvd ====

=== Sal Window===

==== salframe ====
Documentation in progress, from damiend :
[[User:Damiend|Damiend page]]

====salobj====

== TO BE IMPLEMENTED (missing in Aqua)==

===Audio===

====audioconvert====
(obsolete?)

====devaudio====
(obsolete?)

====native sound====

====salimpsound====

====vsound====

===i18n===

===keysymnames===

===saldisp===

===sm===

[FIXME]: is session manager usefull?

=='''Native Controls'''==

====Scrollbar====

'''Works as expected'''. The most important work is done

See : [[Mac_OS_X_Porting_-_Native_Controls#ScrollBar]]

====DrawThemeButton() documentation====

'''Started'''

See : [[Mac_OS_X_Porting_-_Native_Controls#ComboBox]]

Started
<pre>
DrawThemeButton
Draws a button.

OSStatus DrawThemeButton (
const Rect * inBounds,
ThemeButtonKind inKind,
const ThemeButtonDrawInfo * inNewInfo,
const ThemeButtonDrawInfo * inPrevInfo,
ThemeEraseUPP inEraseProc,
ThemeButtonDrawUPP inLabelProc,
UInt32 inUserData
);
Parameters
inBounds
A pointer to a structure of type Rect. Pass a rectangle specifying the boundary of the button, in local coordinates.

inKind
A value of type ThemeButtonKind. Pass a constant specifying the type of button to draw.
See “Theme Buttons” for descriptions of possible values.

inNewInfo
A pointer to a structure of type ThemeButtonDrawInfo. Before calling DrawThemeButton,
set the structure to contain the new state, value, and adornment for the button.
DrawThemeButton uses the information passed in the inNewInfo and inPrevInfo parameters
to apply transitional animation or sound effects as the button state changes, if such are
specified under the current theme.

inPrevInfo
A pointer to a structure of type ThemeButtonDrawInfo. If the button state is changing,
set the structure to contain the previous state, value, and adornment for the button,
to allow DrawThemeButton to apply any transitional effects. If the button state is not
changing, you can pass NULL.

inEraseProc
A value of type ThemeEraseUPP. If you have a custom background, use this parameter to pass
a universal function pointer to an application-defined function such as that described in
ThemeEraseProcPtr. DrawThemeButton calls this function to erase the background before drawing
the button. If you pass NULL, DrawThemeButton's default behavior is to erase the background
for you.

inLabelProc
A value of type ThemeButtonDrawUPP. If you pass a universal function pointer to an
application-defined function such as that described in ThemeButtonDrawProcPtr, DrawThemeButton
calls that function to draw the label of the button. If you pass NULL, no label is drawn.

inUserData
An unsigned 32-bit integer. Provide any data to be passed in to the callback functions specified in
the inLabelProc and inEraseProc parameters. Pass NULL if you do not wish to provide any data.

Return Value
A result code. See “Appearance Manager Result Codes”.

Discussion
The DrawThemeButton function draws a theme-compliant button. If a ThemeEraseProcPtr is
specified in the inEraseProc parameter, DrawThemeButton uses that function to erase the
background of the button before drawing the button. After the button is drawn, if a
ThemeButtonDrawProcPtr is specified in the inLabelProc parameter, DrawThemeButton calls
that function to draw the button’s label.

Note that DrawThemeButton also draws any appearance adornments for the button and that these
can extend beyond the button’s basic bounding rectangle, as specified in the inBounds parameter,
and may be of variable shape. You may therefore wish to call the function
GetThemeButtonBackgroundBounds to obtain the actual rectangle containing the pixels belonging
to a button under the current theme.

Version Notes
This function is available with Appearance Manager 1.1 and later.

Availability
Available in CarbonLib 1.0 and later when Appearance 1.1 or later is present.
Available in Mac OS X 10.0 and later.
Declared In
Appearance.h
</pre>

====HIComboBoxCreate() documentation====

<pre>
HIComboBoxCreate
Creates a combo box control.

OSStatus HIComboBoxCreate (
const HIRect* boundsRect,
CFStringRef text,
const ControlFontStyleRec* style,
CFArrayRef list,
OptionBits inAttributes,
HIViewRef* outComboBox
);
Parameters
boundsRect
The bounding box of the control.

text
The default text in the editable portion of the control. Can be NULL.

style
The font style of the both editable text and the text in the disclosure list. Can be NULL.

list
The default values available in the disclosure list. Can be NULL.

inAttributes
The default attributes of the combo box. For possible values, see “Combo Box Attributes”.

outComboBox
On exit, a pointer to a reference for the new control.

Discussion
The combo box can be used in compositing mode, as well as traditional Control Manager mode.
When created, this view is invisible. To see the view, you must show the view by calling HIViewSetVisible.
</pre>

== What is used for Linux, Windows, Mac OS X ...build ? ==

'''[[Description of the dependencies]]'''

'''[[Windows]]'''

'''[[MacOS X]]'''

'''[[Linux]]'''

'''[[Solaris]]'''

== Content of Aqua ==

'''[[Click here to see the complete list]]'''

'''Content of vcl/inc'''

Notes:

1) Where to find includes

<foo/bar.hxx> means you can find bar.hxx in the foo module. The new style file is foo/inc/foo/bar.hxx, old style is foo/inc/bar.hxx and sometimes the file is somewhere else in the tree or generated. The deliver process copies/generates the file into solver at solver/680/build_type/inc/foo. Good for fixing broken builds. ;-)

2)
suffix .h (for C calls or first version?) or .hxx (C++)

'''A) Family of includes''':

Looking more closely at the list brings to the fore (expression from dictionary ;-) ) that include names are
informatives. Most of the time, the name gives the function/role.
What is interesting is the files with name begining with "sal". sal means System Abstraction Layer + include's function (or explicit name).

Partial list, for example:

salatype.hxx

salbmp.hxx

salctrlhandle.hxx

salctype.hxx

salframe.hxx

salgdi.hxx

salgeom.hxx

sallayout.hxx (main header for fonts services)
...
salmenu
salnativewidgets
...etc

Other important families are "sv" and "uno" or "win" (window) prefixed. sal family will be analysed apart.

'''B) Includes of includes'''

Some includes are more important than other. To prove this, just have a look is sufficient: some are always needed, and some more rarely.

To verify, a simple test to do in vcl/inc:

egrep -H "#include" ./* | wc -l gives me 681 lines ! And some of them are the same...

To know more, the precedent command line can be modified to make appear the numerous call
to the same includes files.

egrep -H "#include" ./* | cut -d"#" -f2 | sort > liste.txt

The content of liste.txt is explicit: dllapi.h, sv.h and some other are very important, while some other includes are only one or two times used. We can see too that vos includes are numerous, even if vos is deprecated**

**see http://wiki.services.openoffice.org/wiki/Source_code_directories

I'm nearly sure that a complete analysis of just this result will give us a lot of information.

I propose to change the order of analysis starting with dllapi.h and sv.h.

[to be continued]

'''B1) "sal" includes family'''

[[salinst.hxx]] This seems to be the main include file

[[salatype.hxx]]

[[salctrlhandle.hxx]]

[[salctype.hxx]]

[[salframe.hxx]]

[[salgdi.hxx]]

[[salgeom.hxx]]

'''[[ sallayout.hxx ]]''' <-- see Native Fonts implementation

[[salgtype.hxx]]

[[vcl/inc/salobj.hxx]]

'''B2) Classicals includes'''

file: abstdlg.hxx [ means abstract dialog ]

This includes does contain the following classes definitions:

[FIXME] : choose a precise presentation template for classes

VclAbstractDialog,

VclAbstractTerminateDialog,

VclAbstractRefreshableDialog,

VclAbstractDialogFactory,

uses <tools/solar.h> , <tools/string.hxx> +

"dllapi.h"

Note : dllapi.h is very interesting because when we have to find (for example) a library suffix, SAL_DLLEXTENSSION can replace all suffixes (every OS's and archs). Just including sal/config.h does it !

Classes:

Window -> what? [FIXME]
ResId -> what?

Does contain the prototype of VclAbstractDialog, inherit of VCL_DLLPUBLIC

file: dllapi.h [ dll for dynamic linked library ]
Uses: <sal/config.h> and >sal/types/h>
includes: VCL_DLLPUBLIC macro

file: accel.h [ means accelerator ]

Classes:

Accelerator
{
}
ImplAccelEntry
{
public members:

Names

mnId
maKeyCode
mpAccel
mpAutoAccel
mbEnabled
}

function / returns / parameters

ImplGetKeyCode / void / KeyFuncType eFunc, ref rCode1 , ref rCode2, ref rCode3

file: accel.hxx

Uses: <sv.h> , "dllapi.h" ,<tools/resid.hxx>, <<tools/rc.hxx>

Classes:

ImplAccelData;
ImplAccelEntry;

== Important Links ==
'''[[Progressive implementation]]'''

'''Native Font server Implementation''' '''[[Mac OS X Porting - Native Fonts]]'''

'''Native Sound Implementation''': [[Mac OS X Porting - Native Audio and Video]]

'''Native Printing Implementation''': [[Mac OS X Porting - Native_Printing]]

'''Drag and Drop implementation''': [[Mac OS X Porting - Native Drag and drop]]

'''Data Acquisition''' : [[Mac OS X Porting - Data Acquisition]]

This work is part of http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s

[to be continued:-) ]

== Keyboard comparizon between OpenOffice.org / Mac OS X application ==

[FIXME] redo a cleanest array

{| style="vertical-align:top; text-align:centered; background-color:#F0F0F0;"
|- style="background-color:#99CCFF; font-weight:bold;"
| Modifier||+ key || Result || TextEdit returns
|-
|ALT|| a||æ ||æ
|-
|ALT||b||ß ||ß
|-
|ALT||c||© ||©
|-
|ALT||d||∂ ||∂
|-
|ALT||e||ê ||ê
|-
|ALT||f||ƒ ||ƒ
|-
|ALT||g ||ﬁ ||ﬁ
|-
|ALT||h ||Ì ||Ì
|-
|ALT||i ||î ||î
|-
|ALT||j ||Ï ||Ï
|-
|ALT||k ||È ||È
|-
|ALT||l ||¬ ||¬
|-
|ALT||m ||µ ||µ
|-
|ALT||n ||~ ||~
|-
|ALT||o ||œ ||œ
|-
|ALT||p ||π ||π
|-
|ALT||q ||‡ ||‡
|-
|ALT||r ||® ||®
|-
|ALT||s ||Ò ||Ò
|-
|ALT||t ||† ||†
|-
|ALT||u ||º ||º
|-
|ALT||v ||◊ ||◊
|-
|ALT||w ||‹ ||‹
|-
|ALT||x ||≈ ||≈
|-
|ALT||y ||Ú ||Ú
|-
|ALT||z ||Â ||Â
|-
|ALT||A ||Æ ||Æ
|-
|ALT||B ||∫ ||∫
|-
|ALT||C ||¢ ||¢
|-
|ALT||D||∆||∆
|-
|ALT||F ||· ||·
|-
|ALT||G ||ﬂ ||ﬂ
|-
|ALT||H ||Î ||Î
|-
|ALT||I ||Î ||Î
|-
|ALT||J ||Í ||Í
|-
|ALT||K ||Ë ||Ë
|-
|ALT||L || <pre>|</pre> ||<pre>|</pre>
|-
|ALT||M ||Ó ||Ó
|-
|ALT||N ||ı ||ı
|-
|ALT||O ||Œ ||Œ
|-
|ALT||P ||∏ ||∏
|-
|ALT||Q ||Ω ||Ω
|-
|ALT||R ||‚ ||‚
|-
|ALT||S ||∑ ||∑
|-
|ALT||T ||™ ||™
|-
|ALT||U ||ª ||ª
|-
|ALT||V ||√ ||√
|-
|ALT||W ||› ||›
|-
|ALT||X ||⁄ ||⁄
|-
|ALT||Y ||Ÿ ||Ÿ
|-
|ALT||Z ||Å ||Å
|-
|ALT||$ ||€ ||€
|-
|ALT||` ||@ ||@
|-
|ALT||£ ||# ||#
|-
|ALT||* ||¥ ||¥
|}

Sous réserve d'erreur ou omission [[User:Ericb|Ericb]] 00:05, 14 January 2007 (CET)

--[[User:Ericb|Ericb]] 15:00, 22 Jul 2005 (EDT)

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

User:Ericb

2007-03-25T07:27:40Z

Plipli: /* What do we have to do? */

==Public Documentation License Notice==

The contents of this Documentation (excepted Native Port Roadmap),are subject to the Public Documentation License Version 1.0 (the "License"); you may only use this Documentation if you comply with the terms of this License. A copy of the License is available at http://www.openoffice.org/licenses/PDL.html.
The Original Documentation is "Mac OS X native port". The Initial Writer of the Original Documentation is (JCA) Eric Bachard (C) 2005-2006. All Rights Reserved. (Initial Writer contact(s): ericb@openoffice.org.)

=='''Mac OS X Native port'''==

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">
'''The first Mac OS X native port objective is make OpenOffice.org run without X11 use, to make it a real Mac application.'''

'''The second one is respect Aqua Human interface Guidelines'''

''' This is a long term work, and every help and/or contributions, like donations** are welcome.'''
</div>

**see http://contributing.openoffice.org/index.html

=='''Native Port Roadmap'''==

==='''2006'''===

* June 2006: work in progress

- Basis: frame, instances, threads, drawing, painting, resizing (Stephan Schaefer, Tino Rachui)

Done:
implement threads
create, manage instance
create, manage windows (including parents)
create, manage events
create manage drawing, resizing
create, add menus (Pavel Janik)
toggle window fullscreen (Pierre de Filippis)
make font server work (Stephan Schaefer)

* Current status font support (Stephan Schaefer, 2006/07/28): the following features are basically working now
** font selection
** font size
** simple font attributes (bold, italic)

Next step: document first part, and propose design

- native filepicker (Pavel Janik, Florian Heckl)

- native printing implementation (Oliver?)

- native font implementation (Eric Bachard)

* September 2006:

- first proofs of concept: fonts, filepicker .. (more?)
- show the results (OOoCon 2006?)

==='''2007'''===

* January 2007: first alpha implementation

=='''Strategy for native port'''==

'''Possible Actions''':

Identify us:

#Complete the arrays below
#Update photos on frapr.com?

Share the work:

#Divide the work between little Teams
#Update Todo list regularly -> needs some love these days ... [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s]

Help:

#Teach tools between us
#Do a debug party on IRC
#write documentation

Meet us:

#IRC
#Mac Meeting (like nov2005 in Hamburg?)

Inform:

#Update website regularly
#Blogs

'''WHO''':

Mac Team:

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
|Developer \ skills || build || write code || code review || debug/trace (higher is better) || contribute to documentation ||
|-
|ericb|| x || x || || 1 || x ||
|-
|pjanik|| || || || || ||
|-
|ssa|| || || || || ||
|-
|maho|| || || || || ||
|-
|tinor|| || || || || ||
|-
|schmidtm|| || || || || ||
|-
|ebischoff|| || || || || ||
|-
|obr|| || || || || ||
|-
|cl|| || || || || ||
|-
|aliscafo|| || || || || ||
|-
|fheckl|| || || || || ||
|-
|Fridrich|| || || || || ||
|-
|plipli|| || x || || || x ||
|-
|}

'''Other resources''':

fonts: ?

events: ?

QA: James McKenzie leads QA for the Mac OS X port of OpenOffice.org and is looking for volunteers to spread this effort over several people and needs people from all over the world to test various languages.

graphical: ?

Communication: ?

'''WHAT''': Status of most important tasks

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
| Task || Names|| Urgency (1=higher)|| Work in Progress || Done || Code review || Debug || Integration ||
|-
|Get rid of X11||done || 1 || x || x || || || ||
|-
|Bundle|| || 1 || x || || || || | ||
|-
|Drawing|| || 1 || x || || || || || ||
|-
|Fonts||plipli || 1 || x || || || || || ||
|-
|Events management|| || 2 || x || || || || || ||
|-
|Controls (see list) ||ericb, aliscafo || 2 || x || || || || || ||
|-
|Native FilePicker||Florian Heckl, Pavel Janik || 3 || x || x || || || || ||
|-
|Native Printing||Yvan Barthelemy || 3 || x || || || || || ||
|-
|Native SpellChecker|| || 4 || || || || || || ||
|-
|Player||Mox Soini || 4 || x || || || || || ||
|}

Other tasks:

Help for writing bug lists, status of bugs ..etc

Write howto use gdb, leaks, other tools

'''WHEN''':

From Christian Lippka (last meeting, 25th of august 2006):
Aug 26 00:21:38 ChristianL
from my point of view what is missing for point 1:
text layout, complete font support, keyboard support,
fixing repaint issues, having aqua install and run out of the box

'''September 2006'''

Present the current state of the project at the 2006 OpenOffice conference in Lyon and Paris

'''Late 2006'''

fix OpenOffice.org launch
fix drawing (repainting)
Implement missing methods and fix most important bugs (mainly the one leading to crash) in:
ATS
Salgraphics
Salinstance

'''January or February 2007'''

make Java work (works partially)
make intensive debug
present something working as alpha

'''June 2007 '''

Implementation of:
native filepicker
native printing

== '''Become a Domain Developer for Mac OS X port''' ==

People regularly contributing to Mac OS x port with regular and quality patches are, after proposal, invited to become a [[DomainDeveloper]].

The purpose of this document is to clearly define all the steps to become a [[DomainDeveloper]].

Preliminary : step 1 in [[Commit_Rights]] must be completed and checked, and you must be in the list of [[http://www.openoffice.org/FAQs/faq-licensing.html#jca1 JCA Licensed people]]

=== Steps for ssh2 key to be uploaded ===

==== Create the key ====

Everything is described here : [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

==== Upload the key ====

You must create an issue, like described below :

Component : www

Sub Component : openoffice.org cvs

Title : CVS Commit access request

Add louis ( Louis Suarez Potts) or st ( Stefan Taxhet ) on CC

Upload your ssh2 public key respecting the process ( Attach a DSA key, not an RSA )

A project lead will confirm your request

Then the support will upload your key

Once done the issue is set to Fixed , and the next step has to be verified before '''you''' close it.

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75291 Upload SSH2 Key for Etsushi Kato]]

==== Verify it works ====

You now can try to connect via tunnel, and follow instructions given [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

If something goes wrong, ask for help to support, with a maximum of details, to solve the problem.

Once it works, the issue can be closed, and you can e.g. test downloading a module from tunnel repository :

First create a tunnel with the command:
<pre>
ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org
</pre>

Then in a new window:

<pre>
export CVSROOT=":pserver:your_login@localhost:/cvs"

cvs login ( enter )

(your password )

mkdir TEST

cd TEST

cvs -z4 co -r SRC680_m205 vcl

cd vcl

cat CVS/Root -> should indicate : your local repository
</pre>

=== Ask for CVS access for all modules required ===

Two steps : create an issue is mandatory because the concerned project is tools, and because people can have only ssh2 key without being [[DomainDeveloper]].

==== Create an issue ====

You must create an issue, described below :

Component : tools

Sub Component : www

Title : CVS access to all modules required

Assigned to mh + CC for ericb and/or pjanik

Present yourself quickly, and ask the access

A project lead will confirm

An admin will confirm this is ok, and set the issue to Fixed

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75494 CVS Access all modules for Etsushi Kato]]

==== Verify ====

Create the tunnel :

open a terminal and type :

ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org

once logged in, open a new terminal, and do ( for example ):
<pre>
cd $OOO_SRC_ROOT/

source MacOSXPPCEnv.Set.sh { source MacOSXX86Env.Set.sh for Mac Intel }

cd vcl ( for example )

IMPORTANT : be sure vcl has been checked from tunnel, not from anoncvs ( cat CVS/Root will give you the answer )

export CWS_WORK_STAMP=aquavcl01 # Only needed for working with [[EIS]], can change for a different CWS ;)

cd aqua/source/gdi

add your changes to your_file.cxx, then commit :

cvs commit -m "#i75689# bla bla ... the reason of the modification(s)" your_file.cxx # The #i75689# is an issue number in the tracker

cvs update

If nothing is wrong, cvs update should not return M for your_file.cxx, means the commit is successfull.
</pre>
In case of problem, use the issue until it is fixed

<big>'''Welcome aboard :)'''</big>

=='''2nd Mac porters meeting'''==

This section has been moved to [[2nd Mac porters meeting]]

=='''IRC Mac port meetings'''==

This section has been moved to [[MacOSXPortMeetings]].

== '''Mac OS X (X11) Quality Assurance'''==

This section has been moved to [[Mac OS X ( X11) Quality Assurance]]

== '''Mac OS X Implementing HIView'''==

This section has been moved to [[Mac OS X Implementing HIView ]]

== '''Debug OpenOffice.org using XCode '''==

[[ MacOSX Debug OpenOffice.org using XCode]]

=='''Description of the Native Port problem'''==

=== How does OpenOffice.org work on Mac OS X? ===

Currently, on Mac OS X, OpenOffice.org uses X11, as "client": X11 is a graphical server, coming from Unix world, and able to run under Linux, *BSD, Solaris, Mac OS X.

- X11 is run as an application, managed like other Apple applications.
- All unix like applications are managed by X11, and from Aqua environment, only X11 is seen as only one applicatiion,
even if other Unix/Linux (e.g.) applications are runing.

OpenOffice.org asks X11 to display a window, waits for X11 acknowledgment, and OpenOffice.org displays the window. All transactions use the network, locally or not. the same mechanism is used for everything to be displayed.

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=== Issues and known problems ===

All events are managed by OpenOffice.org and X11, using the Xlib

Only .ttf fonts type is currently available. Note: '''system fonts are available '''

The rendering is made by X11, not by Mac OS X rendering engine.

X11 and all its clients are seen as one application only: drag and drop protocol does not work because of that (solution: Pasteboard Manager)

==== Other links ====

http://wiki.services.openoffice.org/wiki/List_of_OpenOffice.org_Mac_OS_X_issues_and_problems#

http://wiki.services.openoffice.org/wiki/Printing_problems_with_OpenOffice.org_2.0_for_Mac_OS_X#Reporting_printing_problems

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

== What do we have to do?==

* (in progress) : Implement direct access to Apple graphical engine, using Apple API: Quartz2D/CoreGraphics (and replacing Xlib use)

like: instantiate, manage events and threads for a graphical instance + all needed objects, drawing: manage all drawing cases

* (in progress) : Implement native events management, using CarbonEventManager (replacing Xlib management)

* (in progress) : Implement native font use, using Apple Type Server and ATSUI (for Unicode Imagery) (replacing X11 management)

Work in progress: [[Mac OS X Porting - Native Fonts]]

* Implement native sound, using QuickTime (replacing Java Media Framework): [[Mac OS X Porting - Native Audio and Video]]

* Implement native Drag and drop, Implementing Pasteboard Manager: [[Mac OS X Porting - Native Drag and drop]]

* (done experimental) Implement Native Filepicker

* Implement Native Printing: current uses cups, but native printing is mandatory: [[Mac OS X Porting - Native_Printing]]

* Implement Apple Spellchecker

--[[User:Plipli|Plipli]] 09:27, 25 March 2007 (CEST)

=='''Where is located the code to be modified?'''==

Most of the changes are located in vcl (Visual Class Layer), for everything graphical, events, fonts, rendering and printing.

Other, for sound and movies will be in avmedia (where the player is implemented in OpenOffice.org sources).

For drag and drop, dtrans is concerned (Pasteboard Manager implementation)

[FIXME]: Filepicker? Apple Spellchecker?

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=='''How will the new implementation be tested?==

Currently, all openOffice.org code can be compiled without using the Xlib. but of course, a lot of features are missing,

and the final package simply won't work

In vcl module", a '''toy''' called svdem is built at buildtime. This binary is linked to libvcl* and so all new stuff can be tested.

e.g. : draw anti-aliased lines works well.

Everything implemented in aqua vcl code will be included in libvclplug_aqua, and svdem source code will contain a specific part to proceed tests.

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">

'''The magic is: when all needed features will work with svdem, it will work in the new version of OpenOffice.org !!'''

</div>

[FIXME]: add more complete list of features to implement and test.

== AquaVCL 01 cws ==

[[http://qa.openoffice.org/issues/buglist.cgi?keywords=aqua Top 10 of Aqua issues]]

[[Aquavcl01 tasks]]

===Changelog ===

====Work in progresss : alpha 0.6 ====

Started (19th March ) :

Michael Sicotte proposed to investigate in timers, and continue [[http://www.openoffice.org/issues/show_bug.cgi?id=75228 Pavel's work]] : objective is to replace obsolete code. ( 23th March)

[experimental] plipli proposed a patch for a new salframe implementation, using HIView + optionally compositing (21th March )

[commit scheduled] Michael Sicotte proposed a complete patch for invert() ( SAL_INVERT SAL_INVERT_50 and SAL_INVERT_TRACKFRAME ) (20th March )

Tino proposed to work on code cleanup in salatsuifontutils.cxx, removing obsolete code

ismael and michael work on invert() + drawAlphaRect()

Damien started to work on drawEPS()

plipli and ericb work on refresh

==== alpha 0.5====

Top 10 Summary : 7 issues over 10 are fixed or very close to be :

'''time to code review, tracing, and search for memory leaks'''

[done] Unicode input in salframe ( ekato ) ( 19th March )

[experimental, works partially] beginning of HIView + HIComboxes works (text still missing) (ericb + plipli) ( 14th March )

[done] replace NewRgn() in salframe (ericb (11th March )

[experimental, but very interesting] Improved native windows ( ismael ) ( 7th March )

====alpha 0.4====

'''[Informative]''' build runs with Leopard 9A377a ( fheckl ) ( 7th March )

Refresh screen issues (plipli) (4th to 10th March )

'''[informative]''' plipli announced progress with refresh screen issues ( 28th February )

[experimental, not yet commited] Proxy configuration from system ( pjanik) ( 28th February )

[done] highlighted native button ( pjanik) ( 27th February )

Native File Picker works ( fheckl / pjanik ) ( 23th February )

====alpha 0.3====

Cursor does appear -> invert() + setting a setBlinkTime value in UpdateSettings() (pjanik /ericb )

[done] mirroring negative images (ismael) + DrawAlphaBitmap() + CreateWithMask()

pjanik patch for Focus Events

[done] scrolling works ( pjanik ) (17th February )

[done ] carret works ( plipli) (17th February )

[done] checkbuttons fix for checkmarks (ericb) ( 17th February )

'''[Informative]''' Pavel Janik propose to solve offScreen buffer using HIView ( 17th February )

[experimental, never commited] patch for macosxrc.txt use + UpdateSettings() use in salframe.cxx ( ericb ( 16th February )

Michael Sicotte joined the Team ( 15th February )

invert() : first try (ericb) ( 13th february )

====alpha 0.2====

[12th February 2007 ]

[done] calc does not start : bug identified by tino , first workaround (ericb) [[http://www.openoffice.org/issues/show_bug.cgi?id=73691 issue 73691]]

[done] bitmaps in native popup menus (ismael)

[done] replace obsolete code for HandleWindowPaintEvent(), newRgn() .. etc (ericb) (12th February)

correct salatslayout patch (plipli) ( 11th February)

'''[Informative]''' Michel Renon proposed a summary about his work on fonts issues

[patch] Pavel fixed several menu crashes (09th February )

'''[Informative]''' : Pavel posted a mail about several crashes origin

patch for radioboxes and checkboxes ( ericb ) (9th February)

first complete patch for salatslayout.cxx ( plipli) ( 9th February )

[done] most important crashes fixed ( pjanik) ( 09th february )

Modified baseline for 2.2. : Mac OS X10.4 -> Aqua will be 10.4 and 10.5 compatible only ( ericb)

first try with multi line sallayout (plipli ) ( 08th February )

Damien Duportal joined the Team ( 7th February )

[done] scrollbar changes (ericb ) ( 4th February )

====alpha 0.1====

create Top 10 of issues before alpha 3rd February 2007 : See : [[http://porting.openoffice.org/mac/news/2007/20070203toptenbeforealpha.html Top 10 of issues]]

[experimental, not commited] patch for TPT() implementation (ericb) ( 2nd February 2007 )

Pavel Janik proposed to implement TransformProcessType() ( 2nd February 2007 )

[not commited] implement UpdateSettings() (ericb)

Pavel Janik resynchronized aquavel01 cws with m202 ( 2nd February 2007 )

====alpha 0.03====

Michel Renon joined the Team (1st February )

[done] fix checkbuttons and radiobuttons issues: offsets, redrawing of the check marks ( ericb)

[done] fix scrollbar buttons (implement correct methods to retrieve dimensions)

[done] implement mapfiles for Mac OS X (Stephan Bergmann, Daniel Boelzle, Tino Rachui , Pavel Janik)

====alpha 0.02====

[done] modify libsalsystools.dylib to be correctly loaded with the bundle (ericb, + pjanik)

[done] add mouse drag events ( pjanik )

====alpha 0.01====

[done] add new feature for Aqua windows, to allow QuickTime player use( mox )

[done] replace obsolete code in salframe.cxx with (ericb)

[done] fix correct size for main window (GetOptimaWindowSize() ) (ericb)

[done] fix alpha channel in pixmaps (ismael)

====alpha 0.0====

[done] pushbutton where not correctly drawn (ericb)

[done] fix missing mouse events (pjanik)

[done] fix nRepeat in text entry (ssa)

2nd Mac porters Meeting

===Work in progress ===

URGENT :

Top of issues causing crashes : event issue when tips is enabled causes crashes ( well known window / handler / window desctructor / event loop bug )

Salatsuifontutils : replace old code, track leaks : tino

[done] Bitmaps : ( isma87)

[running] Crashes : (tino, pjanik, ericb, isma87, plipli )

[???] Drag and drop : (vijay)

[???] Printing (ybart)

Florian Heckl proposed a subject for Google Summer of Code about native printing

Drawing/ windowing ( plipli / ericb ) -> mainly refresh

[done] Implement cursor

[started] Native Controls (ericb)

[work in progress] partial multiline sallayout (plipli )

To do :

(started, Oliver) - modify the tree to make the bundle start without hack ( issue fixed during buildtime)

(started, Florian Heckl) verify Native FilePicker implementation ( works , tested in Hamburg )

[done] Ismael Merzaq) implement blit functions in salgdi ( important fix: probably apha version to be tested once done)

[done] Sebastien Plisson- update the missing functions list ( fonts ... ask hdu & cl

[started] ericb, Mox Soini, Sebastien Plisson, Tino Rachui, Pavel janik continue to replace obsolete code

fix crashes with menus (started : tino )

== '''Sort of documentation about VCL around Native Mac OS X port''' ==

Do we really need to understand how it works? ;-)

vcl content:

ls -laR | wc -l
1750

-> Uff 1750 files to analyse :-/

Our purpose is to describe the vcl organisation. The content of vcl is so important, that at the begining, the content will looks a bit confused. e.g. class names ..etc have nothing to do, only description with words and sense, but this will need some time before we can understand everything.

How analyse with more efficiency? After some months to anlalyse '''"horizontaly"''', it appears that list all the content of a directory is not the solution. Of course, we learned a lot, but we now have to complete with '''"orthogonal"''' method (compared to the previous one). The first method wasn't obviously not the good/best way to describe vcl.

[FIXME] a different approach (will ask confirmation to Philipp Lohman), could be a description of how it work in runtime. First define what an instance is, a frame, and what exactly is concerned by such "objects".

With that, we can write a list of different objects all using the same scheme: empty boxes (means pure virtual methods and classes in generic libvvcl), really implemented in the specific part, and finally, the API "encapsulated".

The most difficult is to see where the API is used. But for all the parts, this is the same.

Finally, '''what is important is the design of vcl'''. Which '''patterns''' are used? What are the dependencies, how works the stack for the events, how works the scheduler, the timers too is very important, even fundamental for Aqua implementation. Will have a look at gsl mailing list, and other resources. Probably everything is already (randomly) written somewhere.

=== VCL organisation ===

Thank's to Philipp Lohmann for this short, but precise description:

Basically vcl is divided in the system dependent and the system independent part. The interface between these two is mostly the Sal interface (every interface name Sal*: SalInstance, SalFrame, SalGraphics, SalPrinter, etc.).

SalInstance is a factory that can create all the other abstracted interfaces of the system dependent part. It also provides the main loop SalInstance::Yield()

SalFrame abstracts any kind of system window.

SalVirtualDevice abstracts an offscreen window (e.g. a Pixmap on X11)

SalPrinter and SalInfoPrinter abstract the system print queues where SalInfoPrinter is for querying and SalPrinter for actual printing.

SalGraphics is an interface produced by either SalFrame, SalVirtualDevice or SalPrinter which is used for actual drawing operations (text, bitmaps, vector graphics)

SalSound is for sound playing.

SalBitmap provides memory for bitmap graphics as well as methods converting this memory to a system handle (e.g. a Pixmap on X11).

SalOpenGL provides OpenGL functionality if available.

SalTimer is an interface for periodically triggering the event queue (to timer implementation).

SalI18NImeStatus handles how the status window of an Input Method Editor (IME) should display (this is mainly X11 specific).

SalSystem has some system specific methods that did not belong anywhere else:-)

Of all these there interfaces is at least one implementation per system (Windows, X11 or Mac). The Unix implementation also has a plugin concept to allow for integration of different native toolkits (currently gtk and Qt) which became necessary for the implementation of Native Widget Framework (NWF) to display controls like their normal desktop counterparts.

Basically the independent part (what is beneath vcl/source directory) has generic methods for drawing, window handling and stuff which it brings into a suitable form and then delegates to the system specific implementation (located beneath vcl/win for Windows and vcl/unx for the X11 platforms).

[[User:Ericb|Ericb]] 16:12, 1 July 2006 (CEST)

===Sub-directories description ===

==== '''Organisation of vcl directories''' ====

[[Image:aquavcl_organisation_complete_02.jpg]]

==== '''Directories in vcl. Short description''' ====

''' aqua ''': The name Aqua means Apple look and feel, and is well known as [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html Aqua Human Interface Guidelines]. This look and feel means Mac OS X. The work was begun by (probably) P. luby, Dan Williams Herbert Duerr (most of fonts stuff) and Ed Peterlin. Currently in ruin, this directory does contain a lot of ideas to investigate. The most important part of needed changes for native version (3.0) will be done inside aqua dir inc: does contain all vcl relative includes [PART1]

''' prj ''': Does contain build.lst and d.lst build.lst give us dependencies: probably a lot for vcl, build 98th module over ~148. Everything graphical depends in vcl.

''' qa ''' does contain all quality assurancy stuff

'''source''': the most important:-) This directory contains common sources for all architectures and OS. Mainly: Windows, Unix: Linux , Mac OS X (X11), Solaris, including generic, kde and gtk plugins, and Aqua (Mac OS X without X11, work currently in progress).

Depending on the OS and the architecture, binaries are built or not.

''' test ''': This directory does contain all the needed stuff for tests. As example, in qa/testdocuments, you'll find three documents (one writer, one calc and one impress) for tests purpose.
Other available tests are about memcheck and persistent window state.

''' unx ''': this directory does contain all unixes stuff. We have to understand what is inside to implement aqua port. For example, a lot of classes/strutures and objects use Xlib calls we have to replace with Carbon/Cocoa call (at least at first time) for Mac OS X native port.

''' win ''': Doing Mac OS X native port, I first believed this directory was not interesting for us, but I was wrong: OpenOffice.org roots are inside this directory, and a lot of comments and resources are inside. Mainly interesting if Carbon is used.

'''workben''': Does contain a toy called "svdem". svdem is a binary, used for new implementations. For example, actual aqua development uses svdem intensively, to verify all important properties we need:

- display a window first (al least ...:))

- close cleanly this window

- display a point

- trace a line

- trace an area

- superpose two areas doing some important graphical operations, (like xor),

- display a character

- display a menu.

- intercept events correctly.

[FIXME] add more tests

[[User:Ericb|Ericb]] 13:21, 3 June 2006 (CEST)

=='''Naming convention''' ==

* Class names start with upper case letters, to improve readability.

* Implemented Class names are derived from the virtual classes but can of course take arbitrary names.
To increase readability, it's recommended to closely follow the base class name.

* '''Impl prefix: means Implementation details'''. The concerned class or method or function is not used outside of this module, so no external code (or other libraries) can see it.

'''[[ Events types using Carbon API (Mac OS X): ]]''' A lot of events have to be managed in runtime. Here is a short description

- do not freeze because bad event loops

- event types implementation: currently, they are defined in vcl/aqua/inc/aquavclevents.hxx

Apart: exact sense of hedabu? -> [FIXME] as far as I understood it: it is like "copy" to deliver software into the solver, with extra magic. The header files for example are manipulated so paths need not be exact. "headabu" is supposed to disappear little by little.

== '''What do we have to build in vcl?'''==

Two libraries, corresponding ressources (localized) and a toy so called « svdem »

'''Common part''':

in grey on right. The result will be a non architecture dependant library, built in all cases: for instance, libvcl680mxi.dylib on Mac Intel.

'''Specific part " a plugin " ''':

Light yellow: aqua part will only concern Mac OS X (non X11) the name will probably be libvcl_aqua680mxi.dylib

As you can see, win means windows part, in blue

For Unix build (Linux, Solaris or current Mac OS X X11), in purple.

Result will be:

libvclplug_PLUGIN680mxi.DLLSUFFIX , where PLUGIN can be iether gen (generic) or gtk (using gtk+) or kde (using qt), and DLLSUFFIX can be either .so (linux) or .dylib (Mac OS X) ...etc (I'm not sure for other cases).

Example: libvcl680mxi.dylib and libvclplug_aqua680mxi.dylib

'''In runtime''', libvclplug_aqua will be linked to libvcl680. the first one will contain the real implementation (respecting the API, e.g. Carbon) while the generic libvcl will only contain pure virtual methods ...etc like "empty boxes".

=== Current Aqua content ===

A more complete description of aqua (Mac OS X / no X11 specific): [[Image:Vcl_aqua_organisation_02_tree.jpg]]

==EXISTING objects to build in aqua==

===Sal APP "everything application"===

[FIXME] add all objects descriptions

==== saldata ====

* '''Defined in plugin exclusively''' (i.e. for headers)

Unix: unx/source/app/saldata.cxx (header in unx/inc)

'''Aqua: aqua/source/app/saldata.cxx (header in win/inc)'''

Windows: win/source/app/saldata.cxx (header in aqua/inc)

* Role: saldata contains various kind of data used by the implementation for the concerned platform. '''It is a bunch of global data collections reserved for the platform'''

It is just completely platform dependent, and nobody except this plugin can see it.

'''Saldata is something like a "second sal", but providing an abstraction regarding windowing and graphics''', while SAL module provides an abstraction more Operating System oriented)

e.g. : have a look at XRequest array in vcl/unx/source/app/saldata.cxx => all calls are for Xlib (X11). Ok, useless there, but interesting:-)

[FIXME]: use Windows implementation could be a good starting point. Nothing is the same, but the current aquavcl cws uses similar objects, and it works very correctly.

saldatax.cxx uses classes SalInstance, SalObject, SalFrame, SalVirtualDevice, SalPrinter and fontList.

Current list of possible objects who can be instantiated/released:

structure SalData: does contain pointers on all kind of objects from other classes used in saldata.

inline functions: [FIXME]: complete the description

- SetSalData:
- GetSalData:
- GetAppSalData:

==== salinst ====

=> implemented in vcl/aqua/source/app/salinst.cxx

Role:

* get environment, mutexes, instantiate AquaSalInstance (Ctor, Dtor),

* instantiates/releases a lot of other objects using Get() / CreateObject() / DestroyObject() methods.

Current list of possible objects who can be instantiated/released:

* VirtualDevice [FIXME]: exact role?

*Printer

- GetDefaultPrinter/ CreatePrinter() / DestroyPrinter - what a name ;-) -

- InfoPrinter (Get/Create/Delete)

- PrinterQueue (DeletePrinterQueueInfo / GetPrinterQueueInfo / GetPrinterQueueState)

* System (Create / Delete) [FIXME]: what means system here?

* Events:

AquaSalInstance::SetEventCallback()

AquaSalInstance::SetErrorEvenCallback()

AquaSalInstance::GetConnectionIdentifier()

* Menu / MenuItem:

AquaSalInstance::CreateMenu() / same for DestroyMenu()

AquaSalInstance::CreateMenuItem / same DestroyMenuItem()

* Sound:

AquaSalInstance::CreateSalSound() => object to a pointer of SalSound type

Note: AquaSalInstance::DestroySalSound is not implemented (?)

* Timer: CreateTimer() /

AquaSalInstance:: DestroyTimer() is not yet implemented (?)

Class MacImeStatus: inherits of SalI18NImeStatus

-> only there to see if there is a window to toggle into menubar [FIXME]??

AquaSalInstance::CreateI18NImeStatus(): instantiates MacImeStatus

'''For futher informations, see: ''' '''[[Content of salinst.cxx]]'''

([[User:Ericb|Ericb]] 16:11, 20 May 2006 (CEST) )

==== salmain ====

Role: if possible, runs the standard vcl application code SVMain()

([[User:Ericb|Ericb]] 16:15, 20 May 2006 (CEST))

==== salsound ====

==== salsys ====

==== saltimer ====

=== Sal GDI (everything Graphical Display Interface) ===

====salgdinativewidgets====

[[native controls]]

==== salatslayout ====

==> implemented in vcl/aqua/source/gdi/salatslayout.cxx

- Handle text layouting :

* Use ATSUI (ATSUCreateTextLayoutFromPtr) to layout the text unicode char buffer
* Use ATSUI (ATSU..) to get informations about glyphs
* Populate different arrays (mpGlyph2Chars, mpChars2Glyph, mpCharsWidths, mpGlyphAdvances)
that are used in various methods.

==== salatsuiutils ====

==== salfontutils ====

==== salmathutils ====

==== sal bmp ====

==== salvd ====

==== salpixmaputils====

==== salprn ====

====salrectangle====

==== salvd ====

=== Sal Window===

==== salframe ====
Documentation in progress, from damiend :
[[User:Damiend|Damiend page]]

====salobj====

== TO BE IMPLEMENTED (missing in Aqua)==

===Audio===

====audioconvert====
(obsolete?)

====devaudio====
(obsolete?)

====native sound====

====salimpsound====

====vsound====

===i18n===

===keysymnames===

===saldisp===

===sm===

[FIXME]: is session manager usefull?

=='''Native Controls'''==

====Scrollbar====

'''Works as expected'''. The most important work is done

See : [[Mac_OS_X_Porting_-_Native_Controls#ScrollBar]]

====DrawThemeButton() documentation====

'''Started'''

See : [[Mac_OS_X_Porting_-_Native_Controls#ComboBox]]

Started
<pre>
DrawThemeButton
Draws a button.

OSStatus DrawThemeButton (
const Rect * inBounds,
ThemeButtonKind inKind,
const ThemeButtonDrawInfo * inNewInfo,
const ThemeButtonDrawInfo * inPrevInfo,
ThemeEraseUPP inEraseProc,
ThemeButtonDrawUPP inLabelProc,
UInt32 inUserData
);
Parameters
inBounds
A pointer to a structure of type Rect. Pass a rectangle specifying the boundary of the button, in local coordinates.

inKind
A value of type ThemeButtonKind. Pass a constant specifying the type of button to draw.
See “Theme Buttons” for descriptions of possible values.

inNewInfo
A pointer to a structure of type ThemeButtonDrawInfo. Before calling DrawThemeButton,
set the structure to contain the new state, value, and adornment for the button.
DrawThemeButton uses the information passed in the inNewInfo and inPrevInfo parameters
to apply transitional animation or sound effects as the button state changes, if such are
specified under the current theme.

inPrevInfo
A pointer to a structure of type ThemeButtonDrawInfo. If the button state is changing,
set the structure to contain the previous state, value, and adornment for the button,
to allow DrawThemeButton to apply any transitional effects. If the button state is not
changing, you can pass NULL.

inEraseProc
A value of type ThemeEraseUPP. If you have a custom background, use this parameter to pass
a universal function pointer to an application-defined function such as that described in
ThemeEraseProcPtr. DrawThemeButton calls this function to erase the background before drawing
the button. If you pass NULL, DrawThemeButton's default behavior is to erase the background
for you.

inLabelProc
A value of type ThemeButtonDrawUPP. If you pass a universal function pointer to an
application-defined function such as that described in ThemeButtonDrawProcPtr, DrawThemeButton
calls that function to draw the label of the button. If you pass NULL, no label is drawn.

inUserData
An unsigned 32-bit integer. Provide any data to be passed in to the callback functions specified in
the inLabelProc and inEraseProc parameters. Pass NULL if you do not wish to provide any data.

Return Value
A result code. See “Appearance Manager Result Codes”.

Discussion
The DrawThemeButton function draws a theme-compliant button. If a ThemeEraseProcPtr is
specified in the inEraseProc parameter, DrawThemeButton uses that function to erase the
background of the button before drawing the button. After the button is drawn, if a
ThemeButtonDrawProcPtr is specified in the inLabelProc parameter, DrawThemeButton calls
that function to draw the button’s label.

Note that DrawThemeButton also draws any appearance adornments for the button and that these
can extend beyond the button’s basic bounding rectangle, as specified in the inBounds parameter,
and may be of variable shape. You may therefore wish to call the function
GetThemeButtonBackgroundBounds to obtain the actual rectangle containing the pixels belonging
to a button under the current theme.

Version Notes
This function is available with Appearance Manager 1.1 and later.

Availability
Available in CarbonLib 1.0 and later when Appearance 1.1 or later is present.
Available in Mac OS X 10.0 and later.
Declared In
Appearance.h
</pre>

====HIComboBoxCreate() documentation====

<pre>
HIComboBoxCreate
Creates a combo box control.

OSStatus HIComboBoxCreate (
const HIRect* boundsRect,
CFStringRef text,
const ControlFontStyleRec* style,
CFArrayRef list,
OptionBits inAttributes,
HIViewRef* outComboBox
);
Parameters
boundsRect
The bounding box of the control.

text
The default text in the editable portion of the control. Can be NULL.

style
The font style of the both editable text and the text in the disclosure list. Can be NULL.

list
The default values available in the disclosure list. Can be NULL.

inAttributes
The default attributes of the combo box. For possible values, see “Combo Box Attributes”.

outComboBox
On exit, a pointer to a reference for the new control.

Discussion
The combo box can be used in compositing mode, as well as traditional Control Manager mode.
When created, this view is invisible. To see the view, you must show the view by calling HIViewSetVisible.
</pre>

== What is used for Linux, Windows, Mac OS X ...build ? ==

'''[[Description of the dependencies]]'''

'''[[Windows]]'''

'''[[MacOS X]]'''

'''[[Linux]]'''

'''[[Solaris]]'''

== Content of Aqua ==

'''[[Click here to see the complete list]]'''

'''Content of vcl/inc'''

Notes:

1) Where to find includes

<foo/bar.hxx> means you can find bar.hxx in the foo module. The new style file is foo/inc/foo/bar.hxx, old style is foo/inc/bar.hxx and sometimes the file is somewhere else in the tree or generated. The deliver process copies/generates the file into solver at solver/680/build_type/inc/foo. Good for fixing broken builds. ;-)

2)
suffix .h (for C calls or first version?) or .hxx (C++)

'''A) Family of includes''':

Looking more closely at the list brings to the fore (expression from dictionary ;-) ) that include names are
informatives. Most of the time, the name gives the function/role.
What is interesting is the files with name begining with "sal". sal means System Abstraction Layer + include's function (or explicit name).

Partial list, for example:

salatype.hxx

salbmp.hxx

salctrlhandle.hxx

salctype.hxx

salframe.hxx

salgdi.hxx

salgeom.hxx

sallayout.hxx (main header for fonts services)
...
salmenu
salnativewidgets
...etc

Other important families are "sv" and "uno" or "win" (window) prefixed. sal family will be analysed apart.

'''B) Includes of includes'''

Some includes are more important than other. To prove this, just have a look is sufficient: some are always needed, and some more rarely.

To verify, a simple test to do in vcl/inc:

egrep -H "#include" ./* | wc -l gives me 681 lines ! And some of them are the same...

To know more, the precedent command line can be modified to make appear the numerous call
to the same includes files.

egrep -H "#include" ./* | cut -d"#" -f2 | sort > liste.txt

The content of liste.txt is explicit: dllapi.h, sv.h and some other are very important, while some other includes are only one or two times used. We can see too that vos includes are numerous, even if vos is deprecated**

**see http://wiki.services.openoffice.org/wiki/Source_code_directories

I'm nearly sure that a complete analysis of just this result will give us a lot of information.

I propose to change the order of analysis starting with dllapi.h and sv.h.

[to be continued]

'''B1) "sal" includes family'''

[[salinst.hxx]] This seems to be the main include file

[[salatype.hxx]]

[[salctrlhandle.hxx]]

[[salctype.hxx]]

[[salframe.hxx]]

[[salgdi.hxx]]

[[salgeom.hxx]]

'''[[ sallayout.hxx ]]''' <-- see Native Fonts implementation

[[salgtype.hxx]]

[[vcl/inc/salobj.hxx]]

'''B2) Classicals includes'''

file: abstdlg.hxx [ means abstract dialog ]

This includes does contain the following classes definitions:

[FIXME] : choose a precise presentation template for classes

VclAbstractDialog,

VclAbstractTerminateDialog,

VclAbstractRefreshableDialog,

VclAbstractDialogFactory,

uses <tools/solar.h> , <tools/string.hxx> +

"dllapi.h"

Note : dllapi.h is very interesting because when we have to find (for example) a library suffix, SAL_DLLEXTENSSION can replace all suffixes (every OS's and archs). Just including sal/config.h does it !

Classes:

Window -> what? [FIXME]
ResId -> what?

Does contain the prototype of VclAbstractDialog, inherit of VCL_DLLPUBLIC

file: dllapi.h [ dll for dynamic linked library ]
Uses: <sal/config.h> and >sal/types/h>
includes: VCL_DLLPUBLIC macro

file: accel.h [ means accelerator ]

Classes:

Accelerator
{
}
ImplAccelEntry
{
public members:

Names

mnId
maKeyCode
mpAccel
mpAutoAccel
mbEnabled
}

function / returns / parameters

ImplGetKeyCode / void / KeyFuncType eFunc, ref rCode1 , ref rCode2, ref rCode3

file: accel.hxx

Uses: <sv.h> , "dllapi.h" ,<tools/resid.hxx>, <<tools/rc.hxx>

Classes:

ImplAccelData;
ImplAccelEntry;

== Important Links ==
'''[[Progressive implementation]]'''

'''Native Font server Implementation''' '''[[Mac OS X Porting - Native Fonts]]'''

'''Native Sound Implementation''': [[Mac OS X Porting - Native Audio and Video]]

'''Native Printing Implementation''': [[Mac OS X Porting - Native_Printing]]

'''Drag and Drop implementation''': [[Mac OS X Porting - Native Drag and drop]]

'''Data Acquisition''' : [[Mac OS X Porting - Data Acquisition]]

This work is part of http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s

[to be continued:-) ]

== Keyboard comparizon between OpenOffice.org / Mac OS X application ==

[FIXME] redo a cleanest array

{| style="vertical-align:top; text-align:centered; background-color:#F0F0F0;"
|- style="background-color:#99CCFF; font-weight:bold;"
| Modifier||+ key || Result || TextEdit returns
|-
|ALT|| a||æ ||æ
|-
|ALT||b||ß ||ß
|-
|ALT||c||© ||©
|-
|ALT||d||∂ ||∂
|-
|ALT||e||ê ||ê
|-
|ALT||f||ƒ ||ƒ
|-
|ALT||g ||ﬁ ||ﬁ
|-
|ALT||h ||Ì ||Ì
|-
|ALT||i ||î ||î
|-
|ALT||j ||Ï ||Ï
|-
|ALT||k ||È ||È
|-
|ALT||l ||¬ ||¬
|-
|ALT||m ||µ ||µ
|-
|ALT||n ||~ ||~
|-
|ALT||o ||œ ||œ
|-
|ALT||p ||π ||π
|-
|ALT||q ||‡ ||‡
|-
|ALT||r ||® ||®
|-
|ALT||s ||Ò ||Ò
|-
|ALT||t ||† ||†
|-
|ALT||u ||º ||º
|-
|ALT||v ||◊ ||◊
|-
|ALT||w ||‹ ||‹
|-
|ALT||x ||≈ ||≈
|-
|ALT||y ||Ú ||Ú
|-
|ALT||z ||Â ||Â
|-
|ALT||A ||Æ ||Æ
|-
|ALT||B ||∫ ||∫
|-
|ALT||C ||¢ ||¢
|-
|ALT||D||∆||∆
|-
|ALT||F ||· ||·
|-
|ALT||G ||ﬂ ||ﬂ
|-
|ALT||H ||Î ||Î
|-
|ALT||I ||Î ||Î
|-
|ALT||J ||Í ||Í
|-
|ALT||K ||Ë ||Ë
|-
|ALT||L || <pre>|</pre> ||<pre>|</pre>
|-
|ALT||M ||Ó ||Ó
|-
|ALT||N ||ı ||ı
|-
|ALT||O ||Œ ||Œ
|-
|ALT||P ||∏ ||∏
|-
|ALT||Q ||Ω ||Ω
|-
|ALT||R ||‚ ||‚
|-
|ALT||S ||∑ ||∑
|-
|ALT||T ||™ ||™
|-
|ALT||U ||ª ||ª
|-
|ALT||V ||√ ||√
|-
|ALT||W ||› ||›
|-
|ALT||X ||⁄ ||⁄
|-
|ALT||Y ||Ÿ ||Ÿ
|-
|ALT||Z ||Å ||Å
|-
|ALT||$ ||€ ||€
|-
|ALT||` ||@ ||@
|-
|ALT||£ ||# ||#
|-
|ALT||* ||¥ ||¥
|}

Sous réserve d'erreur ou omission [[User:Ericb|Ericb]] 00:05, 14 January 2007 (CET)

--[[User:Ericb|Ericb]] 15:00, 22 Jul 2005 (EDT)

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

User:Ericb

2007-03-25T07:27:00Z

Plipli: /* What do we have to do? */

==Public Documentation License Notice==

The contents of this Documentation (excepted Native Port Roadmap),are subject to the Public Documentation License Version 1.0 (the "License"); you may only use this Documentation if you comply with the terms of this License. A copy of the License is available at http://www.openoffice.org/licenses/PDL.html.
The Original Documentation is "Mac OS X native port". The Initial Writer of the Original Documentation is (JCA) Eric Bachard (C) 2005-2006. All Rights Reserved. (Initial Writer contact(s): ericb@openoffice.org.)

=='''Mac OS X Native port'''==

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">
'''The first Mac OS X native port objective is make OpenOffice.org run without X11 use, to make it a real Mac application.'''

'''The second one is respect Aqua Human interface Guidelines'''

''' This is a long term work, and every help and/or contributions, like donations** are welcome.'''
</div>

**see http://contributing.openoffice.org/index.html

=='''Native Port Roadmap'''==

==='''2006'''===

* June 2006: work in progress

- Basis: frame, instances, threads, drawing, painting, resizing (Stephan Schaefer, Tino Rachui)

Done:
implement threads
create, manage instance
create, manage windows (including parents)
create, manage events
create manage drawing, resizing
create, add menus (Pavel Janik)
toggle window fullscreen (Pierre de Filippis)
make font server work (Stephan Schaefer)

* Current status font support (Stephan Schaefer, 2006/07/28): the following features are basically working now
** font selection
** font size
** simple font attributes (bold, italic)

Next step: document first part, and propose design

- native filepicker (Pavel Janik, Florian Heckl)

- native printing implementation (Oliver?)

- native font implementation (Eric Bachard)

* September 2006:

- first proofs of concept: fonts, filepicker .. (more?)
- show the results (OOoCon 2006?)

==='''2007'''===

* January 2007: first alpha implementation

=='''Strategy for native port'''==

'''Possible Actions''':

Identify us:

#Complete the arrays below
#Update photos on frapr.com?

Share the work:

#Divide the work between little Teams
#Update Todo list regularly -> needs some love these days ... [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s]

Help:

#Teach tools between us
#Do a debug party on IRC
#write documentation

Meet us:

#IRC
#Mac Meeting (like nov2005 in Hamburg?)

Inform:

#Update website regularly
#Blogs

'''WHO''':

Mac Team:

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
|Developer \ skills || build || write code || code review || debug/trace (higher is better) || contribute to documentation ||
|-
|ericb|| x || x || || 1 || x ||
|-
|pjanik|| || || || || ||
|-
|ssa|| || || || || ||
|-
|maho|| || || || || ||
|-
|tinor|| || || || || ||
|-
|schmidtm|| || || || || ||
|-
|ebischoff|| || || || || ||
|-
|obr|| || || || || ||
|-
|cl|| || || || || ||
|-
|aliscafo|| || || || || ||
|-
|fheckl|| || || || || ||
|-
|Fridrich|| || || || || ||
|-
|plipli|| || x || || || x ||
|-
|}

'''Other resources''':

fonts: ?

events: ?

QA: James McKenzie leads QA for the Mac OS X port of OpenOffice.org and is looking for volunteers to spread this effort over several people and needs people from all over the world to test various languages.

graphical: ?

Communication: ?

'''WHAT''': Status of most important tasks

{| style="vertical-align:top; text-align:left; background-color:#efefef;"
|- style="background-color:#d6d6d6;font-weight:bold;"
| Task || Names|| Urgency (1=higher)|| Work in Progress || Done || Code review || Debug || Integration ||
|-
|Get rid of X11||done || 1 || x || x || || || ||
|-
|Bundle|| || 1 || x || || || || | ||
|-
|Drawing|| || 1 || x || || || || || ||
|-
|Fonts||plipli || 1 || x || || || || || ||
|-
|Events management|| || 2 || x || || || || || ||
|-
|Controls (see list) ||ericb, aliscafo || 2 || x || || || || || ||
|-
|Native FilePicker||Florian Heckl, Pavel Janik || 3 || x || x || || || || ||
|-
|Native Printing||Yvan Barthelemy || 3 || x || || || || || ||
|-
|Native SpellChecker|| || 4 || || || || || || ||
|-
|Player||Mox Soini || 4 || x || || || || || ||
|}

Other tasks:

Help for writing bug lists, status of bugs ..etc

Write howto use gdb, leaks, other tools

'''WHEN''':

From Christian Lippka (last meeting, 25th of august 2006):
Aug 26 00:21:38 ChristianL
from my point of view what is missing for point 1:
text layout, complete font support, keyboard support,
fixing repaint issues, having aqua install and run out of the box

'''September 2006'''

Present the current state of the project at the 2006 OpenOffice conference in Lyon and Paris

'''Late 2006'''

fix OpenOffice.org launch
fix drawing (repainting)
Implement missing methods and fix most important bugs (mainly the one leading to crash) in:
ATS
Salgraphics
Salinstance

'''January or February 2007'''

make Java work (works partially)
make intensive debug
present something working as alpha

'''June 2007 '''

Implementation of:
native filepicker
native printing

== '''Become a Domain Developer for Mac OS X port''' ==

People regularly contributing to Mac OS x port with regular and quality patches are, after proposal, invited to become a [[DomainDeveloper]].

The purpose of this document is to clearly define all the steps to become a [[DomainDeveloper]].

Preliminary : step 1 in [[Commit_Rights]] must be completed and checked, and you must be in the list of [[http://www.openoffice.org/FAQs/faq-licensing.html#jca1 JCA Licensed people]]

=== Steps for ssh2 key to be uploaded ===

==== Create the key ====

Everything is described here : [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

==== Upload the key ====

You must create an issue, like described below :

Component : www

Sub Component : openoffice.org cvs

Title : CVS Commit access request

Add louis ( Louis Suarez Potts) or st ( Stefan Taxhet ) on CC

Upload your ssh2 public key respecting the process ( Attach a DSA key, not an RSA )

A project lead will confirm your request

Then the support will upload your key

Once done the issue is set to Fixed , and the next step has to be verified before '''you''' close it.

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75291 Upload SSH2 Key for Etsushi Kato]]

==== Verify it works ====

You now can try to connect via tunnel, and follow instructions given [[http://www.openoffice.org/scdocs/ddSSHGuide.html SSH Guide]]

If something goes wrong, ask for help to support, with a maximum of details, to solve the problem.

Once it works, the issue can be closed, and you can e.g. test downloading a module from tunnel repository :

First create a tunnel with the command:
<pre>
ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org
</pre>

Then in a new window:

<pre>
export CVSROOT=":pserver:your_login@localhost:/cvs"

cvs login ( enter )

(your password )

mkdir TEST

cd TEST

cvs -z4 co -r SRC680_m205 vcl

cd vcl

cat CVS/Root -> should indicate : your local repository
</pre>

=== Ask for CVS access for all modules required ===

Two steps : create an issue is mandatory because the concerned project is tools, and because people can have only ssh2 key without being [[DomainDeveloper]].

==== Create an issue ====

You must create an issue, described below :

Component : tools

Sub Component : www

Title : CVS access to all modules required

Assigned to mh + CC for ericb and/or pjanik

Present yourself quickly, and ask the access

A project lead will confirm

An admin will confirm this is ok, and set the issue to Fixed

'''EXAMPLE''' : [[http://www.openoffice.org/issues/show_bug.cgi?id=75494 CVS Access all modules for Etsushi Kato]]

==== Verify ====

Create the tunnel :

open a terminal and type :

ssh -2 -x -L 2401:localhost:2401 tunnel@openoffice.org

once logged in, open a new terminal, and do ( for example ):
<pre>
cd $OOO_SRC_ROOT/

source MacOSXPPCEnv.Set.sh { source MacOSXX86Env.Set.sh for Mac Intel }

cd vcl ( for example )

IMPORTANT : be sure vcl has been checked from tunnel, not from anoncvs ( cat CVS/Root will give you the answer )

export CWS_WORK_STAMP=aquavcl01 # Only needed for working with [[EIS]], can change for a different CWS ;)

cd aqua/source/gdi

add your changes to your_file.cxx, then commit :

cvs commit -m "#i75689# bla bla ... the reason of the modification(s)" your_file.cxx # The #i75689# is an issue number in the tracker

cvs update

If nothing is wrong, cvs update should not return M for your_file.cxx, means the commit is successfull.
</pre>
In case of problem, use the issue until it is fixed

<big>'''Welcome aboard :)'''</big>

=='''2nd Mac porters meeting'''==

This section has been moved to [[2nd Mac porters meeting]]

=='''IRC Mac port meetings'''==

This section has been moved to [[MacOSXPortMeetings]].

== '''Mac OS X (X11) Quality Assurance'''==

This section has been moved to [[Mac OS X ( X11) Quality Assurance]]

== '''Mac OS X Implementing HIView'''==

This section has been moved to [[Mac OS X Implementing HIView ]]

== '''Debug OpenOffice.org using XCode '''==

[[ MacOSX Debug OpenOffice.org using XCode]]

=='''Description of the Native Port problem'''==

=== How does OpenOffice.org work on Mac OS X? ===

Currently, on Mac OS X, OpenOffice.org uses X11, as "client": X11 is a graphical server, coming from Unix world, and able to run under Linux, *BSD, Solaris, Mac OS X.

- X11 is run as an application, managed like other Apple applications.
- All unix like applications are managed by X11, and from Aqua environment, only X11 is seen as only one applicatiion,
even if other Unix/Linux (e.g.) applications are runing.

OpenOffice.org asks X11 to display a window, waits for X11 acknowledgment, and OpenOffice.org displays the window. All transactions use the network, locally or not. the same mechanism is used for everything to be displayed.

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=== Issues and known problems ===

All events are managed by OpenOffice.org and X11, using the Xlib

Only .ttf fonts type is currently available. Note: '''system fonts are available '''

The rendering is made by X11, not by Mac OS X rendering engine.

X11 and all its clients are seen as one application only: drag and drop protocol does not work because of that (solution: Pasteboard Manager)

==== Other links ====

http://wiki.services.openoffice.org/wiki/List_of_OpenOffice.org_Mac_OS_X_issues_and_problems#

http://wiki.services.openoffice.org/wiki/Printing_problems_with_OpenOffice.org_2.0_for_Mac_OS_X#Reporting_printing_problems

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

== What do we have to do?==

* (in progress) : Implement direct access to Apple graphical engine, using Apple API: Quartz2D/CoreGraphics (and replacing Xlib use)

like: instantiate, manage events and threads for a graphical instance + all needed objects, drawing: manage all drawing cases

* (in progress) : Implement native events management, using CarbonEventManager (replacing Xlib management)

* (in progress) : Implement native font use, using Apple Type Server and ATSUI (for Unicode Imagery) (replacing X11 management)

Work in progress: [[Mac OS X Porting - Native Fonts]]

* Implement native sound, using QuickTime (replacing Java Media Framework): [[Mac OS X Porting - Native Audio and Video]]

* Implement native Drag and drop, Implementing Pasteboard Manager: [[Mac OS X Porting - Native Drag and drop]]

* (done experimental) Implement Native Filepicker

* Implement Native Printing: current uses cups, but native printing is mandatory: [[Mac OS X Porting - Native_Printing]]

* Implement Apple Spellchecker

=='''Where is located the code to be modified?'''==

Most of the changes are located in vcl (Visual Class Layer), for everything graphical, events, fonts, rendering and printing.

Other, for sound and movies will be in avmedia (where the player is implemented in OpenOffice.org sources).

For drag and drop, dtrans is concerned (Pasteboard Manager implementation)

[FIXME]: Filepicker? Apple Spellchecker?

[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST)

=='''How will the new implementation be tested?==

Currently, all openOffice.org code can be compiled without using the Xlib. but of course, a lot of features are missing,

and the final package simply won't work

In vcl module", a '''toy''' called svdem is built at buildtime. This binary is linked to libvcl* and so all new stuff can be tested.

e.g. : draw anti-aliased lines works well.

Everything implemented in aqua vcl code will be included in libvclplug_aqua, and svdem source code will contain a specific part to proceed tests.

<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;">

'''The magic is: when all needed features will work with svdem, it will work in the new version of OpenOffice.org !!'''

</div>

[FIXME]: add more complete list of features to implement and test.

== AquaVCL 01 cws ==

[[http://qa.openoffice.org/issues/buglist.cgi?keywords=aqua Top 10 of Aqua issues]]

[[Aquavcl01 tasks]]

===Changelog ===

====Work in progresss : alpha 0.6 ====

Started (19th March ) :

Michael Sicotte proposed to investigate in timers, and continue [[http://www.openoffice.org/issues/show_bug.cgi?id=75228 Pavel's work]] : objective is to replace obsolete code. ( 23th March)

[experimental] plipli proposed a patch for a new salframe implementation, using HIView + optionally compositing (21th March )

[commit scheduled] Michael Sicotte proposed a complete patch for invert() ( SAL_INVERT SAL_INVERT_50 and SAL_INVERT_TRACKFRAME ) (20th March )

Tino proposed to work on code cleanup in salatsuifontutils.cxx, removing obsolete code

ismael and michael work on invert() + drawAlphaRect()

Damien started to work on drawEPS()

plipli and ericb work on refresh

==== alpha 0.5====

Top 10 Summary : 7 issues over 10 are fixed or very close to be :

'''time to code review, tracing, and search for memory leaks'''

[done] Unicode input in salframe ( ekato ) ( 19th March )

[experimental, works partially] beginning of HIView + HIComboxes works (text still missing) (ericb + plipli) ( 14th March )

[done] replace NewRgn() in salframe (ericb (11th March )

[experimental, but very interesting] Improved native windows ( ismael ) ( 7th March )

====alpha 0.4====

'''[Informative]''' build runs with Leopard 9A377a ( fheckl ) ( 7th March )

Refresh screen issues (plipli) (4th to 10th March )

'''[informative]''' plipli announced progress with refresh screen issues ( 28th February )

[experimental, not yet commited] Proxy configuration from system ( pjanik) ( 28th February )

[done] highlighted native button ( pjanik) ( 27th February )

Native File Picker works ( fheckl / pjanik ) ( 23th February )

====alpha 0.3====

Cursor does appear -> invert() + setting a setBlinkTime value in UpdateSettings() (pjanik /ericb )

[done] mirroring negative images (ismael) + DrawAlphaBitmap() + CreateWithMask()

pjanik patch for Focus Events

[done] scrolling works ( pjanik ) (17th February )

[done ] carret works ( plipli) (17th February )

[done] checkbuttons fix for checkmarks (ericb) ( 17th February )

'''[Informative]''' Pavel Janik propose to solve offScreen buffer using HIView ( 17th February )

[experimental, never commited] patch for macosxrc.txt use + UpdateSettings() use in salframe.cxx ( ericb ( 16th February )

Michael Sicotte joined the Team ( 15th February )

invert() : first try (ericb) ( 13th february )

====alpha 0.2====

[12th February 2007 ]

[done] calc does not start : bug identified by tino , first workaround (ericb) [[http://www.openoffice.org/issues/show_bug.cgi?id=73691 issue 73691]]

[done] bitmaps in native popup menus (ismael)

[done] replace obsolete code for HandleWindowPaintEvent(), newRgn() .. etc (ericb) (12th February)

correct salatslayout patch (plipli) ( 11th February)

'''[Informative]''' Michel Renon proposed a summary about his work on fonts issues

[patch] Pavel fixed several menu crashes (09th February )

'''[Informative]''' : Pavel posted a mail about several crashes origin

patch for radioboxes and checkboxes ( ericb ) (9th February)

first complete patch for salatslayout.cxx ( plipli) ( 9th February )

[done] most important crashes fixed ( pjanik) ( 09th february )

Modified baseline for 2.2. : Mac OS X10.4 -> Aqua will be 10.4 and 10.5 compatible only ( ericb)

first try with multi line sallayout (plipli ) ( 08th February )

Damien Duportal joined the Team ( 7th February )

[done] scrollbar changes (ericb ) ( 4th February )

====alpha 0.1====

create Top 10 of issues before alpha 3rd February 2007 : See : [[http://porting.openoffice.org/mac/news/2007/20070203toptenbeforealpha.html Top 10 of issues]]

[experimental, not commited] patch for TPT() implementation (ericb) ( 2nd February 2007 )

Pavel Janik proposed to implement TransformProcessType() ( 2nd February 2007 )

[not commited] implement UpdateSettings() (ericb)

Pavel Janik resynchronized aquavel01 cws with m202 ( 2nd February 2007 )

====alpha 0.03====

Michel Renon joined the Team (1st February )

[done] fix checkbuttons and radiobuttons issues: offsets, redrawing of the check marks ( ericb)

[done] fix scrollbar buttons (implement correct methods to retrieve dimensions)

[done] implement mapfiles for Mac OS X (Stephan Bergmann, Daniel Boelzle, Tino Rachui , Pavel Janik)

====alpha 0.02====

[done] modify libsalsystools.dylib to be correctly loaded with the bundle (ericb, + pjanik)

[done] add mouse drag events ( pjanik )

====alpha 0.01====

[done] add new feature for Aqua windows, to allow QuickTime player use( mox )

[done] replace obsolete code in salframe.cxx with (ericb)

[done] fix correct size for main window (GetOptimaWindowSize() ) (ericb)

[done] fix alpha channel in pixmaps (ismael)

====alpha 0.0====

[done] pushbutton where not correctly drawn (ericb)

[done] fix missing mouse events (pjanik)

[done] fix nRepeat in text entry (ssa)

2nd Mac porters Meeting

===Work in progress ===

URGENT :

Top of issues causing crashes : event issue when tips is enabled causes crashes ( well known window / handler / window desctructor / event loop bug )

Salatsuifontutils : replace old code, track leaks : tino

[done] Bitmaps : ( isma87)

[running] Crashes : (tino, pjanik, ericb, isma87, plipli )

[???] Drag and drop : (vijay)

[???] Printing (ybart)

Florian Heckl proposed a subject for Google Summer of Code about native printing

Drawing/ windowing ( plipli / ericb ) -> mainly refresh

[done] Implement cursor

[started] Native Controls (ericb)

[work in progress] partial multiline sallayout (plipli )

To do :

(started, Oliver) - modify the tree to make the bundle start without hack ( issue fixed during buildtime)

(started, Florian Heckl) verify Native FilePicker implementation ( works , tested in Hamburg )

[done] Ismael Merzaq) implement blit functions in salgdi ( important fix: probably apha version to be tested once done)

[done] Sebastien Plisson- update the missing functions list ( fonts ... ask hdu & cl

[started] ericb, Mox Soini, Sebastien Plisson, Tino Rachui, Pavel janik continue to replace obsolete code

fix crashes with menus (started : tino )

== '''Sort of documentation about VCL around Native Mac OS X port''' ==

Do we really need to understand how it works? ;-)

vcl content:

ls -laR | wc -l
1750

-> Uff 1750 files to analyse :-/

Our purpose is to describe the vcl organisation. The content of vcl is so important, that at the begining, the content will looks a bit confused. e.g. class names ..etc have nothing to do, only description with words and sense, but this will need some time before we can understand everything.

How analyse with more efficiency? After some months to anlalyse '''"horizontaly"''', it appears that list all the content of a directory is not the solution. Of course, we learned a lot, but we now have to complete with '''"orthogonal"''' method (compared to the previous one). The first method wasn't obviously not the good/best way to describe vcl.

[FIXME] a different approach (will ask confirmation to Philipp Lohman), could be a description of how it work in runtime. First define what an instance is, a frame, and what exactly is concerned by such "objects".

With that, we can write a list of different objects all using the same scheme: empty boxes (means pure virtual methods and classes in generic libvvcl), really implemented in the specific part, and finally, the API "encapsulated".

The most difficult is to see where the API is used. But for all the parts, this is the same.

Finally, '''what is important is the design of vcl'''. Which '''patterns''' are used? What are the dependencies, how works the stack for the events, how works the scheduler, the timers too is very important, even fundamental for Aqua implementation. Will have a look at gsl mailing list, and other resources. Probably everything is already (randomly) written somewhere.

=== VCL organisation ===

Thank's to Philipp Lohmann for this short, but precise description:

Basically vcl is divided in the system dependent and the system independent part. The interface between these two is mostly the Sal interface (every interface name Sal*: SalInstance, SalFrame, SalGraphics, SalPrinter, etc.).

SalInstance is a factory that can create all the other abstracted interfaces of the system dependent part. It also provides the main loop SalInstance::Yield()

SalFrame abstracts any kind of system window.

SalVirtualDevice abstracts an offscreen window (e.g. a Pixmap on X11)

SalPrinter and SalInfoPrinter abstract the system print queues where SalInfoPrinter is for querying and SalPrinter for actual printing.

SalGraphics is an interface produced by either SalFrame, SalVirtualDevice or SalPrinter which is used for actual drawing operations (text, bitmaps, vector graphics)

SalSound is for sound playing.

SalBitmap provides memory for bitmap graphics as well as methods converting this memory to a system handle (e.g. a Pixmap on X11).

SalOpenGL provides OpenGL functionality if available.

SalTimer is an interface for periodically triggering the event queue (to timer implementation).

SalI18NImeStatus handles how the status window of an Input Method Editor (IME) should display (this is mainly X11 specific).

SalSystem has some system specific methods that did not belong anywhere else:-)

Of all these there interfaces is at least one implementation per system (Windows, X11 or Mac). The Unix implementation also has a plugin concept to allow for integration of different native toolkits (currently gtk and Qt) which became necessary for the implementation of Native Widget Framework (NWF) to display controls like their normal desktop counterparts.

Basically the independent part (what is beneath vcl/source directory) has generic methods for drawing, window handling and stuff which it brings into a suitable form and then delegates to the system specific implementation (located beneath vcl/win for Windows and vcl/unx for the X11 platforms).

[[User:Ericb|Ericb]] 16:12, 1 July 2006 (CEST)

===Sub-directories description ===

==== '''Organisation of vcl directories''' ====

[[Image:aquavcl_organisation_complete_02.jpg]]

==== '''Directories in vcl. Short description''' ====

''' aqua ''': The name Aqua means Apple look and feel, and is well known as [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html Aqua Human Interface Guidelines]. This look and feel means Mac OS X. The work was begun by (probably) P. luby, Dan Williams Herbert Duerr (most of fonts stuff) and Ed Peterlin. Currently in ruin, this directory does contain a lot of ideas to investigate. The most important part of needed changes for native version (3.0) will be done inside aqua dir inc: does contain all vcl relative includes [PART1]

''' prj ''': Does contain build.lst and d.lst build.lst give us dependencies: probably a lot for vcl, build 98th module over ~148. Everything graphical depends in vcl.

''' qa ''' does contain all quality assurancy stuff

'''source''': the most important:-) This directory contains common sources for all architectures and OS. Mainly: Windows, Unix: Linux , Mac OS X (X11), Solaris, including generic, kde and gtk plugins, and Aqua (Mac OS X without X11, work currently in progress).

Depending on the OS and the architecture, binaries are built or not.

''' test ''': This directory does contain all the needed stuff for tests. As example, in qa/testdocuments, you'll find three documents (one writer, one calc and one impress) for tests purpose.
Other available tests are about memcheck and persistent window state.

''' unx ''': this directory does contain all unixes stuff. We have to understand what is inside to implement aqua port. For example, a lot of classes/strutures and objects use Xlib calls we have to replace with Carbon/Cocoa call (at least at first time) for Mac OS X native port.

''' win ''': Doing Mac OS X native port, I first believed this directory was not interesting for us, but I was wrong: OpenOffice.org roots are inside this directory, and a lot of comments and resources are inside. Mainly interesting if Carbon is used.

'''workben''': Does contain a toy called "svdem". svdem is a binary, used for new implementations. For example, actual aqua development uses svdem intensively, to verify all important properties we need:

- display a window first (al least ...:))

- close cleanly this window

- display a point

- trace a line

- trace an area

- superpose two areas doing some important graphical operations, (like xor),

- display a character

- display a menu.

- intercept events correctly.

[FIXME] add more tests

[[User:Ericb|Ericb]] 13:21, 3 June 2006 (CEST)

=='''Naming convention''' ==

* Class names start with upper case letters, to improve readability.

* Implemented Class names are derived from the virtual classes but can of course take arbitrary names.
To increase readability, it's recommended to closely follow the base class name.

* '''Impl prefix: means Implementation details'''. The concerned class or method or function is not used outside of this module, so no external code (or other libraries) can see it.

'''[[ Events types using Carbon API (Mac OS X): ]]''' A lot of events have to be managed in runtime. Here is a short description

- do not freeze because bad event loops

- event types implementation: currently, they are defined in vcl/aqua/inc/aquavclevents.hxx

Apart: exact sense of hedabu? -> [FIXME] as far as I understood it: it is like "copy" to deliver software into the solver, with extra magic. The header files for example are manipulated so paths need not be exact. "headabu" is supposed to disappear little by little.

== '''What do we have to build in vcl?'''==

Two libraries, corresponding ressources (localized) and a toy so called « svdem »

'''Common part''':

in grey on right. The result will be a non architecture dependant library, built in all cases: for instance, libvcl680mxi.dylib on Mac Intel.

'''Specific part " a plugin " ''':

Light yellow: aqua part will only concern Mac OS X (non X11) the name will probably be libvcl_aqua680mxi.dylib

As you can see, win means windows part, in blue

For Unix build (Linux, Solaris or current Mac OS X X11), in purple.

Result will be:

libvclplug_PLUGIN680mxi.DLLSUFFIX , where PLUGIN can be iether gen (generic) or gtk (using gtk+) or kde (using qt), and DLLSUFFIX can be either .so (linux) or .dylib (Mac OS X) ...etc (I'm not sure for other cases).

Example: libvcl680mxi.dylib and libvclplug_aqua680mxi.dylib

'''In runtime''', libvclplug_aqua will be linked to libvcl680. the first one will contain the real implementation (respecting the API, e.g. Carbon) while the generic libvcl will only contain pure virtual methods ...etc like "empty boxes".

=== Current Aqua content ===

A more complete description of aqua (Mac OS X / no X11 specific): [[Image:Vcl_aqua_organisation_02_tree.jpg]]

==EXISTING objects to build in aqua==

===Sal APP "everything application"===

[FIXME] add all objects descriptions

==== saldata ====

* '''Defined in plugin exclusively''' (i.e. for headers)

Unix: unx/source/app/saldata.cxx (header in unx/inc)

'''Aqua: aqua/source/app/saldata.cxx (header in win/inc)'''

Windows: win/source/app/saldata.cxx (header in aqua/inc)

* Role: saldata contains various kind of data used by the implementation for the concerned platform. '''It is a bunch of global data collections reserved for the platform'''

It is just completely platform dependent, and nobody except this plugin can see it.

'''Saldata is something like a "second sal", but providing an abstraction regarding windowing and graphics''', while SAL module provides an abstraction more Operating System oriented)

e.g. : have a look at XRequest array in vcl/unx/source/app/saldata.cxx => all calls are for Xlib (X11). Ok, useless there, but interesting:-)

[FIXME]: use Windows implementation could be a good starting point. Nothing is the same, but the current aquavcl cws uses similar objects, and it works very correctly.

saldatax.cxx uses classes SalInstance, SalObject, SalFrame, SalVirtualDevice, SalPrinter and fontList.

Current list of possible objects who can be instantiated/released:

structure SalData: does contain pointers on all kind of objects from other classes used in saldata.

inline functions: [FIXME]: complete the description

- SetSalData:
- GetSalData:
- GetAppSalData:

==== salinst ====

=> implemented in vcl/aqua/source/app/salinst.cxx

Role:

* get environment, mutexes, instantiate AquaSalInstance (Ctor, Dtor),

* instantiates/releases a lot of other objects using Get() / CreateObject() / DestroyObject() methods.

Current list of possible objects who can be instantiated/released:

* VirtualDevice [FIXME]: exact role?

*Printer

- GetDefaultPrinter/ CreatePrinter() / DestroyPrinter - what a name ;-) -

- InfoPrinter (Get/Create/Delete)

- PrinterQueue (DeletePrinterQueueInfo / GetPrinterQueueInfo / GetPrinterQueueState)

* System (Create / Delete) [FIXME]: what means system here?

* Events:

AquaSalInstance::SetEventCallback()

AquaSalInstance::SetErrorEvenCallback()

AquaSalInstance::GetConnectionIdentifier()

* Menu / MenuItem:

AquaSalInstance::CreateMenu() / same for DestroyMenu()

AquaSalInstance::CreateMenuItem / same DestroyMenuItem()

* Sound:

AquaSalInstance::CreateSalSound() => object to a pointer of SalSound type

Note: AquaSalInstance::DestroySalSound is not implemented (?)

* Timer: CreateTimer() /

AquaSalInstance:: DestroyTimer() is not yet implemented (?)

Class MacImeStatus: inherits of SalI18NImeStatus

-> only there to see if there is a window to toggle into menubar [FIXME]??

AquaSalInstance::CreateI18NImeStatus(): instantiates MacImeStatus

'''For futher informations, see: ''' '''[[Content of salinst.cxx]]'''

([[User:Ericb|Ericb]] 16:11, 20 May 2006 (CEST) )

==== salmain ====

Role: if possible, runs the standard vcl application code SVMain()

([[User:Ericb|Ericb]] 16:15, 20 May 2006 (CEST))

==== salsound ====

==== salsys ====

==== saltimer ====

=== Sal GDI (everything Graphical Display Interface) ===

====salgdinativewidgets====

[[native controls]]

==== salatslayout ====

==> implemented in vcl/aqua/source/gdi/salatslayout.cxx

- Handle text layouting :

* Use ATSUI (ATSUCreateTextLayoutFromPtr) to layout the text unicode char buffer
* Use ATSUI (ATSU..) to get informations about glyphs
* Populate different arrays (mpGlyph2Chars, mpChars2Glyph, mpCharsWidths, mpGlyphAdvances)
that are used in various methods.

==== salatsuiutils ====

==== salfontutils ====

==== salmathutils ====

==== sal bmp ====

==== salvd ====

==== salpixmaputils====

==== salprn ====

====salrectangle====

==== salvd ====

=== Sal Window===

==== salframe ====
Documentation in progress, from damiend :
[[User:Damiend|Damiend page]]

====salobj====

== TO BE IMPLEMENTED (missing in Aqua)==

===Audio===

====audioconvert====
(obsolete?)

====devaudio====
(obsolete?)

====native sound====

====salimpsound====

====vsound====

===i18n===

===keysymnames===

===saldisp===

===sm===

[FIXME]: is session manager usefull?

=='''Native Controls'''==

====Scrollbar====

'''Works as expected'''. The most important work is done

See : [[Mac_OS_X_Porting_-_Native_Controls#ScrollBar]]

====DrawThemeButton() documentation====

'''Started'''

See : [[Mac_OS_X_Porting_-_Native_Controls#ComboBox]]

Started
<pre>
DrawThemeButton
Draws a button.

OSStatus DrawThemeButton (
const Rect * inBounds,
ThemeButtonKind inKind,
const ThemeButtonDrawInfo * inNewInfo,
const ThemeButtonDrawInfo * inPrevInfo,
ThemeEraseUPP inEraseProc,
ThemeButtonDrawUPP inLabelProc,
UInt32 inUserData
);
Parameters
inBounds
A pointer to a structure of type Rect. Pass a rectangle specifying the boundary of the button, in local coordinates.

inKind
A value of type ThemeButtonKind. Pass a constant specifying the type of button to draw.
See “Theme Buttons” for descriptions of possible values.

inNewInfo
A pointer to a structure of type ThemeButtonDrawInfo. Before calling DrawThemeButton,
set the structure to contain the new state, value, and adornment for the button.
DrawThemeButton uses the information passed in the inNewInfo and inPrevInfo parameters
to apply transitional animation or sound effects as the button state changes, if such are
specified under the current theme.

inPrevInfo
A pointer to a structure of type ThemeButtonDrawInfo. If the button state is changing,
set the structure to contain the previous state, value, and adornment for the button,
to allow DrawThemeButton to apply any transitional effects. If the button state is not
changing, you can pass NULL.

inEraseProc
A value of type ThemeEraseUPP. If you have a custom background, use this parameter to pass
a universal function pointer to an application-defined function such as that described in
ThemeEraseProcPtr. DrawThemeButton calls this function to erase the background before drawing
the button. If you pass NULL, DrawThemeButton's default behavior is to erase the background
for you.

inLabelProc
A value of type ThemeButtonDrawUPP. If you pass a universal function pointer to an
application-defined function such as that described in ThemeButtonDrawProcPtr, DrawThemeButton
calls that function to draw the label of the button. If you pass NULL, no label is drawn.

inUserData
An unsigned 32-bit integer. Provide any data to be passed in to the callback functions specified in
the inLabelProc and inEraseProc parameters. Pass NULL if you do not wish to provide any data.

Return Value
A result code. See “Appearance Manager Result Codes”.

Discussion
The DrawThemeButton function draws a theme-compliant button. If a ThemeEraseProcPtr is
specified in the inEraseProc parameter, DrawThemeButton uses that function to erase the
background of the button before drawing the button. After the button is drawn, if a
ThemeButtonDrawProcPtr is specified in the inLabelProc parameter, DrawThemeButton calls
that function to draw the button’s label.

Note that DrawThemeButton also draws any appearance adornments for the button and that these
can extend beyond the button’s basic bounding rectangle, as specified in the inBounds parameter,
and may be of variable shape. You may therefore wish to call the function
GetThemeButtonBackgroundBounds to obtain the actual rectangle containing the pixels belonging
to a button under the current theme.

Version Notes
This function is available with Appearance Manager 1.1 and later.

Availability
Available in CarbonLib 1.0 and later when Appearance 1.1 or later is present.
Available in Mac OS X 10.0 and later.
Declared In
Appearance.h
</pre>

====HIComboBoxCreate() documentation====

<pre>
HIComboBoxCreate
Creates a combo box control.

OSStatus HIComboBoxCreate (
const HIRect* boundsRect,
CFStringRef text,
const ControlFontStyleRec* style,
CFArrayRef list,
OptionBits inAttributes,
HIViewRef* outComboBox
);
Parameters
boundsRect
The bounding box of the control.

text
The default text in the editable portion of the control. Can be NULL.

style
The font style of the both editable text and the text in the disclosure list. Can be NULL.

list
The default values available in the disclosure list. Can be NULL.

inAttributes
The default attributes of the combo box. For possible values, see “Combo Box Attributes”.

outComboBox
On exit, a pointer to a reference for the new control.

Discussion
The combo box can be used in compositing mode, as well as traditional Control Manager mode.
When created, this view is invisible. To see the view, you must show the view by calling HIViewSetVisible.
</pre>

== What is used for Linux, Windows, Mac OS X ...build ? ==

'''[[Description of the dependencies]]'''

'''[[Windows]]'''

'''[[MacOS X]]'''

'''[[Linux]]'''

'''[[Solaris]]'''

== Content of Aqua ==

'''[[Click here to see the complete list]]'''

'''Content of vcl/inc'''

Notes:

1) Where to find includes

<foo/bar.hxx> means you can find bar.hxx in the foo module. The new style file is foo/inc/foo/bar.hxx, old style is foo/inc/bar.hxx and sometimes the file is somewhere else in the tree or generated. The deliver process copies/generates the file into solver at solver/680/build_type/inc/foo. Good for fixing broken builds. ;-)

2)
suffix .h (for C calls or first version?) or .hxx (C++)

'''A) Family of includes''':

Looking more closely at the list brings to the fore (expression from dictionary ;-) ) that include names are
informatives. Most of the time, the name gives the function/role.
What is interesting is the files with name begining with "sal". sal means System Abstraction Layer + include's function (or explicit name).

Partial list, for example:

salatype.hxx

salbmp.hxx

salctrlhandle.hxx

salctype.hxx

salframe.hxx

salgdi.hxx

salgeom.hxx

sallayout.hxx (main header for fonts services)
...
salmenu
salnativewidgets
...etc

Other important families are "sv" and "uno" or "win" (window) prefixed. sal family will be analysed apart.

'''B) Includes of includes'''

Some includes are more important than other. To prove this, just have a look is sufficient: some are always needed, and some more rarely.

To verify, a simple test to do in vcl/inc:

egrep -H "#include" ./* | wc -l gives me 681 lines ! And some of them are the same...

To know more, the precedent command line can be modified to make appear the numerous call
to the same includes files.

egrep -H "#include" ./* | cut -d"#" -f2 | sort > liste.txt

The content of liste.txt is explicit: dllapi.h, sv.h and some other are very important, while some other includes are only one or two times used. We can see too that vos includes are numerous, even if vos is deprecated**

**see http://wiki.services.openoffice.org/wiki/Source_code_directories

I'm nearly sure that a complete analysis of just this result will give us a lot of information.

I propose to change the order of analysis starting with dllapi.h and sv.h.

[to be continued]

'''B1) "sal" includes family'''

[[salinst.hxx]] This seems to be the main include file

[[salatype.hxx]]

[[salctrlhandle.hxx]]

[[salctype.hxx]]

[[salframe.hxx]]

[[salgdi.hxx]]

[[salgeom.hxx]]

'''[[ sallayout.hxx ]]''' <-- see Native Fonts implementation

[[salgtype.hxx]]

[[vcl/inc/salobj.hxx]]

'''B2) Classicals includes'''

file: abstdlg.hxx [ means abstract dialog ]

This includes does contain the following classes definitions:

[FIXME] : choose a precise presentation template for classes

VclAbstractDialog,

VclAbstractTerminateDialog,

VclAbstractRefreshableDialog,

VclAbstractDialogFactory,

uses <tools/solar.h> , <tools/string.hxx> +

"dllapi.h"

Note : dllapi.h is very interesting because when we have to find (for example) a library suffix, SAL_DLLEXTENSSION can replace all suffixes (every OS's and archs). Just including sal/config.h does it !

Classes:

Window -> what? [FIXME]
ResId -> what?

Does contain the prototype of VclAbstractDialog, inherit of VCL_DLLPUBLIC

file: dllapi.h [ dll for dynamic linked library ]
Uses: <sal/config.h> and >sal/types/h>
includes: VCL_DLLPUBLIC macro

file: accel.h [ means accelerator ]

Classes:

Accelerator
{
}
ImplAccelEntry
{
public members:

Names

mnId
maKeyCode
mpAccel
mpAutoAccel
mbEnabled
}

function / returns / parameters

ImplGetKeyCode / void / KeyFuncType eFunc, ref rCode1 , ref rCode2, ref rCode3

file: accel.hxx

Uses: <sv.h> , "dllapi.h" ,<tools/resid.hxx>, <<tools/rc.hxx>

Classes:

ImplAccelData;
ImplAccelEntry;

== Important Links ==
'''[[Progressive implementation]]'''

'''Native Font server Implementation''' '''[[Mac OS X Porting - Native Fonts]]'''

'''Native Sound Implementation''': [[Mac OS X Porting - Native Audio and Video]]

'''Native Printing Implementation''': [[Mac OS X Porting - Native_Printing]]

'''Drag and Drop implementation''': [[Mac OS X Porting - Native Drag and drop]]

'''Data Acquisition''' : [[Mac OS X Porting - Data Acquisition]]

This work is part of http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s

[to be continued:-) ]

== Keyboard comparizon between OpenOffice.org / Mac OS X application ==

[FIXME] redo a cleanest array

{| style="vertical-align:top; text-align:centered; background-color:#F0F0F0;"
|- style="background-color:#99CCFF; font-weight:bold;"
| Modifier||+ key || Result || TextEdit returns
|-
|ALT|| a||æ ||æ
|-
|ALT||b||ß ||ß
|-
|ALT||c||© ||©
|-
|ALT||d||∂ ||∂
|-
|ALT||e||ê ||ê
|-
|ALT||f||ƒ ||ƒ
|-
|ALT||g ||ﬁ ||ﬁ
|-
|ALT||h ||Ì ||Ì
|-
|ALT||i ||î ||î
|-
|ALT||j ||Ï ||Ï
|-
|ALT||k ||È ||È
|-
|ALT||l ||¬ ||¬
|-
|ALT||m ||µ ||µ
|-
|ALT||n ||~ ||~
|-
|ALT||o ||œ ||œ
|-
|ALT||p ||π ||π
|-
|ALT||q ||‡ ||‡
|-
|ALT||r ||® ||®
|-
|ALT||s ||Ò ||Ò
|-
|ALT||t ||† ||†
|-
|ALT||u ||º ||º
|-
|ALT||v ||◊ ||◊
|-
|ALT||w ||‹ ||‹
|-
|ALT||x ||≈ ||≈
|-
|ALT||y ||Ú ||Ú
|-
|ALT||z ||Â ||Â
|-
|ALT||A ||Æ ||Æ
|-
|ALT||B ||∫ ||∫
|-
|ALT||C ||¢ ||¢
|-
|ALT||D||∆||∆
|-
|ALT||F ||· ||·
|-
|ALT||G ||ﬂ ||ﬂ
|-
|ALT||H ||Î ||Î
|-
|ALT||I ||Î ||Î
|-
|ALT||J ||Í ||Í
|-
|ALT||K ||Ë ||Ë
|-
|ALT||L || <pre>|</pre> ||<pre>|</pre>
|-
|ALT||M ||Ó ||Ó
|-
|ALT||N ||ı ||ı
|-
|ALT||O ||Œ ||Œ
|-
|ALT||P ||∏ ||∏
|-
|ALT||Q ||Ω ||Ω
|-
|ALT||R ||‚ ||‚
|-
|ALT||S ||∑ ||∑
|-
|ALT||T ||™ ||™
|-
|ALT||U ||ª ||ª
|-
|ALT||V ||√ ||√
|-
|ALT||W ||› ||›
|-
|ALT||X ||⁄ ||⁄
|-
|ALT||Y ||Ÿ ||Ÿ
|-
|ALT||Z ||Å ||Å
|-
|ALT||$ ||€ ||€
|-
|ALT||` ||@ ||@
|-
|ALT||£ ||# ||#
|-
|ALT||* ||¥ ||¥
|}

Sous réserve d'erreur ou omission [[User:Ericb|Ericb]] 00:05, 14 January 2007 (CET)

--[[User:Ericb|Ericb]] 15:00, 22 Jul 2005 (EDT)

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-03-15T04:51:51Z

Plipli: /* HIView use in AquaSalFrame::CreateNewSystemWindow() */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

HI* events definitions in aquavclevents.hxx

Event handler implementation in HandleHIViewEvent()

The use of HandleHIViewEvent() in AquaSalFrame::CreateNewSystemWindow()

The use of HI* controls, in vcl, when ::CreateNewSystemWindow() is used, calling HandleHIViewEvent(), when HI* events are detected in the frame.

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== VCL / AQUA traces deductions (plipli) ==
1)

== VCL / AQUA traces deductions (ericb) ==
1)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mrContentView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mrContentView);

// make the view visible
HIViewSetVisible (mrContentView, true);

// set the frame
HIViewSetFrame (mrContentView, &myViewRect);

// Activate content view and children
HIViewSetActivated (mrContentView,true);

</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-03-15T04:50:42Z

Plipli: /* Controls */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

HI* events definitions in aquavclevents.hxx

Event handler implementation in HandleHIViewEvent()

The use of HandleHIViewEvent() in AquaSalFrame::CreateNewSystemWindow()

The use of HI* controls, in vcl, when ::CreateNewSystemWindow() is used, calling HandleHIViewEvent(), when HI* events are detected in the frame.

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== VCL / AQUA traces deductions (plipli) ==
1)

== VCL / AQUA traces deductions (ericb) ==
1)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mhView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mhView);

// make the view visible
HIViewSetVisible (mhView, true);

// set the frame
HIViewSetFrame (mhView, &myViewRect);
</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);

HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);

HIViewSetNeedsDisplay (myCombo, true);

printf ("rc2.origin.x %.0f \n rc2.origin.y %.0f \n rc2.size.width %.0f \n rc2.size.height %.0f \n",
rc2.origin.x, rc2.origin.y, rc2.size.width , rc2.size.height );

//HIViewSetActivated (myCombo,true);

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-03-14T19:16:17Z

Plipli: /* VCL traces deductions (plipli) */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

HI* events definitions in aquavclevents.hxx

Event handler implementation in HandleHIViewEvent()

The use of HandleHIViewEvent() in AquaSalFrame::CreateNewSystemWindow()

The use of HI* controls, in vcl, when ::CreateNewSystemWindow() is used, calling HandleHIViewEvent(), when HI* events are detected in the frame.

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== VCL / AQUA traces deductions (plipli) ==
1)

== VCL / AQUA traces deductions (ericb) ==
1)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mhView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mhView);

// make the view visible
HIViewSetVisible (mhView, true);

// set the frame
HIViewSetFrame (mhView, &myViewRect);
</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

if( BeginGraphics() )
{
HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);
HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);
HIViewSetNeedsDisplay (myCombo, true);

EndGraphics();
return true;
}

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-03-14T19:16:01Z

Plipli: /* VCL traces deductions (plipli) */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

HI* events definitions in aquavclevents.hxx

Event handler implementation in HandleHIViewEvent()

The use of HandleHIViewEvent() in AquaSalFrame::CreateNewSystemWindow()

The use of HI* controls, in vcl, when ::CreateNewSystemWindow() is used, calling HandleHIViewEvent(), when HI* events are detected in the frame.

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== VCL traces deductions (plipli) ==
1)

== VCL / AQUA traces deductions (ericb) ==
1)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mhView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mhView);

// make the view visible
HIViewSetVisible (mhView, true);

// set the frame
HIViewSetFrame (mhView, &myViewRect);
</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

if( BeginGraphics() )
{
HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);
HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);
HIViewSetNeedsDisplay (myCombo, true);

EndGraphics();
return true;
}

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-03-14T19:15:10Z

Plipli: /* Technical principles */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

HI* events definitions in aquavclevents.hxx

Event handler implementation in HandleHIViewEvent()

The use of HandleHIViewEvent() in AquaSalFrame::CreateNewSystemWindow()

The use of HI* controls, in vcl, when ::CreateNewSystemWindow() is used, calling HandleHIViewEvent(), when HI* events are detected in the frame.

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== VCL traces deductions (plipli) ==
1)

== VCL traces deductions (plipli) ==
1)

== Technical principles ==

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mhView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mhView);

// make the view visible
HIViewSetVisible (mhView, true);

// set the frame
HIViewSetFrame (mhView, &myViewRect);
</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

if( BeginGraphics() )
{
HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);
HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);
HIViewSetNeedsDisplay (myCombo, true);

EndGraphics();
return true;
}

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

Build a big toy with all controls included : [http://developer.apple.com/samplecode/AppearanceSampleUpdated/listing575.html All controls + code around]

High Level Toolbox, HIServices Release Notes : [http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/ HIToolbox]

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-03-13T21:08:16Z

Plipli: /* Technical principles */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

HI* events definitions in aquavclevents.hxx

Event handler implementation in HandleHIViewEvent()

The use of HandleHIViewEvent() in AquaSalFrame::CreateNewSystemWindow()

The use of HI* controls, in vcl, when ::CreateNewSystemWindow() is used, calling HandleHIViewEvent(), when HI* events are detected in the frame.

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== Technical principles ==

(plipli->ericb:to correct, if I m wrong...)

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or context from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quartz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mhView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mhView);

// make the view visible
HIViewSetVisible (mhView, true);

// set the frame
HIViewSetFrame (mhView, &myViewRect);
</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

if( BeginGraphics() )
{
HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);
HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);
HIViewSetNeedsDisplay (myCombo, true);

EndGraphics();
return true;
}

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

High Level Toolbox, HIServices Release Notes : http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

Mac OS X Implementing HIView

2007-03-13T21:04:42Z

Plipli: /* Current code implementation */

== Contributors ==

Eric Bachard[[http://wiki.services.openoffice.org/wiki/User:Ericb ericb]]

Sébastien Plisson [[http://wiki.services.openoffice.org/wiki/User:Plipli plipli]]

== Introduction ==

'''[DRAFT] : means, not yet working, work in progress ... '''

HIObject is a common base class for all user interface objects and all menus, windows, controls, toolbars, and so on, are subclasses of HIObject.

HIView is an object-oriented view system subclassed from HIObject. All controls are implemented as HIView objects ("views"). You can easily subclass HIView classes, making it easy to implement custom controls. Over time the HIView API will replace the current Control Manager. See [[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html HIView intro]]

The main idea behind HIView is to superpose plans, to create any view, using compositing possibilities of Quartz Graphical Engine.

The final result is the superposition of all plans, following simple rules like :

- The last plan is always drawn on the previous one ;
- Some plans can be declared visible, or not, very easely.

This page is part of [[http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls Implementation]] and the objective is to use HIView for HIComboboxes or other HI* controls.

Our objective is to bind vcl controls with HI* controls, from Carbon API.

e.g. : implement HICombobox as one control only.

The generic implementation, under tests (and not fully working), uses :

HI* events definitions in aquavclevents.hxx

Event handler implementation in HandleHIViewEvent()

The use of HandleHIViewEvent() in AquaSalFrame::CreateNewSystemWindow()

The use of HI* controls, in vcl, when ::CreateNewSystemWindow() is used, calling HandleHIViewEvent(), when HI* events are detected in the frame.

Note : we "or"- ed kWindowCompositingAttribute in nWindowAttributes, to see compositing effects.
[FIXME] : investigate, because use this attribute causes refresh issues

== Technical principles ==
(to correct, if I m wrong...)

1) OO ask to VCL / native implementation code to draw controls (ie DrawNativeControl) or images or text

2) For controls, native implementation code create objects but do not draw them
For images and text, native code draw objects to context (from QDBegin) or contect from HiView event

3) When HIView events are received by event handler, especially kEventControlDraw, native code should draw controls to context given by the event

4) Native code call needsDisplay functions to tell Quatrz which zone to update

== Current code implementation==

===Events for HIView ===

Two sorts of events are needed:

*for objects (ClasskEventClassHIObject ) :

<pre>kEventHIObjectConstruct

kEventHIObjectInitialize

kEventHIObjectDestruct</pre>

*for controls themselves ( Class kEventClassControl ) :

<pre>kEventControlDraw

kEventControlInitialize

kEventControlHitTest

kEventControlGetPartRegion

</pre>

Current implementation : see vcl/aqua/aquavclevents.hxx for more informations about the syntax.

===Install Event Handler ===

Now we have to install event Handler, inside AquaSalFrame::CreateNewSystemWindow() :
<pre>

InstallEventHandler (
GetControlEventTarget (mhView),
NewEventHandlerUPP (HandleHIViewEvent),
GetEventTypeCount (cHIViewEvent),
cHIViewEvent,
(void*)mhView, // note the use of the pointer
NULL
);

</pre>

=== The HI* Event Handler ===

The Handler is OSStatus type, and is used when events are detected.

e.g. : we created HandleHIViewEvent()

using GetEventParameter, itself using the parameters described in Apple documentation.

Code sample :
<pre>
OSStatus HandleHIViewEvent(EventHandlerCallRef inHandlerCallRef, EventRef inEvent, void* inUserData)
{
//lock
ImplSalYieldMutexAcquire();

OSStatus status = noErr;

// we use mrContext, global and seen from everywhere
CGContextRef mrContext;

// create HIRect, contianing the control bounds ( in local coordinates)
HIRect bounds;

status = GetEventParameter (inEvent,
kEventParamCGContextRef,
typeCGContextRef,
NULL,
sizeof (CGContextRef),
NULL,
&mrContext);

// not used, but usefull
//require_noerr(status, CantGetGraphicsContext); // 2

// We need to know the bounds containing the current control
HIViewGetBounds ((HIViewRef) inUserData, &bounds);

// not used, but usefull
//require_noerr(status, CantGetBoundingRectangle);

// unlock
ImplSalYieldMutexRelease();

return status;
}
</pre>

===HIView use in AquaSalFrame::CreateNewSystemWindow() ===

Code sample :

<pre>

// TEST HIVIew part
// Set mhView with HIView Content ViewRef

HIRect myViewRect;
myViewRect.origin.x = aContentRect.left;
myViewRect.origin.y = aContentRect.right;
myViewRect.size.width = aContentRect.right-aContentRect.left;
myViewRect.size.height = aContentRect.bottom-aContentRect.top;
OSStatus errval;
errval = HIViewFindByID(HIViewGetRoot(mrWindow), kHIViewWindowContentID, &mhView);

// make the view visible
HIViewSetVisible (mhView, true);

// set the frame
HIViewSetFrame (mhView, &myViewRect);
</pre>

=== Controls ===

[FIXME]

Example : HICombobox

-> code located in vcl/aqua/source/gdi/salnativewidgets.cxx , where all NWF are defined

1) declare CTRL_COMBOBOX control as "true" in isNativeControlSupported()

2) get the control region in getNativeControlRegion()

3) add CTRL_COMBOBOX case in drawNativeControl()

Code sample for the last part (Warning : not yet working !! ) :

<pre>
switch( nType )
{

case CTRL_COMBOBOX:
if ( ( nPart==PART_BUTTON_DOWN) || (nPart==PART_SUB_EDIT) || (nPart==PART_ENTIRE_CONTROL) || (nPart==HAS_BACKGROUND_TEXTURE))

.... (other code )

if( BeginGraphics() )
{
HIViewRef myCombo;

HIRect rc2;

rc2.origin.x = rControlRegion.GetBoundRect().Left();
rc2.origin.y = rControlRegion.GetBoundRect().Top();
rc2.size.width = rControlRegion.GetBoundRect().GetWidth();
rc2.size.height = rControlRegion.GetBoundRect().GetHeight();

HIComboBoxCreate ( &rc2 , NULL, NULL, NULL, kHIComboBoxStandardAttributes, &myCombo);
HIViewSetVisible ( myCombo, true);
HIViewAddSubview (mrView, myCombo);
HIViewSetNeedsDisplay (myCombo, true);

EndGraphics();
return true;
}

..... (other code )
</pre>

== Usefull Links ==

=== References ===

[[http://developer.apple.com/documentation/Carbon/Conceptual/HandlingWindowsControls/hitb-wind_cont_tasks/chapter_3_section_9.html Introducing HIView]]

OverView : [[http://developer.apple.com/carbon/HIToolbox_feature.html HIToolbox]]

HIVIew : [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/Reference/reference.html reference]] [[http://developer.apple.com/documentation/Carbon/Reference/HIViewReference/HIViewReference.pdf or .pdf format]]

[[http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/index.html Upgrading to HIToolbox]]

===Code sample ===

High Level Toolbox, HIServices Release Notes : http://developer.apple.com/releasenotes/Carbon/RN-HIToolbox/

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]

DomainDeveloper

2007-02-22T18:27:38Z

Plipli: /* Developers */

A mapping of names to OOo accounts.

Abbrev.:

* PL : Project Lead
* CL : Project Co-Lead
* CC : Community Council Member
* ESC : Engineering Steering Committee Member
* CVS : has write access to the OOo CVS repository

----

=== Developers ===

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Name || CVS || @openoffice.org || [[IRC Communication]] || Notes || Affiliation
|-
| || || || || ||
|-
| Volker Ahrendt|| X || va||||||Sun Microsystems
|-
| Kai Ahrens|| X || ka || Kai_Ahrens ||PL Graphic Applications||Sun Microsystems
|-
| Gene Anaya|| || ganaya||||||
|-
| Joost Andrae|| X || ja||ja||CL qa, release testing en-US builds and releasing builds||Sun Microsystems
|-
| Eric Bachard|| X || ericb||ericb2|| CL porting Mac OSX/Linux PPC port ||French OO.o project
|-
| Kai Backman|| || kaib ||KaiB||||
|-
| Sascha Ballach|| X || sab||||||
|-
| Jayant Balraj Madavi|| || jayant_madavi||aZEN_JM||Connectivity / Database||Novell, Inc.
|-
| Jörg Barfurth|| X || jb||JoergB||Configuration Util||Sun Microsystems
|-
| Mathias Bauer|| X || mba||||PL Writer, CL Framework, XML||Sun Microsystems
|-
| Thorsten Behrens|| X || thb||thorsten||vcl/impress/toolkit visionary||Sun Microsystems
|-
| Thomas Benisch|| X || tbe||||Scripting framework||Sun Microsystems
|-
| Stephan Bergmann|| X || sb||||CL UDK||Sun Microsystems
|-
| Andreas Bille|| X || abi||||||Sun Microsystems
|-
| Éric Bischoff|| X || ebischoff||ebischoff||KDE A/B driver||Bureau Cornavin
|-
| Nick Blievers|| X || nick||||IRIX||
|-
| Daniel Boelzle|| X || dbo||||UNO core/bridges/packages||Sun Microsystems
|-
| Oliver Bolte|| X || obo||||RE||Sun Microsystems
|-
| Rafaella Braconi|| || coni||||CL l10n, globalization program manager||Sun Microsystems
|-
| Michael Brauer|| X || mib||||PL XML||Sun Microsystems
|-
| Oliver Braun|| X || obr||obr||System Integration/Accessibility Hacker||Sun Microsystems
|-
| Andreas Bregas|| X || ab||||StarBasic||Sun Microsystems
|-
| Jörg Brunsmann|| || jbrunsmann||||UDK||
|-
| Jörg Budischewski|| || jbu||PyUNO hacker||||Sun Microsystems
|-
| Peter Burow|| X || pb||UI||||Sun Microsystems
|-
| Aidan Butler|| || aidan||||XML filters||
|-
| Giuseppe Castagno || X || beppec56 || beppec56_ or beppe_c || PDF output
|-
| [[User:ScottCarr|Scott Carr]] || X || kcarr||kcarr||PL Documentation||Progbits
|-
| Colin Charles|| || drbyte||bytee||Malaysian native-lang project||bytebot.net
|-
| Behrend Cornelius|| X || bc||||Wizards||Sun Microsystems
|-
| Michael Cziebalski|| || mci||||||
|-
| [[User:pdefilippis|Pierre de Filippis]]|| X || pdefilippis||aliscafo||Mac OSX native porting||
|-
| Andrew Dent|| X ||ace_dent||ace_dent||ui/custom_images||
|-
| Naren Devaiah|| || ||ndev||Performance||Intel Corporation
|-
| Nitin Dongre|| || ||nitin_BITS||||Novell, Inc.(intern)
|-
| Radek Doulik|| || radekdoulik||rodo_||Canvas hacker||Novell, Inc.
|-
| Carsten Driesner|| X || cd|| cd_oo ||PL Framework||Sun Microsystems
|-
| Herbert Duerr|| X || hdu||hdu_hh||GSL||Sun Microsystems
|-
| Oliver Düsterhoff|| X || od||Writer||||Sun Microsystems
|-
| Bernd Eilers|| X || bei||rfc821||EIS||Sun Microsystems
|-
| René Engelhard|| X || rene||_rene_||config_office, Debian packager||Debian
|-
| Andre Fischer|| X || af||||Impress||Sun Microsystems
|-
| Uwe Fischer || || ufi || || || Sun Microsystems
|-
| Ken Foskey|| || waratah||waratah||config_office/dmake man||slug.org.au
|-
| Duncan Foster|| || dfoster||||||
|-
| David Fraser|| || davidfraser||davidfraser||South African translations, multilingual builds||translate.org.za
|-
| Nils Fuhrmann|| || nf||||Localization||Sun Microsystems
|-
| Martin Gallwey|| X || mtg||marty_||XML/Writer/packaging||
|-
| Pierre-Andre Galmes || || pagalmes || pagalmes || Chart2 ||StarXpert
|-
| Tony Galmiche|| X || tonygalmiche||||CL FR native-lang project||
|-
| Sunil Gandhi|| || ||tyro||||NOSIP
|-
| Sophie Gautier|| X || sgauti|| sophi ||PL FR native-lang project, CC ||.
|-
| Vladimir Glazounov|| X || vg||||RE||Sun Microsystems
|-
| Laurent Godard || X || laurentgodard || lgodard || CC, PL Extensions, Fr Native-lang Project || inDesko/Nuxeo
|-
| Jody Goldberg|| X || jodygoldberg||jody||[[Calc]] spreadsheet-ness||Novell, Inc.
|-
| Dirk Grobler|| X || dg||||Database Access||Sun Microsystems
|-
| [[User:Sg|Steffen Grund]]|| X || sg|| || NetBeans Integration ||Sun Microsystems
|-
| Bettina Haberer|| || bh||||RFEOwner||Sun Microsystems
|-
| Ingrid Halama|| X || iha||||Chart||Sun Microsystems
|-
| Chris Halls|| X || haggai||haggai||Debian packager&misc. hacker||Credativ Ltd., Debian
|-
| Gregor Hartmann|| X || gh|| Lachs ||Testtool||Sun Microsystems
|-
| Bustamam Harun|| || bustamam||||Malaysian stuff||
|-
| Kevin Hendricks|| X || khendricks||||PL Lingucomponent, PowerPC||
|-
| Con Hennessy|| || cphennessy||cph2 or cph_||hacker & former council person||OpenApp
|-
| Ivo Hinkelmann|| X || ihi||ivo||l10n tooling/general/RE||Sun Microsystems
|-
| Eric Hoch|| X || maveric||mav_eric||Mac Porting||
|-
| [[User:Lutz_Hoeger|Lutz Hoeger]]|| X || lh ||lutzh||PL [http://ux.openoffice.org User Experience]||Sun Microsystems
|-
| Jan Holešovský|| X || kendy||kendy||KDE integration||Novell, Inc.
|-
| Martin Hollmichel|| X || mh||Ratte/Nesshof||Build Maestro, PL External, Tools, Porting, CC||Sun Microsystems
|-
| Karl Hong|| X || khong||||i18n, CJK expert||Sun Microsystems
|-
| Matthias Huetsch|| X || mhu||||Performance/strategy, PL UCB, CC, ESC||Sun Microsystems
|-
| Michael Hönnig|| X || mi||||PL API||
|-
| [[User:icobgr|Hristo Hristov]] || || icobgr || icobgr || PL Bulgarian native-lang project ||
|-
| Sven Jacobi|| X || sj||||Escherwizard||Sun Microsystems
|-
| Jörg Jahnke|| || jj||||Internal tooling||Sun Microsystems
|-
| Christian Jansen|| || cj ||||Menu and Toolbar?||Sun Microsystems
|-
| Ocke Janssen|| X || oj||Base||||Sun Microsystems
|-
| Pavel Janík|| X || pjanik||paveljanik||PL Czech native-lang project, CL l10n, CC, ESC, l10n builds||
|-
| Berry Jia|| X || berryjia||||||Sun Microsystems
|-
| Pascal Junck|| || pjunck||||||Sun Microsystems
|-
| [[User:pj@openoffice.org|Peter Junge]]|| X || pj|| peter13j|| OOo community contact for my Chinese Employer, QA||Beijing Redflag CH2000
|-
| Christian Junker|| || Cyb||christianju||API||Trees For Life
|-
| Hirano Kazunari|| || khirano||||Japanese||
|-
| Dhananjay Keskar|| X || dkeskar ||dkeskar||Performance,Buildbot,cat-herder||Intel Corporation
|-
| Robert Kinsella|| || rkinsella||||||Sun Microsystems
|-
| Volodymyr Khrystynych|| || volody||||XML Filter||
|-
| Matthias Klose|| || doko||doko||Ubuntu, gcc, python packager||Canonical, Inc.
|-
| Laszlo Kovacs|| || lkovacs||||Documentation||
|-
| Martin Kretzschmar|| X || mkretzschmar||martink||Gnome / Debian||Student
|-
| Will Lachance|| || wlach||wlach_||Word Perfect File Filters||Net Integration Technologies, Inc.
|-
| Thomas Lange|| X || tl||||||Sun Microsystems
|-
| Lars Langhans|| X || lla||||||Sun Microsystems
|-
| Hans-Joachim Lankenau|| X || hjs||ause||dmake makefile expert, RE||Sun Microsystems
|-
| Németh László|| X || nemeth||||PL lingucomponent||
|-
| Jakob Lechner|| X || jakob_lechner||||Writer||Fabalabs
|-
| Michael Leibowitz|| X || mikeleib ||mikeleib||performance||Intel Corporation
|-
| Wind Li|| X || windly||||Address books||
|-
| Ping Liao|| || pliao||||||
|-
| Tor Lillqvist|| X || tml||tml_||||Novell, Inc.
|-
| Joachim Lingner|| X || jl||||Java, CLI||Sun Microsystems
|-
| Christian Lippka|| X || cl||ChristianL||Graphic Applications||Sun Microsystems
|-
| Mindy Liu|| || mindyliu||||||
|-
| [[User:Dl|Dieter Loeschky]]|| X || dl ||||PL: ODF Toolkit||Sun Microsystems
|-
| Philipp Lohmann|| X || pl||pl_hh||VCL/X11 (GSL) hacker||Sun Microsystems
|-
| Jackson Low|| X || xxjack12xx||||Porting||
|-
| Patrick Luby|| || pluby||||Mac||
|-
| Prasad Madhav || X || pmadhav || pmadhav || Buildbot || Intern@Intel
|-
| Babak Mahbod|| || bmahbod||||||
|-
| Martin Maher|| || mmaher||||Writer & Filter chap||
|-
| Nakata Maho|| X || maho||_maho_||PL QA, FreeBSD guy||Independent
|-
| John Marmion|| X || jmarmion||||||
|-
| Andreas Martens|| X || ama||||PL Writer||Sun Microsystems
|-
| [[User:smsm1|Shaun McDonald]] || X || smsm1 || shaunmcdonald || Mac Port, buildbot MacPort1 || Student
|-
| Caolán McNamara|| X || cmc||caolan||CL Writer & Filter man||RedHat, Inc.
|-
| Michael Meeks|| X || mmeeks||michael_||ugly hack-er, ESC||Novell, Inc.
|-
| Frank Meies|| X || fme||||Writer||Sun Microsystems
|-
| Federico Mena-Quintero|| || federicomena||federico||perfectionist||Novell, Inc.
|-
| Ismael Merzaq|| X || isma87||ismael_||Mac OSX native porting||Student
|-
| Michael Mi|| || mmi||||||
|-
| Björn Milcke|| X || bm||bm_||Chart||Sun Microsystems
|-
| Petr Mladek|| || pmladek||pmladek||SUSE RPMs, ooo-build releases||Novell, Inc.
|-
| Cyrille Moureaux|| X || cyrillem||Cyrille||||Sun Microsystems
|-
| [[User:Mmp|Matthias Müller-Prove]]|| X || mmp|| mprove|| CL [[User Experience]], http://ux.openoffice.org || Sun Microsystems
|-
| Niklas Nebel|| X || nn||||PL [[Calc]]||Sun Microsystems
|-
| Christoph Neumann|| X || cn||||API tests||Sun Microsystems
|-
| NicelKM|| X || mnicel||nicel||||Novell, Inc.
|-
| Bertram Nolte|| || bnolte||||||
|-
| Tomas O'Connor|| || toconnor||||Scripting Framework||
|-
| Lars Oppermann|| X || lo||||||Sun Microsystems
|-
| Rodrigo Parra Novo|| X || rodarvus||rodarvus||Gnumeric/Abiword OpenDocument Format support and port to Maemo||INdT (Instituto Nokia de Tecnologia)
|-
| Edward Peterlin|| X || OPENSTEP||||Mac||
|-
| Frank Peters|| X || fpe||||Documentation||Sun Microsystems
|-
| Christof Pintaske|| X || cp||||||Sun Microsystems
|-
| Ron Piterman|| || rpiterman||||||
|-
| Sebastien Plisson|| X || plipli||plipli||Developer on Aqua port||OO Aqua Port
|-
| Noel Power|| || npower||noelp||VBA Interop, Scripting||Novell, Inc.
|-
| Nikolai Pretzell|| X || np || ||Autodoc, code quality||Sun Microsystems
|-
| Volker Quetschke|| X || vq||vq||W32-tcsh/bash build environment and dmake Hacker, ESC||Gravity Waves
|-
| Tino Rachui|| X || tra||tinor||GSL/Unix Hacker||Sun Microsystems
|-
| [[User:Kr|Kay Ramme]]|| X || kr||||PL UDK||Sun Microsystems
|-
| [[User:ErAck|Eike Rathke]]|| X || er||erAck||CL [[Calc]], engine; CL i18n; stricken with number formatter||Sun Microsystems
|-
| Michael Rauch|| X || mrauch||||NetBSD||
|-
| Jens-Heiner Rechtien|| X || hr||blauwal||RE; OOo SCM (CVS, CWS tooling); Porting; Compilers||Sun Microsystems
|-
| Daniel Rentz|| X || dr||||[[Calc]] Excel filter, UI||Sun Microsystems
|-
| Florian Reuter|| X || flr||||Writer filters||Novell, Inc.
|-
| Georg Richter|| X || grichter||georg||Base, native MySQL driver||MySQL AB
|-
| G. Roderick Singleton|| || grsingleton||grsingleton||Documentation||pathtech.org
|-
| Hennes Rohling|| X || hro||||GSL & Util||Sun Microsystems
|-
| Bibek Sahu|| || Bibek||bibek||Impress pieces||Trees For Life
|-
| Andreas Schlüns|| X || as||||Framework||Sun Microsystems
|-
| Ingo Schmidt|| X || is||||(Native) Installation||Sun Microsystems
|-
| [[User:Jsc|Jürgen Schmidt]]|| X || jsc||jsc||PL API, CL Extensions, UNO, SDK||Sun Microsystems
|-
| Stephan Schäfer|| X || ssa||ssa||VCL||Sun Microsystems
|-
| Frank Schönheit|| X || fs||FrankS||Database Access, Forms||Sun Microsystems
|-
| Julian Seward || || sewardj || || valgrind ||
|-
| Darragh Sherwin|| || dsherwin||darragh||E-Legislation / E-GovSystems||Propylon
|-
| Raul Siddhartha|| || rsiddhartha||raul||GTK File Selector||Novell, Inc.
|-
| Sarah Smith|| || ssmith||||||
|-
| [[User:mox|Mox Soini]] || X || mox || Moxed || Mac Porting ||
|-
| Rajesh Sola|| || rajeshsola||sola||misc.||NOSIP
|-
| Kai Sommerfeld|| X || kso||||manager & hacker||Sun Microsystems
|-
| Oliver Specht|| X || os||||PL UI||Sun Microsystems
|-
| Jörg Spindler|| || jspindler||||||
|-
| Fridrich Štrba|| X || fridrich_strba||Fridrich||Word Perfect Hacker||
|-
| Ulf Stroehler|| || us||||||Sun Microsystems
|-
| Muthu Subramanian|| || muthusuba||muthusuba||misc.||
|-
| Louis Suárez-Potts|| || louis||louis||Community Manager||Collab.net
|-
| Claus Sørensen|| || cs||c26n,cHBs,chbs||Danish Localization and Project Management Tool(oopm)||ProFOSS
|-
| Stefan Taxhet|| X || st||stx12||CC, interpersonal problem fixer||Sun Microsystems
|-
| Armin Theissen|| || armin||||||
|-
| Caio Tiago Oliveira|| X || asrail||asrail||CL QA, release testing pt-BR builds||Independent
|-
| Jan Tietjens|| || tietjens||||||
|-
| Rüdiger Timm|| X || rt|| rtimm ||RE||Sun Microsystems
|-
| Malte Timmermann|| X || mt||||||Sun Microsystems
|-
| Gerhard Tonn|| || tonn||||s390||
|-
| Willem van Dorp|| || willem.vandorp||||||
|-
| Tom Verbeek|| X || tv||||Wizards, Art team||Sun Microsystems
|-
| Sander Vesik|| || svesik||||||
|-
| Daniel Vogelheim|| X || dvo||||XML||
|-
| Mikhail Voitenko|| X || mav||Framework||||Sun Microsystems
|-
| Robert Vojta|| X || rvojta||rvojta||VBA Interop||
|-
| Dirk Völzke|| X || dv||||Installation||Sun Microsystems
|-
| [[User:Sparcmoz|Jim Watson]]|| X || sparcmoz|| sparcmoz||GNU Linux sparc porter||clug.org.au
|-
| Armin Weiss|| X || aw||||||Sun Microsystems
|-
| Dan Williams|| X || fa||dcbw||Mac et. al. hacker||RedHat, Inc.
|-
| Stephan Wunderlich|| X || sw||||||
|-
| Kohei Yoshida|| X || kohei||kohei_||[[Calc]] hacker, Calc optimization solver developer||SlickEdit, Inc.
|-
| George Zahopoulos|| X || georgez||||||
|-
| Kurt Zenker|| X || kz||smoketester||RE||Sun Microsystems
|-
| Claudio F Filho|| || filhocf||filhocf||Brazilian portuguese Localization||BrOffice.org
|-
| Xiaoyang Yu|| || || ||Disk block reordering||Intel Corporation
|-
| Antonio Xu|| X || antoxu || antoxu || Async dialogs, PRC improvements || Intel Corporation
|-
| Rail Aliev || X || rail || rail || Ru and Tr NL Co-lead || Infra-Resource
|-
| Jeremy Zheng|| X || zhiming || Jeremy || Async dialogs, PRC improvements || Intel Corporation
|-
| [[User:Schmidtm|Matthias Schmidt]] || || schmidtm || schmidtm || Mac OSX Aqua Port || Sun Microsystems
|-
| Yuri Dario || || ydario || Paperino || OS/2 Port || Serenity Systems intl
|-
| Wei Zhao || || weiz || || Chinese Localization || Beijing Redflag CH2000
|-
| Liu Tao || || liutao || || PyUNO, Async dialogs|| Beijing Redflag CH2000
|-
| JiangChuang || || jiangc || || || Beijing Redflag CH2000
|-
| Lv Xugang || || lvxg || || || Beijing Redflag CH2000
|-
| Chen Jinhong || || chainchen || || || Beijing Redflag CH2000
|-
| Li Yuan || || liyuan || || PyUNO, Async dialogs || Beijing Redflag CH2000
|-
| Wu Yan || || youngwoo || || || Beijing Redflag CH2000
|-

|}

=== QA Engineers ===

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Name ||CVS||@openoffice.org || [[IRC Communication]] || Interested modules || Notes || Affiliation
|-
| Stefan Baltzer||||sba||||writer||||Sun Microsystems
|-
| Thorsten Bosbach||X||tbo||||framework, qa/qatesttool||QA Framework / Automation||Sun Microsystems
|-
| Oliver Craemer||X||oc||||[[Calc]]||QA Calc / Automation||Sun Microsystems
|-
| Helge Delfs||X||hde||||writer, qa/qatesttool||QA Writer / Automation||Sun Microsystems
|-
| Fredrik Haegg||X||fha||||draw, impress, qa/qatesttool||QA Graphics / Automation||Sun Microsystems
|-
| Hasan Ilter||||hi||||writer, printing, pdf export||||Sun Microsystems
|-
| Michael Rüß||||mru||||writer, word im/export||||Sun Microsystems
|-
| Éric Savary||||es||||writer, accessibility||||Sun Microsystems
|-
| [[User:jsi|Joerg Sievers]]||X||jsi||jogi||qa/qatesttool, [[Calc]]||Automation / QA Calc||Sun Microsystems
|-
| Joerg Skottke||X||jsk||skotti||framework, qa/qatesttool||QA Framework / Automation||Sun Microsystems
|-
| Marc Neumann||X||msc||||database, qa/qatesttool||QA Base / Automation||Sun Microsystems
|-
| Chris Lukasiak||||clu||||database||||Sun Microsystems
|-
| Frank Stecher||||fst||||[[Calc]]||||Sun Microsystems
|-
| Jack Warchold|||| jw||||writer, import/export filters||||Sun Microsystems
|-
| Uwe Luebbers||||ul||||framework||||Sun Microsystems
|-
| Thorsten Martens||||tm||||framework||||Sun Microsystems
|-
| Olaf Felka|||| of||||framework, installation||||Sun Microsystems
|-
| Thomas Klarhoefer||||kla||||chart||||Sun Microsystems
|-
| Wolfram Garten|||| wg||||draw, impress||||Sun Microsystems
|-
| Christian Guenther||||cgu||||draw, impress||||Sun Microsystems
|-
| [[User:Thorsten_Ziehm|Thorsten Ziehm]]||||| thorstenziehm||||||QA lead||Sun Microsystems
|-
|}

We are tracking pending JCAs in the document [[Pending JCAs]].

== Related Pages ==
* [[User Experience Community]]
* A map of OOo developers around the world is available at http://www.frappr.com/ooodev, please add yourself to the map if you're involved in OOo development. It's just fun to see who's where :-)

[[Category:Development]]

Documentation/Building Guide/Building on MacOSX

2007-02-15T20:51:36Z

Plipli: /* One-Time preparations and scripts */

<big>'''This document tries to wrap-up the build process for [[OpenOffice.org]] on MacOS X using the native windowing-toolkit of the platform named Aqua.''' </big>

An important goal is to get the demonstration programs "svdem" up and running. They act as a fairly good starting point to further endeavours, since they are used to test the capabilities of the underlying [[VCL]] layer. If this is achieved, one can build and Install the full-fledged OpenOffice.org Package. The purpose of this document is to describe the cumbersome build process of OpenOffice.org rather than to give a kickstart in the coding involved to get VCL ported to Carbon. A starting point for this is Pierre de Filippis excellent [[Intro To Mac Porting]].

I use the bash shell in all examples, since to my belief users of the C-shell are smart enough to figure out the differences anyway. If you want to dig deeper into the build process, please have a look at the description of the build environment here: [http://tools.openoffice.org/build_env.html Open OfficeBuild Environment].

Many thanks for help and assistance go to Pavel Janik and Eric Bachard.

== '''Prerequisites''' ==

This document was derived from the description of the X11 build thanksworthy provided by Eric Hoch in this document: [[MacOSXBuildInstructions]]. Here I like to outline the things you need to build the Aqua Version (besides the OS).

=== Mandatory ===

==== Xcode ====

This is (with GNU cp, soon optional) the only mandatory part to be installed to build Aqua version of OpenOffice.org.

Current verified working version is XCode 2.4.

Xcode 2.2, 2.3 are known to work for Aqua development. If any earlier versions work as well, please add them here.

==== X11SDK (soon optional) ====

A dependency for Mozilla plugin needs some prototype defined in some Xllib.h header.

Please note, this dependency is not needed in runtime, but only at buildtime.

X11SDK.pkg archive is located in your Tiger's DVD, and has to be installed in the case of you're using Mozilla prebuild archives

'''Workaround''' : XCode does contain Xlib headers. Just modify INCLUDE path properly will solve the build issue.

Meant replace ( not existing)
/usr/X11R6/include

with (existing) : /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include

Doing a symlink between them :
<code>
If X11 and /or X11SDK is(are) not installed :
sudo mkdir -p /usr/X11R6

sudo ln -s /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include /usr/X11R6/include
</code>

<pre>This issue should be fixed soon.</pre>

=== Strongly recommended ===

==== ccache ====
If you intend to build several times OpenOffice, you probably can benefit of ccache. ccache will speed up your future builds. The first time you make a build with ccache you won't notice it, but then the build will go up to five times faster.

You can install it using fink. It is simply named "ccache".

If you don't use fink, you can download it and build it yourself using the source provided at http://ccache.samba.org/

Then, in order to use it, you need to change the following environment variables (using bash) :

<pre>
export CC="ccache gcc"
export CXX="ccache g++"
</pre>

=== Optional ===

==== Java ====

Normally installed with XCode.

==== The perl module Archive::Zip ( optional ) ====

Nothing is needed anymore with recent versions of XCode (means : not needed with XCode 2.4 at least).

If you still have issues doing configure because of that, please install Archive::Zip repecting the instructions below :

<code>[bash,N]
perl -MCPAN -eshell
install Archive::Zip
</code>

==== gpc ( optional) ====
GPC is available here: ftp://ftp.cs.man.ac.uk/pub/toby/gpc/gpc231.tar.Z>
Attention: Direct Link to the download but it's only a few hundred KB.
Note: You can alternatively use the libart_lgpl library instead of GPC. This requires an additional configure flag (--enable-libart) and a precompiled libart library installed in a standard location, such as /usr/lib.

==== pkg-config (optional) ====

Nothing to install on Aqua build, since --disable-gtk is forced

Called ''pkgconfig'' in Fink.

pkg-config can be found here : http://pkgconfig.freedesktop.org/wiki/

== '''Some Background (what is aquavcl01, EIS)''' ==

=== EIS ===
OpenOffice sources are basically kept in the CVS server located at anoncvs.services.openoffice.org. However this repository is managed by a database on top called EIS (Environment Information System) which is used to keep track of Master- and Client Workspaces. Master Workspaces are used to keep track of changes going back of the mainline trunk and undergo extensive QA-cycles. These Master Workspaces are driven to official releases. Child workspaces in contrast are copies of certain Master Workspaces used to develop and test bugfixes and additional functionality. These Child Workspaces are later (hopefully) merged back to mainlain Master Workspaces. The TX20 Report mentioned in the Links section gives a very good overview about the overall process. To learn more about Childworkspaces (CWS) have a look here: [[CWS]].

Go to EIS http://eis.services.openoffice.org/EIS2/servlet/Logon and Logon as guest/guest to get yourself an impression. You can find information about the different workspaces, their dates and times there.

=== VCL (Visual Class Libraries) ===

Porting OpenOffice.org to a new Windowing Toolkit is mostly porting of the OpenOffice's VCL Layer (Visual Class Libraries) to the new platforms toolkit. The VCL-Layer is responsible of mapping the OpenOffice Application calls to the windowing toolkit.

The (native) OpenOffice port to MacOSX using the Aqua Windowing Toolkit is developed in a child workspace called '''aquavcl01'''. This child workspace consists of the modules (aka subdirs): canvas dtrans extensions freetype padmin scp2 sj2 solenv vcl.

The basic approach to prepare a developer's client system to successfully build OpenOffice/Aqua is the following:

# checkout a given OpenOffice Milestone.
# checkout aquavcl01 Child Workspace.
# merge them together.
# apply the latest patches.

The last point here is a cumbersome but nevertheless necessary operation, since this porting project is in flux. Thanks to Pavel and many others improvements are happening at tremendous pace at the moment. All of these improvements get distributed as patches/diffs against aquavcl01. Aquavcl01 needs to remain stable all the time, therefore the team needs to work on this patch-by-patch aproach at the moment.

== '''Getting the code (checkout, merge and patch the puppy)''' ==

Now let's have a look what to check-out and where. All these milestone numbers below highly depend on the given point-in-time. The current milestone as of now (February 2nd 2007) is m202. You may change this to your needs. You can find the current milestone of each cws in the EIS database.

You also need to bear in mind that you have to access to the CVS-Server's default port (2401). If a firewall stop's you here you have to setup a CVS-Tunnel.

==== create a directory for a given milestone, setup CVS access: ====
<code>[bash,N]
mkdir src680-m202
cd src680-m202

export CVSROOT=:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs
cvs login
</code>
Please Enter the password 'anoncvs'

==== checkout Milestone m202 (1,5 GB): ====
<code>[bash,N]
cvs -z3 co -r SRC680_m202 OpenOffice2
</code>
Once done, you'll obtain milestone 202. this not exactly what we want, because all changes concerning aquavcl01 Child workspace are not included. To complete, we need to check aquavcl01 changes.

==== checkout Aquavcl01 (50 MB): ====

1) First possibility : create a dedicated tree (cool backup )

To check aquavcl01 Child workspace, the most simple is to create aquavcl01 directory, and go inside this dir
<code>[bash,N]
mkdir aquavcl01-src

cd aquavcl01-src
</code>
(assuming you already did cvs login ..etc )
<code>[bash,N]
cvs -z3 co -r cws_src680_aquavcl01 OpenOffice2
</code>
The following modules will be present at the end :
<div style="background-color: lightyellow; border: 1px red dashed; padding: 3px 0 3px 15px;">
canvas

extensions

fpicker

padmin

sal

scp2

sfx2

solenv

dtrans

freetype

psprint

sj2

vcl

toolkit
</div>

All these modules are the ones we modified to create the native version : they all are tagged "aquavcl01" (see all CVS/Tag files in the tree) and all you have to do is either rename or delete the one located in src680-m202 and replace them with the one located in aquavcl01-src.

e.g. : canvas in src680-m202 will become canvas_m202 , and then, cp canvas from aquavcl01-src into src-m202

This applies for all the modules listed above.

2) Second possibility : use a little script to extract changes : extract_aquavcl01.sh

This shell script, located in src680-m202 will contain :
<code>[bash,N]
#!/bin/bash
list="canvas extensions fpicker padmin scp2 sfx2 solenv dtrans freetype psprint sj2 vcl sal toolkit"
for i in $list ; do
mv $i $i-m202
cvs -z3 co -r cws_src680_aquavcl01 $i
done
</code>

Then chmod +x extract_aquavcl01.sh

and run it :

./extract_aquavcl01.sh

When finished, and if no problem occurs, you should have a complete tree.

=== One-Time preparations and scripts ===

OpenOffice building gets configured by the popular open-source configuration-management package 'autoconf'. So you can do your beloved './configure' command, but in our case this is done in the 'config_office' subdirectory. To save the configure parameters and use them with different milestones I used to link-in my shellscript to fire up the ./configure line.

My directory-structure looks like this:

bin/
src680-m182/
src680-m196/
...

Now I go to the 'config_office' subdir and link in my startscript:
<code>[bash,N]
cd src680-m202/config_office/
ln -s ../../bin/build.sh
</code>
And this is how 'build.sh' looks like:

<code>[bash,N]
#!/bin/sh
export BASE=`pwd|sed 's/\/config_office//'`
export OOVERSION=`echo $BASE|sed 's/^\/.*\///'`
echo Building from : $BASE
echo OpenOffice Version : $OOVERSION
./configure \
--with-lang="de en-US" \
--with-jdk-home=/Library/Java/Home/ \
--with-epm=internal \
--disable-mozab \
--disable-odk \
--disable-pasf \
--disable-gtk \
--disable-mozilla \
--with-build-version=$OOVERSION-`date +%d-%m-%y` \
--disable-fontconfig \
--disable-neon \
--without-nas
</code>

--disable-odk will avoid you to download some windows dll which is not needed for aqua-build.

--disable-pasf : pasf stands for Portable Audio System file. As we want to use system library rather than portable ones, we disabled this. However, at this time not all functionality will be available with pasf disabled. You might willing to use --with-pasf if you want working audio in your build.

--without-nas : nas stands for Network Audio System, it uses X11, if you want to use it in your build, just remove this flag. You will need to install the X11 package provided in your CDs/DVD Mac OS X installation. X11 SDK from xCode tools is not required for build this.

This is allowedly a pretty much limited setup, but my overall goal is to get people to have 'svdem' build to start coding rather than to have a production ready build for the final release. Therefore I switched off most of the stuff. How these offical builds are done in the long run is to be decided when we get there.

== '''List of Patches for a given Milestone''' ==

Here is a list of Patches one has to apply against a given Milestone of SRC680 (including CWS aquavcl01). Please keep the older Milestones here, since people are probably still on these Versions.

PLEASE NOTE : '''Current milestone for Aqua build is m202''' (older milestones are deprecated)

{| border="1" cellpadding="5" cellspacing="0"
|-
! Milestone || Patch to apply || Status
|-
| '''m202''' || see [[List of Patches requiring testing before for integration]] || work in progress
|-
| ''' (deprecated) m202''' || To avoid crashes with several entries in menu apply [http://eric.bachard.free.fr/patches/aqua/about_workaround/diff_salframe.diff about_workaround patch] in vcl/aqua/source/window ||Work in progress
|-
| ''' (deprecated) m200''' || To avoid crashes with several entries in menu apply [http://eric.bachard.free.fr/patches/aqua/about_workaround/diff_salframe.diff about_workaround patch] in vcl/aqua/source/window ||Work in progress
|}

== '''List of Patches requiring testing before for integration''' ==

All patches that developers have that need testing or peer review should be added here.

salatslayout.cxx : new implementation of text layout has to be tested.

== '''Known build issues''' ==

'''(deprecated) m200''': Breakage in instsetoo_native

See [http://eric.bachard.free.fr/mac/aquavcl/patches/m200_aquavcl01/instsetoo_native_util_makefile.mk.diff Fix for instsetoo_native breakage]

how apply the patch ?

Place it in <install_dir>/instsetoo_native/util

type :

patch -p0<instsetoo_native_util_makefile.mk.diff

m196: Breakage in pyuno

See [http://www.openoffice.org/issues/show_bug.cgi?id=72372 pyuno not found]

'''Workaround''' :

<pre>
1) either use the patch provided in issue 72372

2) or simply do ( in the same terminal, or please source the environment before):

cd bridges
build && deliver
cd ../pyuno
build && deliver

-> pyuno should build without any problem

cd .. && dmake

will complete your build

</pre>
[[User:Ericb|Ericb]] 14:52, 13 December 2006 (CET)

== '''Doing the build (about 4,5 GB)''' ==

Fine, now we have a (hopefully) working 'build.sh' in the config_office subdir. We need to run it beforehand:

cd src680-m202/config_office/
./build.sh

This will setup the necessary includefiles and create a couple of files in the '''parent''' directory (bootstrap, MacOSXPPCEnv.Set.sh, MacOSXPPCEnv.Set). If you are using the sh, ksh or bash you only need to take care for 'MacOSXPPCEnv.Set.sh'.

Now we need to get back to our base-directory, run the bootstrap script, source our Enviroment (MacOSXPPCEnv.Set.sh) and finally start the build-process:

On PowerPC :

cd ..
./bootstrap
source MacOSXPPCEnv.Set.sh
time dmake

Or (on Mac Intel ) :

cd ..
./bootstrap
source MacOSXX86Env.Set.sh
time dmake

The main purpose of the '''boostrap''' script is to build (if necessary) the dmake utility used. Dmake once was a unix make-clone made by wticorp but got incorporated into OpenOffice since it was orphaned. For more information about dmake, it's history and manpage have a look here: http://tools.openoffice.org/dmake/index.html

Sourcing MacOSXPPCEnv.Set.sh is very important not only for building but also for '''running''' svdem later on. Here all the Environment-Variables for the Build will be set up. For a detailed description see [[Environment_Variables]]. Please note that on Intel machines, 'MacOSXPPCEnv.Set' should be substituted with 'MacOSXX86Env.Set'.

This Build process takes on my box (Dual 1.8 GHz G5, 1.5GB RAM) roughly 10 hours. Be patient. What can you do meanwhile? Do this:
<code>[bash,N]
while true ; do find . -maxdepth 1 -type d -anewer MacOSXPPCEnv.Set.sh |wc -l ; sleep 5; done
</code>
and wait till the number reaches 174

== '''Creating Debug-Versions of Modules''' ==

<pre> Important: a new section about use XCode for OpenOffice.org debug has been created.
See :</pre>

[[MacOSX_Debug_OpenOffice.org_using_XCode]]

'''Is it possible to build the complete set with symbols included ?'''

Currently not possible, and not advised.

''' is it possible to build some modules with symbols ?'''

Yes, and that's the simplest way to proceed. Some modules, like sal and vcl can be rebuilt using debug.

Example :

To rebuild sal with symbols included, do:

<code>[bash,N]
cd sal
rm -rf unxmacxp.pro
build debug=true
</code>

and recopy the libs into the bundle. gdb will display the symbols, and make your life easier.

Note : debug string is tested, and DEBUG is active when debug string is not empty. So debug=t works too.

''' How change gdb options, and use e.g. -g -ggdb or -gdwarf-2 ?'''

To rebuild the module, you just have to modify the option in solenv/inc/unxmacx.mk, replacing -g with -ggdb

'''Known issues'''

Sometimes a build error, or a runtime error, may be seen in the normal build,
but the error goes away when --enable-debug is used or if the module is compiled with debug=true.

The DEBUG build turns off optimisation, so this is a hint that compiler optimisation causes the error.

The error might be due to incorrect code or a compiler fault. Such errors might not be seen on all platforms,

and might not be seen in different compiler versions on one platform.

If the code can not be fixed there is a workaround using NOOPTFILES to build specified files with no optimisation.

Example :

jvmfwk on Mac OS X: build jvmfwk in m183 on Mac OS X Intel leads to Bus Error when javaldx is run.

Solution : use trial and error to rebuild individual files with debug=true. This proves the problem lies with vendorbase.cxx

Have a look in sc/source/core/data/makefile.mk for an example to use NOOPTFILES

To solve our problem: just add : NOOPTFILES= $(SLO)$/vendorbase.obj in the corresponding makefile.

Take care in case some .IF is needed to prevent interference with other platforms.

There's some additional information around debugging on Christians Page [[User:CL#2006-09-03]]

== Building and running svdem ==

We want to run the demonstration programs called "svdem". There are a couple of binaries called "svdem", which area they cover is still somewhat unclear to me, I hope some of you guys can shed some light here. But hey, this is a wiki! Just correct here :-).

==== svdem from VCL ====
To have the VCL Testprogram build you have to do:

'''[FIXME] replace this scetion with the same, but about svdem from svtools'''

cd vcl; build --all

This should have created a file called "svdem" here: vcl/unxmacxp.pro/bin/svdem. If you managed to build these binaries, you are nearly there. What you need now, is a wrapper directory structure to make this binary a fellow Mac OSX application. I mean the ones which have this structure:

svdem.app/
svdem.app/Contents
svdem.app/Contents/Info.plist
svdem.app/Contents/MacOS
svdem.app/Contents/MacOS/applicat.rdb
svdem.app/Contents/MacOS/svdem

You can basically create this structure anywhere you want. And you can link-in the file you just created (svdem). So you build up this structure once and link-in the freshly created svdem there:

ls -l svdem applicat.rdb
svdem -> /opt/src/openoffice/src680-m202/vcl/unxmacxp.pro/bin/svdem
applicat.rdb -> /opt/src/openoffice/src680-m202/vcl/unxmacxp.pro/bin/applicat.rdb

Now only the Info.plist file is missing, so here we go:

<code>[xml,N]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleDisplayName</key>
<string>SvDem</string>
<key>CFBundleExecutable</key>
<string>svdem</string>
<key>CFBundleIdentifier</key>
<string>com.yourcompany.svdem</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>LSRequiresCarbon</key>
<true/>
</dict>
</plist>
</code>

If you created the directory structure properly you can do './svdem' in the 'svdem.app/Contents/MacOS/' directory. You should see the svdem coming up.

==== svdem from svtools ====
* Copy the application package you created for the vcl svdem.
* Source your MacOSX[PPC-X86]Env.Set.sh
* Go into svtools/workben
* build svdem using dmake in the workben directory
* link the svdem and applicat.rdb from Contents/MacOS to the ones located in svtools/unxmacxp.pro/bin

You are done : you can now source your environment and run svdem using your usual shell.

== '''Installing, preparing and running OpenOffice.org''' ==

Here I like to outline the steps to run OpenOffice.org after a successful build from the sources. Running the native Aqua Version of OpenOffice.org is somewhat tricky at the moment, since the installation procedure and mode are not in their final state. So right now one has to manually do some preparations to run the Office suite. This will change in the future when we are about to release some Alpha Builds to a wider audience.

=== Drag & Drop Install the Application from the Diskimage ===

When you are one of the lucky few (Don't give up, Eric!), who have a successful build, you are going to see something like this as the last lines of the build:

.
.
.
......................................................................................................................................................
(CRC32 $11685D33: DiscRecording 3.1.3f2 (Apple_HFS : 2))
Ressourcen hinzufügen…
......................................................................................................................................................
Dauer: 15.406s
Dateigröße: 144732418 Bytes, Prüfsumme: CRC32 $14E0BB67
Bearbeitete Sektoren: 773848, 773845 komprimiert
Geschwindigkeit: 24.5M Bytes/Sek
Ersparnis: 63.5 %
created: /opt/src/openoffice/src680-m202/instsetoo_native/unxmacxp.pro/OpenOffice/install/de/OpenOffice.org-2.2_de.dmg

In this final step the ""instsetoo_native"" target creates the install Diskimages using Apple's 'hdiutil'. In my case it gives its output in German. After this disk image(s) have been created, double click the disk image to mount it (or type open <path to the DMG Image>) , and then move the icon named "OpenOffice.org 2.2" to your ''Applications'' folder (or any other folder you want this program to reside). The "OpenOffice.org 2.1" icon shown in the Finder is in fact a subdirectory called "OpenOffice.org 2.2.app". Subdirectories named ".app" (along with some well-know files inside like Info.plist, etc) are called ''Bundles'' in Apple's lingo.

=== Prepare the installation ===

'''Soon optional (tests in progress) '''

After the OpenOffice 2.2 Application has been copied to its destination, you have to go into this bundle and run a small shell script provided by Pavel Janik to prepare soffice.bin (OpenOffice.org launcher) for running. You have to run this script in the directory where a Universal Binary called "droplet" is located. This "droplet" binary was used to fire-off the X11 version of OpenOffice.org. Expect this to change, but as of now we have to do it like this.

I have put my OpenOffice.org build in my home directory's private "Application" folder (/Users/schmidtm/Applications), so please change this path to your installation. Now go to into the bundle and run the script:

cd /Users/schmidtm/Applications/OpenOffice.org 2.2.app/Contents/MacOS
/opt/src/openoffice/bin/fix_installed_OOo

<code>[bash,N]
#!/bin/bash

[ ! -f droplet ] && {
echo "Please run me in the directory, where binary named droplet is located."
exit 0
}

mv THIRDPARTYLICENSEREADME.html help presets share ..
mv droplet droplet.orig
mv program/* .
rmdir program

cd ..
ln -sf MacOS program
sed 's#droplet#soffice.bin#' Info.plist >Info.plist.new
mv Info.plist.new Info.plist
cd MacOS
</code>

=== Run the soffice.bin ===

We're nearly through, let's fire-off the binary:

AQUA_NATIVE_MENUS=TRUE ./soffice.bin -nofirststartwizard -norestore

Notice the enviroment variable here. AQUA_NATIVE_MENUS is experimental stuff created by Pavel, SAL_NO_NWF was created some times ago, and is located in vcl/source/window/window.cxx . At the moment we have:

{| border="1" cellpadding="5" cellspacing="0"
|-
! Variable || Function
|-
| SAL_NO_NWF=TRUE || disable native controls code
|-
| AQUA_NATIVE_MENUS=TRUE || enable experimental native menus code
|}

Both changes are marked with comments in the source code, and when we remove them in the future, native controls and native menus will be enabled by default.

'''HACK''' : with current code, to enable native menus by defaut without have to define an environment variable, just comment as follow :

in vcl/aqua/source/window/salmenu.cxx, around line 124 :
<code>
/*
static const char *pExperimental = getenv ("AQUA_NATIVE_MENUS");

if ( !pExperimental || strcasecmp(pExperimental, "TRUE") )
return FALSE;
*/
</code>

== External links ==

# Bug Database: http://www.openoffice.org/issues/query.cgi
# Mailinglist: mac@porting.openoffice.org
# IRC Meeting-Logs (#ooo_macport@freenode.org): [[Previous_Mac_Meeting_logs]] [[MacOSXPortMeetings]]
# TX20: http://eric.bachard.free.fr/UTBM_TX20/reports/Carbon_vcl.pdf
# OpenOffice Source Directory Structure: http://wiki.services.openoffice.org/wiki/Source_code_directories
# Pavels Patch Wiki: http://blog.janik.cz/
# Eric Bachard Wiki: http://wiki.services.openoffice.org/wiki/User:Ericb
# Christian Lippka Wiki: http://wiki.services.openoffice.org/wiki/User:CL
# Carbon: http://developer.apple.com/carbon
# EIS: http://eis.services.openoffice.org/EIS2/servlet/Logon
# Runtime Configuration: http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/index.html
# OpenOffice Domain Developer http://wiki.services.openoffice.org/wiki/DomainDeveloper

== Screenshots ==

# Eric Bachard screenshots (some are from Stephan Schaefer) http://eric.bachard.free.fr/mac/aquavcl/screenshots/
# Most recent: http://eric.bachard.free.fr/mac/aquavcl/screenshots/aqua_menus_05_nov_06/
# Pavel Janik screenshots http://blog.janik.cz/images/MacOSX/2006-08-10
# Important screenshot (eventloop issue) : http://blog.janik.cz/images/MacOSX/ => See : OOoMenus-separator-and-disabled_entries.png
# Native Menus : http://eric.bachard.free.fr/mac/aquavcl/screenshots/aqua_native_controls_03_11_06/aqua_menus_01.jpg

More menus : http://eric.bachard.free.fr/mac/aquavcl/screenshots/aqua_menus_05_nov_06/index.html

[[Category:MacOSX]]
[[Category:Porting]]
[[Category:Development]]
[[Category:Aqua]]

User:Ericb

2007-02-13T14:06:12Z

Plipli: /* '''Strategy for native port''' */

User:Ericb

2007-02-13T12:38:33Z

Plipli: /* salatslayout */

Documentation/Building Guide/Building on MacOSX

2007-02-10T05:48:11Z

Plipli: /* '''List of Patches requiring testing before for integration''' */

<big>'''This document tries to wrap-up the build process for [[OpenOffice.org]] on MacOS X using the native windowing-toolkit of the platform named Aqua.''' </big>

An important goal is to get the demonstration programs "svdem" up and running. They act as a fairly good starting point to further endeavours, since they are used to test the capabilities of the underlying [[VCL]] layer. If this is achieved, one can build and Install the full-fledged OpenOffice.org Package. The purpose of this document is to describe the cumbersome build process of OpenOffice.org rather than to give a kickstart in the coding involved to get VCL ported to Carbon. A starting point for this is Pierre de Filippis excellent [[Intro To Mac Porting]].

I use the bash shell in all examples, since to my belief users of the C-shell are smart enough to figure out the differences anyway. If you want to dig deeper into the build process, please have a look at the description of the build environment here: [http://tools.openoffice.org/build_env.html Open OfficeBuild Environment].

Many thanks for help and assistance go to Pavel Janik and Eric Bachard.

== '''Prerequisites''' ==

This document was derived from the description of the X11 build thanksworthy provided by Eric Hoch in this document: [[MacOSXBuildInstructions]]. Here I like to outline the things you need to build the Aqua Version (besides the OS).

=== Mandatory ===

==== Xcode ====

This is (with GNU cp, soon optional) the only mandatory part to be installed to build Aqua version of OpenOffice.org.

Current verified working version is XCode 2.4.

Xcode 2.2, 2.3 are known to work for Aqua development. If any earlier versions work as well, please add them here.

==== X11SDK (soon optional) ====

A dependency for Mozilla plugin needs some prototype defined in some Xllib.h header.

Please note, this dependency is not needed in runtime, but only at buildtime.

X11SDK.pkg archive is located in your Tiger's DVD, and has to be installed in the case of you're using Mozilla prebuild archives

'''Workaround''' : XCode does contain Xlib headers. Just modify INCLUDE path properly will solve the build issue.

Meant replace ( not existing)
/usr/X11R6/include

with (existing) : /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include

Doing a symlink between them :
<code>
If X11 and /or X11SDK is(are) not installed :
sudo mkdir -p /usr/X11R6

sudo ln -s /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include /usr/X11R6/include
</code>

<pre>This issue should be fixed soon.</pre>

=== Strongly recommended ===

==== ccache ====
If you intend to build several times OpenOffice, you probably can benefit of ccache. ccache will speed up your future builds. The first time you make a build with ccache you won't notice it, but then the build will go up to five times faster.

You can install it using fink. It is simply named "ccache".

If you don't use fink, you can download it and build it yourself using the source provided at http://ccache.samba.org/

Then, in order to use it, you need to change the following environment variables (using bash) :

<pre>
export CC="ccache gcc"
export CXX="ccache g++"
</pre>

=== Optional ===

==== Java ====

Normally installed with XCode.

==== The perl module Archive::Zip ( optional ) ====

Nothing is needed anymore with recent versions of XCode (means : not needed with XCode 2.4 at least).

If you still have issues doing configure because of that, please install Archive::Zip repecting the instructions below :

<code>[bash,N]
perl -MCPAN -eshell
install Archive::Zip
</code>

==== gpc ( optional) ====
GPC is available here: ftp://ftp.cs.man.ac.uk/pub/toby/gpc/gpc231.tar.Z>
Attention: Direct Link to the download but it's only a few hundred KB.
Note: You can alternatively use the libart_lgpl library instead of GPC. This requires an additional configure flag (--enable-libart) and a precompiled libart library installed in a standard location, such as /usr/lib.

==== pkg-config (optional) ====

Nothing to install on Aqua build, since --disable-gtk is forced

Called ''pkgconfig'' in Fink.

pkg-config can be found here : http://pkgconfig.freedesktop.org/wiki/

== '''Some Background (what is aquavcl01, EIS)''' ==

=== EIS ===
OpenOffice sources are basically kept in the CVS server located at anoncvs.services.openoffice.org. However this repository is managed by a database on top called EIS (Environment Information System) which is used to keep track of Master- and Client Workspaces. Master Workspaces are used to keep track of changes going back of the mainline trunk and undergo extensive QA-cycles. These Master Workspaces are driven to official releases. Child workspaces in contrast are copies of certain Master Workspaces used to develop and test bugfixes and additional functionality. These Child Workspaces are later (hopefully) merged back to mainlain Master Workspaces. The TX20 Report mentioned in the Links section gives a very good overview about the overall process. To learn more about Childworkspaces (CWS) have a look here: [[CWS]].

Go to EIS http://eis.services.openoffice.org/EIS2/servlet/Logon and Logon as guest/guest to get yourself an impression. You can find information about the different workspaces, their dates and times there.

=== VCL (Visual Class Libraries) ===

Porting OpenOffice.org to a new Windowing Toolkit is mostly porting of the OpenOffice's VCL Layer (Visual Class Libraries) to the new platforms toolkit. The VCL-Layer is responsible of mapping the OpenOffice Application calls to the windowing toolkit.

The (native) OpenOffice port to MacOSX using the Aqua Windowing Toolkit is developed in a child workspace called '''aquavcl01'''. This child workspace consists of the modules (aka subdirs): canvas dtrans extensions freetype padmin scp2 sj2 solenv vcl.

The basic approach to prepare a developer's client system to successfully build OpenOffice/Aqua is the following:

# checkout a given OpenOffice Milestone.
# checkout aquavcl01 Child Workspace.
# merge them together.
# apply the latest patches.

The last point here is a cumbersome but nevertheless necessary operation, since this porting project is in flux. Thanks to Pavel and many others improvements are happening at tremendous pace at the moment. All of these improvements get distributed as patches/diffs against aquavcl01. Aquavcl01 needs to remain stable all the time, therefore the team needs to work on this patch-by-patch aproach at the moment.

== '''Getting the code (checkout, merge and patch the puppy)''' ==

Now let's have a look what to check-out and where. All these milestone numbers below highly depend on the given point-in-time. The current milestone as of now (February 2nd 2007) is m202. You may change this to your needs. You can find the current milestone of each cws in the EIS database.

You also need to bear in mind that you have to access to the CVS-Server's default port (2401). If a firewall stop's you here you have to setup a CVS-Tunnel.

==== create a directory for a given milestone, setup CVS access: ====
<code>[bash,N]
mkdir src680-m202
cd src680-m202

export CVSROOT=:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs
cvs login
</code>
Please Enter the password 'anoncvs'

==== checkout Milestone m202 (1,5 GB): ====
<code>[bash,N]
cvs -z3 co -r SRC680_m202 OpenOffice2
</code>
Once done, you'll obtain milestone 202. this not exactly what we want, because all changes concerning aquavcl01 Child workspace are not included. To complete, we need to check aquavcl01 changes.

==== checkout Aquavcl01 (50 MB): ====

1) First possibility : create a dedicated tree (cool backup )

To check aquavcl01 Child workspace, the most simple is to create aquavcl01 directory, and go inside this dir
<code>[bash,N]
mkdir aquavcl01-src

cd aquavcl01-src
</code>
(assuming you already did cvs login ..etc )
<code>[bash,N]
cvs -z3 co -r cws_src680_aquavcl01 OpenOffice2
</code>
The following modules will be present at the end :
<div style="background-color: lightyellow; border: 1px red dashed; padding: 3px 0 3px 15px;">
canvas

extensions

fpicker

padmin

sal

scp2

sfx2

solenv

dtrans

freetype

psprint

sj2

vcl

toolkit
</div>

All these modules are the ones we modified to create the native version : they all are tagged "aquavcl01" (see all CVS/Tag files in the tree) and all you have to do is either rename or delete the one located in src680-m202 and replace them with the one located in aquavcl01-src.

e.g. : canvas in src680-m202 will become canvas_m202 , and then, cp canvas from aquavcl01-src into src-m202

This applies for all the modules listed above.

2) Second possibility : use a little script to extract changes : extract_aquavcl01.sh

This shell script, located in src680-m202 will contain :
<code>[bash,N]
#!/bin/bash
list="canvas extensions fpicker padmin scp2 sfx2 solenv dtrans freetype psprint sj2 vcl sal toolkit"
for i in $list ; do
mv $i $i-m202
cvs -z3 co -r cws_src680_aquavcl01 $i
done
</code>

Then chmod +x extract_aquavcl01.sh

and run it :

./extract_aquavcl01.sh

When finished, and if no problem occurs, you should have a complete tree.

=== One-Time preparations and scripts ===

OpenOffice building gets configured by the popular open-source configuration-management package 'autoconf'. So you can do your beloved './configure' command, but in our case this is done in the 'config_office' subdirectory. To save the configure parameters and use them with different milestones I used to link-in my shellscript to fire up the ./configure line.

My directory-structure looks like this:

bin/
src680-m182/
src680-m196/
...

Now I go to the 'config_office' subdir and link in my startscript:
<code>[bash,N]
cd src680-m202/config_office/
ln -s ../../bin/build.sh
</code>
And this is how 'build.sh' looks like:

<code>[bash,N]
#!/bin/sh
export BASE=`pwd|sed 's/\/config_office//'`
export OOVERSION=`echo $BASE|sed 's/^\/.*\///'`
echo Building from : $BASE
echo OpenOffice Version : $OOVERSION
./configure \
--with-lang="de en-US" \
--with-jdk-home=/Library/Java/Home/ \
--with-gnu-cp=/sw/bin/cp \
--with-epm=internal \
--disable-mozab \
--disable-odk \
--disable-pasf \
--disable-gtk \
--disable-mozilla \
--with-build-version=$OOVERSION-`date +%d-%m-%y` \
--disable-fontconfig \
--disable-neon \
--without-nas
</code>

--disable-odk will avoid you to download some windows dll which is not needed for aqua-build.

--disable-pasf : pasf stands for Portable Audio System file. As we want to use system library rather than portable ones, we disabled this. However, at this time not all functionality will be available with pasf disabled. You might willing to use --with-pasf if you want working audio in your build.

--disable-nas : nas stands for Network Audio System, it uses X11, if you want to use it in your build, just remove this flag. You will need to install the X11 package provided in your CDs/DVD Mac OS X installation. X11 SDK from xCode tools is not required for build this.

This is allowedly a pretty much limited setup, but my overall goal is to get people to have 'svdem' build to start coding rather than to have a production ready build for the final release. Therefore I switched off most of the stuff. How these offical builds are done in the long run is to be decided when we get there.

== '''List of Patches for a given Milestone''' ==

Here is a list of Patches one has to apply against a given Milestone of SRC680 (including CWS aquavcl01). Please keep the older Milestones here, since people are probably still on these Versions.



PLEASE NOTE : '''Current milestone for Aqua build is m202''' (older milestones are deprecated)

{| border="1" cellpadding="5" cellspacing="0"
|-
! Milestone || Patch to apply || Status
|-
| ''' m202''' || To avoid crashes with several entries in menu apply [http://eric.bachard.free.fr/patches/aqua/about_workaround/diff_salframe.diff about_workaround patch] in vcl/aqua/source/window ||Work in progress
|-
| ''' (deprecated) m200''' || To avoid crashes with several entries in menu apply [http://eric.bachard.free.fr/patches/aqua/about_workaround/diff_salframe.diff about_workaround patch] in vcl/aqua/source/window ||Work in progress
|}

== '''List of Patches requiring testing before for integration''' ==

All patches that developers have that need testing or peer review should be added here.

salatslayout.cxx : new implementation of text layout has to be tested.

== '''Known build issues''' ==

'''(deprecated) m200''': Breakage in instsetoo_native

See [http://eric.bachard.free.fr/mac/aquavcl/patches/m200_aquavcl01/instsetoo_native_util_makefile.mk.diff Fix for instsetoo_native breakage]

how apply the patch ?

Place it in <install_dir>/instsetoo_native/util

type :

patch -p0<instsetoo_native_util_makefile.mk.diff

m196: Breakage in pyuno

See [http://www.openoffice.org/issues/show_bug.cgi?id=72372 pyuno not found]

'''Workaround''' :

<pre>
1) either use the patch provided in issue 72372

2) or simply do ( in the same terminal, or please source the environment before):

cd bridges
build && deliver
cd ../pyuno
build && deliver

-> pyuno should build without any problem

cd .. && dmake

will complete your build

</pre>
[[User:Ericb|Ericb]] 14:52, 13 December 2006 (CET)

== '''Doing the build (about 4,5 GB)''' ==

Fine, now we have a (hopefully) working 'build.sh' in the config_office subdir. We need to run it beforehand:

cd src680-m202/config_office/
./build.sh

This will setup the necessary includefiles and create a couple of files in the '''parent''' directory (bootstrap, MacOSXPPCEnv.Set.sh, MacOSXPPCEnv.Set). If you are using the sh, ksh or bash you only need to take care for 'MacOSXPPCEnv.Set.sh'.

Now we need to get back to our base-directory, run the bootstrap script, source our Enviroment (MacOSXPPCEnv.Set.sh) and finally start the build-process:

On PowerPC :

cd ..
./bootstrap
source MacOSXPPCEnv.Set.sh
time dmake

Or (on Mac Intel ) :

cd ..
./bootstrap
source MacOSXX86Env.Set.sh
time dmake

The main purpose of the '''boostrap''' script is to build (if necessary) the dmake utility used. Dmake once was a unix make-clone made by wticorp but got incorporated into OpenOffice since it was orphaned. For more information about dmake, it's history and manpage have a look here: http://tools.openoffice.org/dmake/index.html

Sourcing MacOSXPPCEnv.Set.sh is very important not only for building but also for '''running''' svdem later on. Here all the Environment-Variables for the Build will be set up. For a detailed description see [[Environment_Variables]]. Please note that on Intel machines, 'MacOSXPPCEnv.Set' should be substituted with 'MacOSXX86Env.Set'.

This Build process takes on my box (Dual 1.8 GHz G5, 1.5GB RAM) roughly 10 hours. Be patient. What can you do meanwhile? Do this:
<code>[bash,N]
while true ; do find . -maxdepth 1 -type d -anewer MacOSXPPCEnv.Set.sh |wc -l ; sleep 5; done
</code>
and wait till the number reaches 174

== '''Creating Debug-Versions of Modules''' ==

<pre> Important: a new section about use XCode for OpenOffice.org debug has been created.
See :</pre>

[[MacOSX_Debug_OpenOffice.org_using_XCode]]

'''Is it possible to build the complete set with symbols included ?'''

Currently not possible, and not advised.

''' is it possible to build some modules with symbols ?'''

Yes, and that's the simplest way to proceed. Some modules, like sal and vcl can be rebuilt using debug.

Example :

To rebuild sal with symbols included, do:

<code>[bash,N]
cd sal
rm -rf unxmacxp.pro
build debug=true
</code>

and recopy the libs into the bundle. gdb will display the symbols, and make your life easier.

Note : debug string is tested, and DEBUG is active when debug string is not empty. So debug=t works too.

''' How change gdb options, and use e.g. -g -ggdb or -gdwarf-2 ?'''

To rebuild the module, you just have to modify the option in solenv/inc/unxmacx.mk, replacing -g with -ggdb

'''Known issues'''

Sometimes a build error, or a runtime error, may be seen in the normal build,
but the error goes away when --enable-debug is used or if the module is compiled with debug=true.

The DEBUG build turns off optimisation, so this is a hint that compiler optimisation causes the error.

The error might be due to incorrect code or a compiler fault. Such errors might not be seen on all platforms,

and might not be seen in different compiler versions on one platform.

If the code can not be fixed there is a workaround using NOOPTFILES to build specified files with no optimisation.

Example :

jvmfwk on Mac OS X: build jvmfwk in m183 on Mac OS X Intel leads to Bus Error when javaldx is run.

Solution : use trial and error to rebuild individual files with debug=true. This proves the problem lies with vendorbase.cxx

Have a look in sc/source/core/data/makefile.mk for an example to use NOOPTFILES

To solve our problem: just add : NOOPTFILES= $(SLO)$/vendorbase.obj in the corresponding makefile.

Take care in case some .IF is needed to prevent interference with other platforms.

There's some additional information around debugging on Christians Page [[User:CL#2006-09-03]]

== Building and running svdem ==

We want to run the demonstration programs called "svdem". There are a couple of binaries called "svdem", which area they cover is still somewhat unclear to me, I hope some of you guys can shed some light here. But hey, this is a wiki! Just correct here :-).

==== svdem from VCL ====
To have the VCL Testprogram build you have to do:

'''[FIXME] replace this scetion with the same, but about svdem from svtools'''

cd vcl; build --all

This should have created a file called "svdem" here: vcl/unxmacxp.pro/bin/svdem. If you managed to build these binaries, you are nearly there. What you need now, is a wrapper directory structure to make this binary a fellow Mac OSX application. I mean the ones which have this structure:

svdem.app/
svdem.app/Contents
svdem.app/Contents/Info.plist
svdem.app/Contents/MacOS
svdem.app/Contents/MacOS/applicat.rdb
svdem.app/Contents/MacOS/svdem

You can basically create this structure anywhere you want. And you can link-in the file you just created (svdem). So you build up this structure once and link-in the freshly created svdem there:

ls -l svdem applicat.rdb
svdem -> /opt/src/openoffice/src680-m202/vcl/unxmacxp.pro/bin/svdem
applicat.rdb -> /opt/src/openoffice/src680-m202/vcl/unxmacxp.pro/bin/applicat.rdb

Now only the Info.plist file is missing, so here we go:

<code>[xml,N]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleDisplayName</key>
<string>SvDem</string>
<key>CFBundleExecutable</key>
<string>svdem</string>
<key>CFBundleIdentifier</key>
<string>com.yourcompany.svdem</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>LSRequiresCarbon</key>
<true/>
</dict>
</plist>
</code>

If you created the directory structure properly you can do './svdem' in the 'svdem.app/Contents/MacOS/' directory. You should see the svdem coming up.

==== svdem from svtools ====
* Copy the application package you created for the vcl svdem.
* Source your MacOSX[PPC-X86]Env.Set.sh
* Go into svtools/workben
* build svdem using dmake in the workben directory
* link the svdem and applicat.rdb from Contents/MacOS to the ones located in svtools/unxmacxp.pro/bin

You are done : you can now source your environment and run svdem using your usual shell.

== '''Installing, preparing and running OpenOffice.org''' ==

Here I like to outline the steps to run OpenOffice.org after a successful build from the sources. Running the native Aqua Version of OpenOffice.org is somewhat tricky at the moment, since the installation procedure and mode are not in their final state. So right now one has to manually do some preparations to run the Office suite. This will change in the future when we are about to release some Alpha Builds to a wider audience.

=== Drag & Drop Install the Application from the Diskimage ===

When you are one of the lucky few (Don't give up, Eric!), who have a successful build, you are going to see something like this as the last lines of the build:

.
.
.
......................................................................................................................................................
(CRC32 $11685D33: DiscRecording 3.1.3f2 (Apple_HFS : 2))
Ressourcen hinzufügen…
......................................................................................................................................................
Dauer: 15.406s
Dateigröße: 144732418 Bytes, Prüfsumme: CRC32 $14E0BB67
Bearbeitete Sektoren: 773848, 773845 komprimiert
Geschwindigkeit: 24.5M Bytes/Sek
Ersparnis: 63.5 %
created: /opt/src/openoffice/src680-m202/instsetoo_native/unxmacxp.pro/OpenOffice/install/de/OpenOffice.org-2.2_de.dmg

In this final step the ""instsetoo_native"" target creates the install Diskimages using Apple's 'hdiutil'. In my case it gives its output in German. After this disk image(s) have been created, double click the disk image to mount it (or type open <path to the DMG Image>) , and then move the icon named "OpenOffice.org 2.2" to your ''Applications'' folder (or any other folder you want this program to reside). The "OpenOffice.org 2.1" icon shown in the Finder is in fact a subdirectory called "OpenOffice.org 2.2.app". Subdirectories named ".app" (along with some well-know files inside like Info.plist, etc) are called ''Bundles'' in Apple's lingo.

=== Prepare the installation ===

'''Soon optional (tests in progress) '''

After the OpenOffice 2.2 Application has been copied to its destination, you have to go into this bundle and run a small shell script provided by Pavel Janik to prepare soffice.bin (OpenOffice.org launcher) for running. You have to run this script in the directory where a Universal Binary called "droplet" is located. This "droplet" binary was used to fire-off the X11 version of OpenOffice.org. Expect this to change, but as of now we have to do it like this.

I have put my OpenOffice.org build in my home directory's private "Application" folder (/Users/schmidtm/Applications), so please change this path to your installation. Now go to into the bundle and run the script:

cd /Users/schmidtm/Applications/OpenOffice.org 2.2.app/Contents/MacOS
/opt/src/openoffice/bin/fix_installed_OOo

<code>[bash,N]
#!/bin/bash

[ ! -f droplet ] && {
echo "Please run me in the directory, where binary named droplet is located."
exit 0
}

mv THIRDPARTYLICENSEREADME.html help presets share ..
mv droplet droplet.orig
mv program/* .
rmdir program

cd ..
ln -sf MacOS program
sed 's#droplet#soffice.bin#' Info.plist >Info.plist.new
mv Info.plist.new Info.plist
cd MacOS
</code>

=== Run the soffice.bin ===

We're nearly through, let's fire-off the binary:

AQUA_NATIVE_MENUS=TRUE ./soffice.bin -nofirststartwizard -norestore

Notice the enviroment variable here. AQUA_NATIVE_MENUS is experimental stuff created by Pavel, SAL_NO_NWF was created some times ago, and is located in vcl/source/window/window.cxx . At the moment we have:

{| border="1" cellpadding="5" cellspacing="0"
|-
! Variable || Function
|-
| SAL_NO_NWF=TRUE || disable native controls code
|-
| AQUA_NATIVE_MENUS=TRUE || enable experimental native menus code
|}

Both changes are marked with comments in the source code, and when we remove them in the future, native controls and native menus will be enabled by default.

'''HACK''' : with current code, to enable native menus by defaut without have to define an environment variable, just comment as follow :

in vcl/aqua/source/window/salmenu.cxx, around line 124 :
<code>
/*
static const char *pExperimental = getenv ("AQUA_NATIVE_MENUS");

if ( !pExperimental || strcasecmp(pExperimental, "TRUE") )
return FALSE;
*/
</code>

== External links ==

# Bug Database: http://www.openoffice.org/issues/query.cgi
# Mailinglist: mac@porting.openoffice.org
# IRC Meeting-Logs (#ooo_macport@freenode.org): [[Previous_Mac_Meeting_logs]] [[MacOSXPortMeetings]]
# TX20: http://eric.bachard.free.fr/UTBM_TX20/reports/Carbon_vcl.pdf
# OpenOffice Source Directory Structure: http://wiki.services.openoffice.org/wiki/Source_code_directories
# Pavels Patch Wiki: http://blog.janik.cz/
# Eric Bachard Wiki: http://wiki.services.openoffice.org/wiki/User:Ericb
# Christian Lippka Wiki: http://wiki.services.openoffice.org/wiki/User:CL
# Carbon: http://developer.apple.com/carbon
# EIS: http://eis.services.openoffice.org/EIS2/servlet/Logon
# Runtime Configuration: http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/index.html
# OpenOffice Domain Developer http://wiki.services.openoffice.org/wiki/DomainDeveloper

== Screenshots ==

# Eric Bachard screenshots (some are from Stephan Schaefer) http://eric.bachard.free.fr/mac/aquavcl/screenshots/
# Most recent: http://eric.bachard.free.fr/mac/aquavcl/screenshots/aqua_menus_05_nov_06/
# Pavel Janik screenshots http://blog.janik.cz/images/MacOSX/2006-08-10
# Important screenshot (eventloop issue) : http://blog.janik.cz/images/MacOSX/ => See : OOoMenus-separator-and-disabled_entries.png
# Native Menus : http://eric.bachard.free.fr/mac/aquavcl/screenshots/aqua_native_controls_03_11_06/aqua_menus_01.jpg

More menus : http://eric.bachard.free.fr/mac/aquavcl/screenshots/aqua_menus_05_nov_06/index.html

[[Category:MacOSX]]
[[Category:Porting]]
[[Category:Development]]
[[Category:Aqua]]

Aquavcl01 tasks

2007-01-26T13:44:54Z

Plipli: /* '''Remove deprecated functions''' */

This page is work in progress.

== Aqua VCL tasks ==

This page is reserved for all aquavcl01 tasks, and will probably removed (I hope) when aquavcl01 will be integrated)

Any contributions/help to continue/build this page is welcome.

=== '''Remove deprecated functions''' ===

Related reading: [http://developer.apple.com/documentation/Carbon/Reference/QuickDraw_Ref/Reference/reference.html#//apple_ref/doc/c_ref/GDevice QuickDraw Reference], [http://developer.apple.com/documentation/Carbon/Reference/QuickDraw_Ref/DeprecationAppendix/AppendixADeprecatedAPI.html Deprecated QuickDraw functions] and [http://developer.apple.com/documentation/Carbon/Conceptual/QuickDrawToQuartz2D/index.html?http://developer.apple.com/documentation/Carbon/Conceptual/QuickDrawToQuartz2D/tq_intro/chapter_1_section_1.html QuickDraw to Quartz2D guide]

short list of the deprecated functions + the context :

Context 1 : App/ Timer # comment : since RunApplicationEventLoop is usable, we should be able to replace *TimeMask with the recent corresponding kEvent*

file:
deprecated function : RemoveTimeTask / PrimeTimeTask / InstallTimeTask

Context 2: gdi / ATS+fonts : # Comment -> work in progress. I'll describe everything
file : vcl/aqua/source/gdi/salatslayout.cxx

--> i will remove deprecated in salatslayout while i m working on it. (plipli)

deprecated function : ATSUGetGlyphInfo

file : vcl/aqua/source/gdi/salatsuifontutils.cxx # same as ATS+fonts
deprecated functions : TextOrder / ScriptOrder / LanguageOrder / FMGetFontFromFontFamilyInstance

No idea (ChristianL ? ) :

Context 3 : gdi / Color + Pixmaps
file : vcl/aqua/source/gdi/salcolorutils.cxx
deprecated functions : GetGDevice / MakeITable / GetCTSeed / GetPixDepth /GetCTable /

Context3 4: gdi / Geometry + Pixmaps

file : vcl/aqua/source/gdi/salpixmaputils.cxx
deprecated functions : SetRect / GetGDevice (dupe) / NewPixMap / GetPixelsState / SetPixelsState / LockPixels / DisposePixMap

Context 4: Frame

file : vcl/aqua/source/window/salframe.cxx
deprecated functions : GetMainDevice / SetRect (dupe) / NewRgn / GetRegionBounds / DisposeRgn

URL : [http://eric.bachard.free.fr/mac/aquavcl/logs_aquavcl/log.log build log of vcl/aqua]

=== ''' CWS Integration''' ===

Enter your plan/ proposal here

=== ''' CWS REsync''' ===

Current: m187

Scheduled: ?

[FIXME] : complete with other tasks

[[User:Ericb|Ericb]] 21:09, 2 November 2006 (CET)

[[Category:Porting]]
[[Category:MacOSX]]
[[Category:Aqua]]