Apache OpenOffice Wiki - User contributions [en]

Documentation/Building Guide/Building on MacOSX

2006-10-01T13:13:37Z

Pdefilippis: /* Introduction */

=== Introduction ===

This document tries to wrap-up the build process for OpenOffice on MacOS X using the native windowing-toolkit of the platform named Aqua. The main 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 bias 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 enviroment 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 buld the Aqua Version (besides the OS). Your are much better off to install the Fink Package Manager on your Apple, to resolve these dependencies (and get some cool stuff too). Go to [http://fink.sourceforge.net Fink]

==== Xcode ====
Xcode 2.3 and 2.4 are known to work for Aqua development. Please add earlier versions work as well, please add them here.

==== Java 1.4.2+ ====
==== The perl module Archive::Zip ====
<code>[bash,N]
perl -MCPAN -eshell
install Archive::Zip
</code>
==== Apache Ant 1.6.5 ====
For the OpenOffice Builds you need to have Apache's Ant in the source-directory. You have to have Ant Version 1.6.5+. My Ant usually resides in /opt/ant so i link it in from there:
<code>[bash,N]
cd src680-m182/
ln -s /opt/ant/ apache-ant-1.6.5
</code>

==== gpc ====
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 ====
Called ''pkgconfig'' in Fink.

pkg-config can be found here : http://pkgconfig.freedesktop.org/wiki/

==== gnu copy ====
In Fink terms this is in the package ''fileutils''.

If you prefer direct download, GNU coreutils can be found at http://www.gnu.org/software/coreutils/coreutils.html.

After installing, you should copy or rename the newly installed cp to gnucp (located at /usr/local/bin/cp or /sw/bin/cp if you used Fink) (cf. http://qa.openoffice.org/issues/show_bug.cgi?id=69711)

=== Some Backgroud (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 succsessfully 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 (August, 16th 2006) is m184. You may change this to your needs. You can finde 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-m184
cd src680-m184

export CVSROOT=:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs
cvs login
</code>
Please Enter the password 'anoncvs'

==== checkout Milestone m184 (1,5 GB): ====
<code>[bash,N]
cvs -z3 co -r SRC680_m184 OpenOffice2
</code>
Once done, you'll obtain milestone 184. 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 arelady 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 :

canvas
extensions
padmin
scp2
solenv
dtrans
freetype
psprint
sj2
vcl

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-m184 and replace them with the one located in aquavcl01-src.

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

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-m184 will contain :
<code>[bash,N]
#!/bin/bash
list="canvas extensions padmin scp2 solenv dtrans freetype psprint sj2 vcl"
for i in $list ; do
cd $i
cvs up -j CWS_SRC680_AQUAVCL01_ANCHOR -j cws_src680_aquavcl01
cd ..
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.

==== Apply some patches ====

After you've checked-out all the sources you need, you may have to apply some patches.

For the succsessfull build of m184 plus aquavcl01 you need to apply the patch from issue number [http://www.openoffice.org/issues/show_bug.cgi?id=68810 68810]:
<code>[bash,N]
patch -p0 <../patches/i68810.patch
</code>

=== 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-m176/
src680-m182/
...

Now I go to the 'config_office' subdir and link in my startscript:
<code>[bash,N]
cd src680-m182/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-ant-home=$BASE/apache-ant-1.6.5/ \
--with-gnu-cp=/sw/bin/cp \
--with-epm=internal \
--disable-mozab \
--disable-odl \
--disable-pasf \
--disable-gtk \
--disable-mozilla \
--with-build-version=$OOVERSION-`date +%d-%m-%y` \
--disable-fontconfig \
--disable-neon \
--without-nas
</code>

--disable-odl 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.

=== Doing the build ===

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

cd src680-m182/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 MacOSXIntelEnv.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 Enviroment-Variables for the Build will be set up. For a detailed descripton see [[Environment_Variables]]. Please note that on Intel machines, 'MacOSXPPCEnv.Set' should be substituted with 'MacOSXIntelEnv.Set'.

This Build process takes on my box (Dual 1.8 GHz G5, 1.5GB RAM) roughly 10 hours. Be paitioned. 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 ===

'''Is it possible to build the complete set ?'''

Currently not possible, and not adviced.

''' 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 :-).

To have the VCL Testprogram build you have to do:

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-m177//vcl/unxmacxp.pro/bin/svdem
applicat.rdb -> /opt/src/openoffice/src680-m177//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.

=== 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-m182/instsetoo_native/unxmacxp.pro/OpenOffice/install/de/OpenOffice.org-2.0.4_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.0" to your ''Applications'' folder (or any other folder you want this program to reside). The "OpenOffice.org 2.0" icon shown in the Finder is in fact a subdirectory called "OpenOffice.org 2.0.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 ====

After the OpenOffice 2.0 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.0.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 AQUA_NATIVE_CONTROLS=TRUE ./soffice.bin -nofirststartwizard -norestore

Notice the enviroment variable here. It's experimental stuff created by Pavel. At the moment we have:

{| border="1" cellpadding="5" cellspacing="0"
|-
! Variable || Function
|-
| AQUA_NATIVE_CONTROLS=TRUE || enable 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 : to enable native controls and native menus by defaut without have to define an environment variable, just comment as follow :

in vcl/aqua/source/gdi/salnativewidgets.cxx , around line 55 :

<code>
/*
static const char *pExperimental = getenv ("AQUA_NATIVE_CONTROLS");

if ( !pExperimental || strcasecmp(pExperimental, "TRUE") )
return FALSE;
*/
</code>

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>

=== 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.

{| border="1" cellpadding="5" cellspacing="0"
|-
! Milestone || Patch to apply || Status
|-
| m184 || '''Patch 1''': [http://www.openoffice.org/issues/show_bug.cgi?id=68810 sw : 68810] <br>'''Patch 2''': to fix extensions and moz plugin build, building or not mozilla plugin, you have to apply macmozplugfix [http://eric.bachard.free.fr/patches/aqua/extensions_mozplug/aqua_extenstions_mozplug.diff patch] This patch does includes both np_sdk changes and extensions changes (see macmozplugfix cws) <br>'''Patch 3''': to avoid systematical crashes in runtime you'll have to apply [http://eric.bachard.free.fr/patches/aqua/vcl67/vcl67.patch vcl67 patch] in vcl <br> '''Patch 4''' : to simply start OpenOffice.org after applying Pavel's script (else, launch OpenOffice.org using a terminal is mandatory, <br> apply [http://eric.bachard.free.fr/patches/aqua/fix_libsalsystools/i69373.diff.txt i69373]|| OK
|-
| m184 || 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
|}

=== URL Links ===

# MacOSX X11 Build Documentation: http://wiki.services.openoffice.org/wiki/MacOSXBuildInstructions
# Bug Database: http://www.openoffice.org/issues/query.cgi
# Mailinglist: mac@porting.openoffice.org
# IRC Meeting-Logs (#ooo_macport@freenode.org): http://eric.bachard.free.fr/mac/aquavcl/logs_meetings/
# 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/scrollbar_01sept
# 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/ericb_22august/native_menu_4.jpg

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

DomainDeveloper

2006-09-21T10:17:21Z

Pdefilippis:

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 nick || Notes || Affiliation
|-
| || || || || ||
|-
| Volker Ahrend|| || 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||Mac OSX/Linux PPC ports/CL porting||French OOo 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 Framework, XML||Sun Microsystems
|-
| Thorsten Behrens|| X || thb||thorsten||vcl/impress/toolkit visionary||Sun Microsystems
|-
| Thomas Benisch|| X || tbe||||Scripting framework||Sun Microsystems
|-
| Stefan Bergmann|| X || sb||||CL UDK, tools&UCB hacker||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
|-
| Scott Carr|| || kcarr||kcarr||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||||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 ||
|-
| 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||spreadsheet-ness||Novell, Inc.
|-
| Dirk Grobler|| X || dg||||Database Access||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||
|-
| 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
|-
| 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||
|-
| 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||||||
|-
| Dieter Loeschky|| X || ||||Localization||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_||FreeBSD guy||Independent
|-
| John Marmion|| X || jmarmion||||||
|-
| Andreas Martens|| X || ama||||PL Writer||Sun Microsystems
|-
| 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.
|-
| 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]]|| || mmp|| || [[OpenOffice.org User Experience]] Engineer, http://ui.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||||Calc||Sun Microsystems
|-
| Ron Piterman|| || rpiterman||||||
|-
| Noel Power|| || npower||noelp||VBA Interop, Scripting||Novell, Inc.
|-
| Nikolai Pretzell|| X || np || ||Autodoc, code quality philosopher||Sun Microsystems
|-
| Volker Quetschke|| || vq||vq||Windows Build Genius||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||
|-
| 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
|-
| Jürgen Schmidt|| X || jsc||||PL API, 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||||||
|-
| 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||QA||Independent
|-
| Jan Tietjens|| || tietjens||||||
|-
| Rüdiger Timm|| X || rt||||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
|-
|}

=== QA Engineers ===

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Name || @openoffice.org || IRC nick || Interested modules || Notes || Affiliation
|-
| Stefan Baltzer||sba||||writer||||Sun Microsystems
|-
| Oliver Craemer||oc||||calc||||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
|-
| Joerg Skottke||jsk||skotti||||QA framework / Automation framework||Sun Microsystems
|-
| Marc Neumann||msc||||database||||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
|-
| Thorsten Ziehm|| thorstenziehm||||||QA lead||Sun Microsystems
|-
|}

We are tracking pending JCAs in the document [[Pending JCAs]].

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]]

DomainDeveloper

2006-09-21T10:14:40Z

Pdefilippis:

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 nick || Notes || Affiliation
|-
| || || || || ||
|-
| Volker Ahrend|| || 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||Mac OSX/Linux PPC ports/CL porting||French OOo 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 Framework, XML||Sun Microsystems
|-
| Thorsten Behrens|| X || thb||thorsten||vcl/impress/toolkit visionary||Sun Microsystems
|-
| Thomas Benisch|| X || tbe||||Scripting framework||Sun Microsystems
|-
| Stefan Bergmann|| X || sb||||CL UDK, tools&UCB hacker||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
|-
| Scott Carr|| || kcarr||kcarr||Documentation||Progbits
|-
| Colin Charles|| || drbyte||bytee||Malaysian native-lang project||bytebot.net
|-
| Behrend Cornelius|| X || bc||||Wizards||Sun Microsystems
|-
| Michael Cziebalski|| || mci||||||
|-
| 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||||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 ||
|-
| 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||spreadsheet-ness||Novell, Inc.
|-
| Dirk Grobler|| X || dg||||Database Access||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||
|-
| 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
|-
| 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||
|-
| 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||||||
|-
| Dieter Loeschky|| X || ||||Localization||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_||FreeBSD guy||Independent
|-
| John Marmion|| X || jmarmion||||||
|-
| Andreas Martens|| X || ama||||PL Writer||Sun Microsystems
|-
| 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.
|-
| 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]]|| || mmp|| || [[OpenOffice.org User Experience]] Engineer, http://ui.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||||Calc||Sun Microsystems
|-
| Ron Piterman|| || rpiterman||||||
|-
| Noel Power|| || npower||noelp||VBA Interop, Scripting||Novell, Inc.
|-
| Nikolai Pretzell|| X || np || ||Autodoc, code quality philosopher||Sun Microsystems
|-
| Volker Quetschke|| || vq||vq||Windows Build Genius||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||
|-
| 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
|-
| Jürgen Schmidt|| X || jsc||||PL API, 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||||||
|-
| 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||QA||Independent
|-
| Jan Tietjens|| || tietjens||||||
|-
| Rüdiger Timm|| X || rt||||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
|-
|}

=== QA Engineers ===

{| border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
|-
! Name || @openoffice.org || IRC nick || Interested modules || Notes || Affiliation
|-
| Stefan Baltzer||sba||||writer||||Sun Microsystems
|-
| Oliver Craemer||oc||||calc||||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
|-
| Joerg Skottke||jsk||skotti||||QA framework / Automation framework||Sun Microsystems
|-
| Marc Neumann||msc||||database||||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
|-
| Thorsten Ziehm|| thorstenziehm||||||QA lead||Sun Microsystems
|-
|}

We are tracking pending JCAs in the document [[Pending JCAs]].

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]]

Mac OS X Porting - Scrollbar

2006-09-18T02:07:05Z

Pdefilippis:

=Scrollbar=

==Contributors==
* Eric Bachard: [[User:Ericb|Ericb]]
* Pierre de Filippis: [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

==Introduction==
The purpose of this article is first to present our current knowledge of the implementation of scrollbars in the native Mac OS X version of OpenOffice.org and second to be a tutorial on how to create scrollbars with HITheme.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Conceptual/ProgAppearance_Manager/index.html Inside Carbon: Appearance Manager]
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
As stated on the Native Controls page, HITheme is the new version of the Appearance Manager. Apple is pushing developers to use it since they are not supporting the AE anymore. But to make the transition easy Apple made the HITheme API very close to the AE. For example both have functions with very similar name and both share the same constants. You can always refer back to the AE to find the list of these constants and use them in HITheme functions.

==The Track==
The Appearance Manager hence HITheme group controls under 2 categories: buttons and tracks. Is considered a track: various types of rectangular controls including scroll bars, sliders, and progress bars.

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

User:Pdefilippis

2006-09-14T17:35:06Z

Pdefilippis: /* Articles */

===Developer ID===
* Name: Pierre de Filippis
* User ID: pdefilippis
* Blog: [http://aliscafo.blogspot.com/ http://aliscafo.blogspot.com/]
* Website: [http://www.aliscafo.com/ http://www.aliscafo.com/]
* IRC Nickname: aliscafo
* E-mail: [mailto:aliscafo@gmail.com aliscafo@gmail.com]

===Current Work===
I am working on the implementation of native controls for the native Mac OS X version of OpenOffice.org.

===Articles===
* [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Scrollbar Native Scrollbar] (2006-09-13)
* [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls] (2006-09-02)
* [http://wiki.services.openoffice.org/wiki/Intro_To_Mac_Porting Intro To Mac Porting] (2006-08-23)

===How did I become an OOo developer?===
I first joined the Mac OS X porting team as a member of the Google Summer of Code 2006 program. I spent my Summer learning about OOo' source code and VCL in particular. I was able to add the Fullscreen capability and worked on some geometrical shapes representation. After the end of the program I decided to keep contributing for two reasons. First it is very interesting and it gives me the opportunity of acquiring a valuable experience. Second it wouldn't have made sense to just stop after spending a lot of time learning the structure of VCL, the features of the Carbon API and how to use them.

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

Mac OS X Porting - Scrollbar

2006-09-14T02:22:43Z

Pdefilippis:

=Scrollbar=

==Contributors==
* Eric Bachard: [[User:Ericb|Ericb]]
* Pierre de Filippis: [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

==Introduction==
The purpose of this article is first to present our current knowledge of the implementation of scrollbars in the native Mac OS X version of OpenOffice.org and second to be a tutorial on how to create scrollbars with HITheme.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Conceptual/ProgAppearance_Manager/index.html Inside Carbon: Appearance Manager]
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
As stated on the Native Controls page, HITheme is the new version of the Appearance Manager. Apple is pushing developers to use it since they are not supporting the AE anymore. But to make the transition easy Apple made the HITheme API very close to the AE. For example both have functions with very similar name and both share the same constants. You can always refer back to the AE to find the list of these constants and use them in HITheme functions.

==

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

Mac OS X Porting - Scrollbar

2006-09-13T20:55:47Z

Pdefilippis:

=Native Controls=

==Contributors==
* Eric Bachard: [[User:Ericb|Ericb]]
* Pierre de Filippis: [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

==Introduction==
The purpose of this article is first to present our current knowledge of the implementation of scrollbars in the native Mac OS X version of OpenOffice.org and second to be a tutorial on how to create scrollbars with HITheme.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/Carbon/Conceptual/ProgAppearance_Manager/index.html Inside Carbon: Appearance Manager]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==

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

User:Ericb

2006-09-13T15:28:05Z

Pdefilippis: /* Important Links */

==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 ( Oliver Braun )

- 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|| || || || || ||
|-
|}

'''Other resources''' :

fonts: ?

events: ?

QA: ?

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|| || 1 || x || x || || || ||
|-
|Bundle|| || 1 || x || || || || | ||
|-
|Drawing|| || 1 || x || || || || || ||
|-
|Fonts|| || 1 || x || || || || || ||
|-
|Events management|| || 2 || x || || || || || ||
|-
|Controls (see list)||ericb, aliscafo || 2 || x || || || || || ||
|-
|Native FilePicker|| || 3 || x || x || || || || ||
|-
|Native Printing|| || 3 || x || || || || || ||
|-
|Native SpellChecker|| || 4 || || || || || || ||
|-
|Player|| || 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

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

===Todo===

1) define location and date
Easy to attend for all people coming
Some University ?
An airport close to the meeting is prefered

2) write a list of interested people

ericb
pjanik
obr
fheckl

[complete the list]

3) define needed resources

rooms for 10 to 20 people ( as cheap as possible)
Food ?
Hardware : 1 per workshop -> 4 machines would be great

4) Find money for travels, rooms and food

By plane ?
come together by car ?
Note : I'll propose the amount of money we need to Louis.

5) Location

not defined, but Pavel proposed CZ (Prague ? ) and fheckl has never been to Prague so it would be OK for him

[FIXME]

6) Duration

A weekend : e.g. Saturday 2nd / Sunday 3rd december 2006

7) Content

Common sessions / Workshops around native issues :

- windowing (salinst*)
- redrawing
- fonts
- controls
- native printing
- packaging
..etc (propose other)

===Agenda (can be modified)===

[FIXME] create an array ..

Saturday :

- Common session from 12:00 to 15:00

- Workshops : From 16:00 to 19:00

[Saturday evening : some dinner in the city ? ]

Sunday :

- Workshops from 10:00 to 12:00

- Conclusions from 13:00 to 14:00

Time to return after ...

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

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

==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 ?==

* 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

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

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

Work in progress : http://wiki.services.openoffice.org/wiki/Fonts_starting_point_and_documentation

* Implement native sound, using QuickTime (replacing Java Media Framework )

[[Native Sound Implementation on Mac OS X]]
(page under construction)

* Implement native Drag and drop, Implementing Pasteboard Manager

[[Native Drag and drop implementation on Mac OS X]] (page under construction)

* Implement Native Filepicker

* Implement Native Printing : current uses cups, but native printing is mandatory

[[Native Printing implementation on Mac OS X]] (page under construction)

* Implement Apple Spellchecker

=='''Where is the code located 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.

== '''Sort out 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 implementaion (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 ====

==== salatsuiutils ====

==== salfontutils ====

==== salmathutils ====

==== sal bmp ====

==== salvd ====

==== salframe ====

==== salpixmaputils====

==== salprn ====

====salrectangle====

==== salvd ====

=== Sal Window===

==== salframe ====

====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 ?

== 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''' '''[[Fonts starting point and documentation]]'''

'''Native Sound Implementation''' : http://wiki.services.openoffice.org/wiki/Native_Sound_Implementation_on_Mac_OS_X

'''Native Printing Implementation''' : http://wiki.services.openoffice.org/wiki/Native_Printing_implementation_on_Mac_OS_X

'''Drag and Drop implementation''' : http://wiki.services.openoffice.org/wiki/Native_Drag_and_drop_implementation_on_Mac_OS_X

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

'''Wish list for Mac OS X port''' : [[Mac OS X port : wish list]]

[to be continued :-) ]

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

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

User:Pdefilippis

2006-09-13T15:26:28Z

Pdefilippis: /* How did I become an OOo developer? */

===Developer ID===
* Name: Pierre de Filippis
* User ID: pdefilippis
* Blog: [http://aliscafo.blogspot.com/ http://aliscafo.blogspot.com/]
* Website: [http://www.aliscafo.com/ http://www.aliscafo.com/]
* IRC Nickname: aliscafo
* E-mail: [mailto:aliscafo@gmail.com aliscafo@gmail.com]

===Current Work===
I am working on the implementation of native controls for the native Mac OS X version of OpenOffice.org.

===Articles===
* [http://wiki.services.openoffice.org/wiki/Intro_To_Mac_Porting Intro To Mac Porting]
* [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls]
* Working of an article about creating scrollbars with HITheme and Appearance Manager

===How did I become an OOo developer?===
I first joined the Mac OS X porting team as a member of the Google Summer of Code 2006 program. I spent my Summer learning about OOo' source code and VCL in particular. I was able to add the Fullscreen capability and worked on some geometrical shapes representation. After the end of the program I decided to keep contributing for two reasons. First it is very interesting and it gives me the opportunity of acquiring a valuable experience. Second it wouldn't have made sense to just stop after spending a lot of time learning the structure of VCL, the features of the Carbon API and how to use them.

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

User:Pdefilippis

2006-09-13T15:24:00Z

Pdefilippis:

===Developer ID===
* Name: Pierre de Filippis
* User ID: pdefilippis
* Blog: [http://aliscafo.blogspot.com/ http://aliscafo.blogspot.com/]
* Website: [http://www.aliscafo.com/ http://www.aliscafo.com/]
* IRC Nickname: aliscafo
* E-mail: [mailto:aliscafo@gmail.com aliscafo@gmail.com]

===Current Work===
I am working on the implementation of native controls for the native Mac OS X version of OpenOffice.org.

===Articles===
* [http://wiki.services.openoffice.org/wiki/Intro_To_Mac_Porting Intro To Mac Porting]
* [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls]
* Working of an article about creating scrollbars with HITheme and Appearance Manager

===How did I become an OOo developer?===
I first joined the Mac OS X porting team as a member of the Google Summer of Code 2006 program. I spent my Summer learning about OOo' source code and VCL in particular. I was able to add the Fullscreen capability and worked on some geometrical shapes representation. After the end of the program I decided to keep contributing for two reasons. First it is very interesting and it gives me the opportunity of acquiring a valuable experience. Second it wouldn't have made sense to just stop after spending a lot of time learning the structure of VCL, the features of the Carbon API and how to use them.

User:Pdefilippis

2006-09-13T15:23:04Z

Pdefilippis:

===Developer ID===
* Name: Pierre de Filippis
* User ID: pdefilippis
* Blog: [http://aliscafo.blogspot.com/ http://aliscafo.blogspot.com/]
* IRC Nickname: aliscafo
* E-mail: [mailto:aliscafo@gmail.com aliscafo@gmail.com]

===Current Work===
I am working on the implementation of native controls for the native Mac OS X version of OpenOffice.org.

===Articles===
* [http://wiki.services.openoffice.org/wiki/Intro_To_Mac_Porting Intro To Mac Porting]
* [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls]
* Working of an article about creating scrollbars with HITheme and Appearance Manager

===How did I become an OOo developer?===
I first joined the Mac OS X porting team as a member of the Google Summer of Code 2006 program. I spent my Summer learning about OOo' source code and VCL in particular. I was able to add the Fullscreen capability and worked on some geometrical shapes representation. After the end of the program I decided to keep contributing for two reasons. First it is very interesting and it gives me the opportunity of acquiring a valuable experience. Second it wouldn't have made sense to just stop after spending a lot of time learning the structure of VCL, the features of the Carbon API and how to use them.

User:Pdefilippis

2006-09-13T15:21:47Z

Pdefilippis: /* How did I become an OOo developer? */

===Developer ID===
* Name: Pierre de Filippis
* User ID: pdefilippis
* Blog: [http://aliscafo.blogspot.com/]
* IRC Nickname: aliscafo
* E-mail: [mailto:aliscafo@gmail.com aliscafo@gmail.com]

===Current Work===
I am working on the implementation of native controls for the native Mac OS X version of OpenOffice.org.

===Articles===
* [http://wiki.services.openoffice.org/wiki/Intro_To_Mac_Porting Intro To Mac Porting]
* [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls]
* Working of an article about creating scrollbars with HITheme and Appearance Manager

===How did I become an OOo developer?===
I first joined the Mac OS X porting team as a member of the Google Summer of Code 2006 program. I spent my Summer learning about OOo' source code and VCL in particular. I was able to add the Fullscreen capability and worked on some geometrical shapes representation. After the end of the program I decided to keep contributing for two reasons. First it is very interesting and it gives me the opportunity of acquiring a valuable experience. Second it wouldn't have made sense to just stop after spending a lot of time learning the structure of VCL, the features of the Carbon API and how to use them.

User:Pdefilippis

2006-09-13T15:19:38Z

Pdefilippis:

===Developer ID===
* Name: Pierre de Filippis
* User ID: pdefilippis
* Blog: [http://aliscafo.blogspot.com/]
* IRC Nickname: aliscafo
* E-mail: [mailto:aliscafo@gmail.com aliscafo@gmail.com]

===Current Work===
I am working on the implementation of native controls for the native Mac OS X version of OpenOffice.org.

===Articles===
* [http://wiki.services.openoffice.org/wiki/Intro_To_Mac_Porting Intro To Mac Porting]
* [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls Native Controls]
* Working of an article about creating scrollbars with HITheme and Appearance Manager

===How did I become an OOo developer?===
I first joined the Mac OS X porting team as a member of the Google Summer of Code 2006 program. I spent my Summer learning about OOo' source code and VCL in particular. I was able to add the Fullscreen capability and worked on some geometrical shapes representation. After the end of the program I decided to keep contributing, first because it is very interesting and because I am acquiring a valuable experience and second because it wouldn't have made sense to just stop after spending a lot of time trying to understand how the VCL is structured and learning the features of the Carbon API and how to use them.

User:Pdefilippis

2006-09-13T15:04:07Z

Pdefilippis:

===Developer ID===
<pre>
Name: Pierre de Filippis
User ID: pdefilippis
Blog: [http://aliscafo.blogspot.com/]
IRC Nickname: aliscafo
E-mail: [mailto:aliscafo@gmail.com aliscafo@gmail.com]
</pre>

===Current Work===
I am working on the implementation of native controls for the native Mac OS X version of OpenOffice.org.

===Articles===
* [http://wiki.services.openoffice.org/wiki/Intro_To_Mac_Porting Intro To Mac Porting]
* [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Native_Controls]
* Working of an article about creating scrollbars with HITheme and Appearance Manager

===How did I become an OOo developer?===
I

Mac OS X Porting - Native Controls

2006-09-11T02:26:15Z

Pdefilippis: /* How a ScrollBar is drawn */

=Native Controls=

==Contributors==
* Eric Bachard: [[User:Ericb|Ericb]]
* Pierre de Filippis: [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]
* Pavel Janik
* Christian Lippka: [[User:CL|CL]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of HITheme.h: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': Boolean function. If the return value is TRUE, bIsInside contains information whether aPos was or not inside the native widget specified by the nType/nPart combination.
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===

Uses AquaSalGraphics class, defined in vcl/aqua/inc/salgdi.h. AquaSalGraphics itself inherits of SalGraphics virtual class (defined in vcl/inc/salgdi.hxx).

This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

Most of the stuff used in salnativewidgets.hxx are from HITheme.h (or Appearance.h for previous test)

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular OK, Cancel buttons.

===Radio Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular radio button.

===Check Box===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular check box.

===ScrollBar===
* Implemented by: [[User:Ericb|Ericb]]
This is the regular scrollbar.

====Current status====

=====How a ScrollBar is drawn=====
After printing out the part numbers passed to draw a ScrollBar, I found out how it is actually drawn out:
* 1. Part 101 - PART_BUTTON_UP
* 2. Part 102 - PART_BUTTON_DOWN
* 3. Part 211 - PART_THUMB_VERT
* 4. Part 201 - PART_TRACK_VERT_UPPER
* 5. Part 203 - PART_TRACK_VERT_LOWER

The first two parts are self-explanatory. The last 3 are a little more confusing at first especially since some heights and widths can be negative. But here is what they are.

=====Part 211=====
This part is the slider. As described by its value, it is vertical. The horizontal equivalent is part 210 - PART_THUMB_HORZ.

=====Part 201 - Part 203=====
These are the parts that are between the slider and the arrows. Part 201 is between the slider and the upper arrow. Part 203 is between the slider and the lower arrow. Each one of them can actually have a negative size in the case where the slider touches one or both of the arrows. The equivalents for a horizontal scrollbar are part 200 - PART_TRACK_HORZ_LEFT and part 202 - PART_TRACK_HORZ_RIGHT.

(10th September) Now the scrollbar is correctly drawn. Missing: always full (needs some work). modify the top control coordinates, manage active/not active.

Patch available here : http://eric.bachard.free.fr/mac/aquavcl/patches/controls/scrollbar/scrollbar10sept.diff

Screenshot :

http://eric.bachard.free.fr/mac/aquavcl/screenshots/scrollbar10sept/scrollbar10sept.jpg

(03rd September) Does not work as expected, work in progress to fix arrows issue, and obtain correct redrawing (arrows are correctly drawn, but not at good place). See screenshot:

[[Image:Scrollbar02_mini.jpg|200px|frame|center|Current state of native scrollbar]]

More to come...



==Current state of native controls==

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

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

Mac OS X Porting - Native Controls

2006-09-11T02:25:38Z

Pdefilippis: /* How a ScrollBar is drawn */

=Native Controls=

==Contributors==
* Eric Bachard: [[User:Ericb|Ericb]]
* Pierre de Filippis: [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]
* Pavel Janik
* Christian Lippka: [[User:CL|CL]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of HITheme.h: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': Boolean function. If the return value is TRUE, bIsInside contains information whether aPos was or not inside the native widget specified by the nType/nPart combination.
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===

Uses AquaSalGraphics class, defined in vcl/aqua/inc/salgdi.h. AquaSalGraphics itself inherits of SalGraphics virtual class (defined in vcl/inc/salgdi.hxx).

This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

Most of the stuff used in salnativewidgets.hxx are from HITheme.h (or Appearance.h for previous test)

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular OK, Cancel buttons.

===Radio Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular radio button.

===Check Box===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular check box.

===ScrollBar===
* Implemented by: [[User:Ericb|Ericb]]
This is the regular scrollbar.

====Current status====

=====How a ScrollBar is drawn=====
After printing out the part numbers passed to draw a ScrollBar. I found out how it is actually drawn out:
* 1. Part 101 - PART_BUTTON_UP
* 2. Part 102 - PART_BUTTON_DOWN
* 3. Part 211 - PART_THUMB_VERT
* 4. Part 201 - PART_TRACK_VERT_UPPER
* 5. Part 203 - PART_TRACK_VERT_LOWER

The first two parts are self-explanatory. The last 3 are a little more confusing at first especially since some heights and widths are negative. But here is what they are.

=====Part 211=====
This part is the slider. As described by its value, it is vertical. The horizontal equivalent is part 210 - PART_THUMB_HORZ.

=====Part 201 - Part 203=====
These are the parts that are between the slider and the arrows. Part 201 is between the slider and the upper arrow. Part 203 is between the slider and the lower arrow. Each one of them can actually have a negative size in the case where the slider touches one or both of the arrows. The equivalents for a horizontal scrollbar are part 200 - PART_TRACK_HORZ_LEFT and part 202 - PART_TRACK_HORZ_RIGHT.

(10th September) Now the scrollbar is correctly drawn. Missing: always full (needs some work). modify the top control coordinates, manage active/not active.

Patch available here : http://eric.bachard.free.fr/mac/aquavcl/patches/controls/scrollbar/scrollbar10sept.diff

Screenshot :

http://eric.bachard.free.fr/mac/aquavcl/screenshots/scrollbar10sept/scrollbar10sept.jpg

(03rd September) Does not work as expected, work in progress to fix arrows issue, and obtain correct redrawing (arrows are correctly drawn, but not at good place). See screenshot:

[[Image:Scrollbar02_mini.jpg|200px|frame|center|Current state of native scrollbar]]

More to come...



==Current state of native controls==

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

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

Mac OS X Porting - Native Controls

2006-09-11T02:25:01Z

Pdefilippis: /* ScrollBar */

=Native Controls=

==Contributors==
* Eric Bachard: [[User:Ericb|Ericb]]
* Pierre de Filippis: [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]
* Pavel Janik
* Christian Lippka: [[User:CL|CL]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of HITheme.h: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': Boolean function. If the return value is TRUE, bIsInside contains information whether aPos was or not inside the native widget specified by the nType/nPart combination.
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===

Uses AquaSalGraphics class, defined in vcl/aqua/inc/salgdi.h. AquaSalGraphics itself inherits of SalGraphics virtual class (defined in vcl/inc/salgdi.hxx).

This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

Most of the stuff used in salnativewidgets.hxx are from HITheme.h (or Appearance.h for previous test)

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular OK, Cancel buttons.

===Radio Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular radio button.

===Check Box===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular check box.

===ScrollBar===
* Implemented by: [[User:Ericb|Ericb]]
This is the regular scrollbar.

====Current status====

=====How a ScrollBar is drawn=====
After printing out the part numbers passed to draw a ScrollBar. I found out how it is actually drawn out:
* 1. Part 101 - PART_BUTTON_UP
* 2. Part 102 - PART_BUTTON_DOWN
* 3. Part 211 - PART_THUMB_VERT
* 4. Part 201 - PART_TRACK_VERT_UPPER
* 5. Part 203 - PART_TRACK_VERT_LOWER

The first two parts are self-explanatory. The last 3 are a little more confusing at first especially since some heights and widths are negative. But here is what they are.

'''Part 211'''
This part is the slider. As described by its value, it is vertical. The horizontal equivalent is part 210 - PART_THUMB_HORZ.

'''Part 201 - Part 203'''
These are the parts that are between the slider and the arrows. Part 201 is between the slider and the upper arrow. Part 203 is between the slider and the lower arrow. Each one of them can actually have a negative size in the case where the slider touches one or both of the arrows. The equivalents for a horizontal scrollbar are part 200 - PART_TRACK_HORZ_LEFT and part 202 - PART_TRACK_HORZ_RIGHT.

(10th September) Now the scrollbar is correctly drawn. Missing: always full (needs some work). modify the top control coordinates, manage active/not active.

Patch available here : http://eric.bachard.free.fr/mac/aquavcl/patches/controls/scrollbar/scrollbar10sept.diff

Screenshot :

http://eric.bachard.free.fr/mac/aquavcl/screenshots/scrollbar10sept/scrollbar10sept.jpg

(03rd September) Does not work as expected, work in progress to fix arrows issue, and obtain correct redrawing (arrows are correctly drawn, but not at good place). See screenshot:

[[Image:Scrollbar02_mini.jpg|200px|frame|center|Current state of native scrollbar]]

More to come...



==Current state of native controls==

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

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

Mac OS X Porting - Native Controls

2006-09-03T15:12:35Z

Pdefilippis: /* Contributors */

=Native Controls=

==Contributors==
* Eric Bachard: [[User:Ericb|Ericb]]
* Pierre de Filippis: [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]
* Pavel Janik
* Christian Lippka: [[User:CL|CL]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of HITheme.h: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': Boolean function. If the return value is TRUE, bIsInside contains information whether aPos was or not inside the native widget specified by the nType/nPart combination.
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===

Uses AquaSalGraphics class, defined in vcl/aqua/inc/salgdi.h. AquaSalGraphics itself inherits of SalGraphics virtual class (defined in vcl/inc/salgdi.hxx).

This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

Most of the stuff used in salnativewidgets.hxx are from HITheme.h (or Appearance.h for previous test)

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular OK, Cancel buttons.

===Radio Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular radio button.

===Check Box===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular check box.

===ScrollBar===
* Implemented by: [[User:Ericb|Ericb]]
This is the regular scrollbar.

====Current status====
Does not work as expected, work in progress to fix arrows issue, and obtain correct redrawing (arrows are correctly drawn, but not at good place). See screenshot:

[[Image:Scrollbar02_mini.jpg|200px|frame|center|Current state of native scrollbar]]

More to come...



==Current state of native controls==

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

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

Mac OS X Porting - Native Controls

2006-09-03T14:45:14Z

Pdefilippis: /* Contributors */

=Native Controls=

==Contributors==
* Eric Bachard: [[User:Ericb|Ericb]]
* Pierre de Filippis: [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]
* Christian Lippka: [[User:CL|CL]]
* Pavel Janik

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of HITheme.h: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': Boolean function. If the return value is TRUE, bIsInside contains information whether aPos was or not inside the native widget specified by the nType/nPart combination.
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===

Uses AquaSalGraphics class, defined in vcl/aqua/inc/salgdi.h. AquaSalGraphics itself inherits of SalGraphics virtual class (defined in vcl/inc/salgdi.hxx).

This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

Most of the stuff used in salnativewidgets.hxx are from HITheme.h (or Appearance.h for previous test)

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular OK, Cancel buttons.

===Radio Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular radio button.

===Check Box===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular check box.

===ScrollBar===
* Implemented by: [[User:Ericb|Ericb]]
This is the regular scrollbar.

====Current status====
Does not work as expected, work in progress to fix arrows issue, and obtain correct redrawing (arrows are correctly drawn, but not at good place). See screenshot:

[[Image:Scrollbar02_mini.jpg|200px|frame|center|Current state of native scrollbar]]

More to come...



==Current state of native controls==

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

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

Mac OS X Porting - Native Controls

2006-09-03T14:43:47Z

Pdefilippis: /* Native Controls */

=Native Controls=

==Contributors==
* [[User:Ericb|Ericb]]
* [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of HITheme.h: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': Boolean function. If the return value is TRUE, bIsInside contains information whether aPos was or not inside the native widget specified by the nType/nPart combination.
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===

Uses AquaSalGraphics class, defined in vcl/aqua/inc/salgdi.h. AquaSalGraphics itself inherits of SalGraphics virtual class (defined in vcl/inc/salgdi.hxx).

This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

Most of the stuff used in salnativewidgets.hxx are from HITheme.h (or Appearance.h for previous test)

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular OK, Cancel buttons.

===Radio Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular radio button.

===Check Box===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular check box.

===ScrollBar===
* Implemented by: [[User:Ericb|Ericb]]
This is the regular scrollbar.

====Current status====
Does not work as expected, work in progress to fix arrows issue, and obtain correct redrawing (arrows are correctly drawn, but not at good place). See screenshot:

[[Image:Scrollbar02_mini.jpg|200px|frame|center|Current state of native scrollbar]]

More to come...



==Current state of native controls==

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

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

Mac OS X Porting - Native Controls

2006-09-03T14:42:10Z

Pdefilippis: /* The native controls and the implementation */

=Native Controls=

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of HITheme.h: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': Boolean function. If the return value is TRUE, bIsInside contains information whether aPos was or not inside the native widget specified by the nType/nPart combination.
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===

Uses AquaSalGraphics class, defined in vcl/aqua/inc/salgdi.h. AquaSalGraphics itself inherits of SalGraphics virtual class (defined in vcl/inc/salgdi.hxx).

This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

Most of the stuff used in salnativewidgets.hxx are from HITheme.h (or Appearance.h for previous test)

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular OK, Cancel buttons.

===Radio Button===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular radio button.

===Check Box===
* Implemented by: [[User:Pdefilippis|Pdefilippis]]
This is the regular check box.

===ScrollBar===
* Implemented by: [[User:Ericb|Ericb]]
This is the regular scrollbar.

====Current status====
Does not work as expected, work in progress to fix arrows issue, and obtain correct redrawing (arrows are correctly drawn, but not at good place). See screenshot:

[[Image:Scrollbar02_mini.jpg|200px|frame|center|Current state of native scrollbar]]

More to come...



==Current state of native controls==

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-03T14:40:38Z

Pdefilippis: /* The native controls and the implementation */

=Native Controls=

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of HITheme.h: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': Boolean function. If the return value is TRUE, bIsInside contains information whether aPos was or not inside the native widget specified by the nType/nPart combination.
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===

Uses AquaSalGraphics class, defined in vcl/aqua/inc/salgdi.h. AquaSalGraphics itself inherits of SalGraphics virtual class (defined in vcl/inc/salgdi.hxx).

This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

Most of the stuff used in salnativewidgets.hxx are from HITheme.h (or Appearance.h for previous test)

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

===ScrollBar===
* Implemented by: [[User:Ericb|Ericb]]
This is the regular scrollbar.

====Current status====
Does not work as expected, work in progress to fix arrows issue, and obtain correct redrawing (arrows are correctly drawn, but not at good place). See screenshot:

[[Image:Scrollbar02_mini.jpg|200px|frame|center|Current state of native scrollbar]]

More to come...



==Current state of native controls==

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-03T14:39:45Z

Pdefilippis: /* ScrollBar */

=Native Controls=

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of HITheme.h: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': Boolean function. If the return value is TRUE, bIsInside contains information whether aPos was or not inside the native widget specified by the nType/nPart combination.
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===

Uses AquaSalGraphics class, defined in vcl/aqua/inc/salgdi.h. AquaSalGraphics itself inherits of SalGraphics virtual class (defined in vcl/inc/salgdi.hxx).

This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

Most of the stuff used in salnativewidgets.hxx are from HITheme.h (or Appearance.h for previous test)

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

===ScrollBar===
* Implemented by: [[User:Ericb|Ericb]]
This is the regular scrollbar.

====Current status====
Does not work as expected, work in progress to fix arrows issue, and obtain correct redrawing (arrows are correctly drawn, but not at good place). See screenshot:

[[Image:Scrollbar02_mini.jpg|200px|frame|center|Current state of native scrollbar]]

More to come...



[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-03T14:38:32Z

Pdefilippis: /* The native controls and the implementation */

=Native Controls=

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of HITheme.h: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': Boolean function. If the return value is TRUE, bIsInside contains information whether aPos was or not inside the native widget specified by the nType/nPart combination.
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===

Uses AquaSalGraphics class, defined in vcl/aqua/inc/salgdi.h. AquaSalGraphics itself inherits of SalGraphics virtual class (defined in vcl/inc/salgdi.hxx).

This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

Most of the stuff used in salnativewidgets.hxx are from HITheme.h (or Appearance.h for previous test)

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

===ScrollBar===
* Implemented by: [[User:Ericb|Ericb]]
This is the regular scrollbar (see screenshot)

[[Image:Scrollbar02_mini.jpg|200px|frame|center|Current state of native scrollbar]]

====Current status====
Does not work as expected, work in progress to fix arrows issue, and obtain correct redrawing (arrows are correctly drawn, but not at good place).

More to come...



[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-03T01:56:07Z

Pdefilippis: /* Using HITheme */

=Native Controls=

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of hitheme.h: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': [TO DO]
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===
This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

More to come...



-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-03T01:40:26Z

Pdefilippis: /* Using HITheme */

=Native Controls=

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of hitheme.h:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': [TO DO]
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===
This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

More to come...



-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-03T01:40:10Z

Pdefilippis: /* Using HITheme */

=Native Controls=

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of hitheme.h:
/Volumes/Macintosh HD/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': [TO DO]
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===
This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

More to come...



-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-03T01:39:30Z

Pdefilippis: /* Using HITheme */

=Native Controls=

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

* Location of hitheme.h: :/Volumes/Macintosh HD/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/HITheme.h

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': [TO DO]
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===
This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

More to come...



-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-02T22:27:53Z

Pdefilippis: /* Native Controls */

=Native Controls=

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/2006-09-01.png Bigger Version]]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': [TO DO]
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===
This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

More to come...



-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-02T22:11:54Z

Pdefilippis: /* Current state */

=Native Controls=

[[Image:nativectrlsvtools.jpg|200px|frame|center|Current state of native controls. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/08-23-06-01.png Bigger Version]]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': [TO DO]
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===
This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

More to come...



-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-02T22:11:12Z

Pdefilippis: /* Pictures of the current state */

=Native Controls=

==Current state==

[[Image:nativectrlsvtools.jpg|200px|frame|center|The svdem application in svtools. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/08-23-06-01.png Bigger Version]]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': [TO DO]
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===
This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

More to come...



-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-02T22:10:43Z

Pdefilippis:

=Native Controls=

==Current state==

[[Image:nativectrlsvtools.jpg|200px|frame|center|The svdem application in svtools. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/08-23-06-01.png Bigger Version]]]

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': [TO DO]
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===
This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

More to come...



==Pictures of the current state==

[[Image:nativectrlsvtools.jpg|200px|frame|center|The svdem application in svtools. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/08-23-06-01.png Bigger Version]]]

-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-02T22:01:39Z

Pdefilippis: /* Pictures of the current state */

=Native Controls=

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': [TO DO]
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===
This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

More to come...



==Pictures of the current state==

[[Image:nativectrlsvtools.jpg|200px|frame|center|The svdem application in svtools. [http://photos1.blogger.com/blogger2/3622/26233778049693/1600/08-23-06-01.png Bigger Version]]]

-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-02T21:57:11Z

Pdefilippis:

=Native Controls=

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': [TO DO]
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===
This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

==The native controls and the implementation==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

More to come...



==Pictures of the current state==

-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-02T21:55:43Z

Pdefilippis: /* List of all the controls to change + pictures (VCL<->Apple) equivalent */

=Native Controls=

==Introduction==
The purpose of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org. Our goal by implementing native controls is to remove the win32 look as much as possible and replace it by the Aqua look and feel using the Carbon API.

==Apple Documentation and References==
* [http://developer.apple.com/documentation/Carbon/Reference/Appearance_Manager/index.html Appearance Manager Reference]
* [http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html Apple Human Interface Guidelines]

==The Appearance Manager and HITheme==
Apple provides an easy way to change a custom user interface to an aqua interface by using the Appearance Manager(AM). This API was first developed for Mac OS 8 and is centered around QuickDraw. The AM is less and less supported by Apple since 10.2 and any implementation needs to be replaced with the [http://developer.apple.com/referencelibrary/Carbon/idxHumanInterfaceToolbox-date.html HIToolbox] version: HITheme. The problem with HITheme is that its implementation started on Mac OS X 10.2 (Jaguar) and has since gone under many revisions and new functions have been progressively added with each new version of OS X. Therefore some functions in the 10.4 version might not be in 10.3 or 10.2. This will probably be one of the reason why the native version of OpenOffice.org will run on Mac OS X 10.4 and higher only.

===Using HITheme===
Unfortunately there is not much documentation provided by Apple about HITheme. Thus we have to look at the HITheme.h header file directly and read the extensive comments to understand how to use this API. All the constants used to describe the type of controls that we want to implement is still the same as in the AM. This is the reason why the AM reference document is still useful and should always be opened when implementing native controls. The AM and HITheme are very similar in the way they approach the implementation of native controls, most of the time the functions have similar names and the arguments different types so you can always use the AM reference to give you an idea about the procedure to follow.

==Native controls in VCL==

[[Image:Controls.jpg|frame|center|Native Controls Files in VCL]]

===salnativewidgets.cxx===
This file was copied directly from the Windows implementation of native controls. All the useless functions were removed and we are left with 6 functions:

* '''isNativeControlSupported''': function called to see if a control should be implemented natively or not. A big switch statement that goes through all the controls and part of controls possible. Returns true when a control is supported. Each time a new control is implemented this function should be modified so the new native code is used at compile time.
* '''hitTestNativeControl''': [TO DO]
* '''getState''': a translation from the VCL constants to the Carbon constants of the state of controls.
* '''drawNativeControl''': the most important function. This is where the code for new native controls is written. Again it is a big switch statment that lists each control with the corresponding implementation. Needs to be modified each time a new control is implemented.
* '''drawNativeControlText''': [TO DO]
* '''getNativeControlRegion''': [TO DO]

===salnativewidgets.hxx===
This header file describes all the structures, classes and constants used to get the state and properties of the VCL controls. It is necessary to be familiar with this file since its content will be used to translate the state and properties to their Carbon equivalent.

==All the controls==
Here is a list of all the controls that need to be native. Since some of them do not have the same name in VCL and Carbon, they are listed in this format: <VCL name> - <Carbon name> when they are different.

===Push Button===
This is the regular OK, Cancel buttons.

===Radio Button===
This is the regular radio button.

===Check Box===
This is the regular check box.

More to come...



==To do==
==Pictures of the current state==

-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-02T21:40:03Z

Pdefilippis: /* salnativewidgets.cxx */

Mac OS X Porting - Native Controls

2006-09-02T21:39:39Z

Pdefilippis:

Mac OS X Porting - Native Controls

2006-09-02T21:26:39Z

Pdefilippis: /* Overview of the Files that we need to deal with + graph */

File:Controls.jpg

2006-09-02T21:25:20Z

Pdefilippis: Graph representing the path to the files for native controls

Graph representing the path to the files for native controls

Mac OS X Porting - Native Controls

2006-09-02T20:24:45Z

Pdefilippis: /* The Appearance Manager and HITheme */

Mac OS X Porting - Native Controls

2006-09-02T19:29:28Z

Pdefilippis: /* The Appearance Manager and HITheme */

Mac OS X Porting - Native Controls

2006-09-02T19:11:13Z

Pdefilippis: /* Tradeoff between the Appearance Manager and HITheme */

Mac OS X Porting - Native Controls

2006-09-02T19:09:36Z

Pdefilippis: /* Tradeoff between the Appearance Manager and HITheme */

Mac OS X Porting - Native Controls

2006-09-02T19:03:29Z

Pdefilippis: /* Tradeoff between the Appearance Manager and HITheme */

Mac OS X Porting - Native Controls

2006-09-02T18:58:59Z

Pdefilippis:

Mac OS X Porting - Native Controls

2006-09-02T18:33:09Z

Pdefilippis: /* Introduction */

Mac OS X Porting - Native Controls

2006-09-02T18:32:10Z

Pdefilippis:

Mac OS X Porting - Native Controls

2006-09-02T18:24:41Z

Pdefilippis:

=Native Controls=

==Introduction==
The goal of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org.

==Overview of the Files that we need to deal with + graph==
==Overview of the Apple documentation that we need==
==List of all the controls to change + pictures (VCL<->Apple) equivalent==
==To do==
==Pictures of the current state==

-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-02T18:16:54Z

Pdefilippis:

=Native Controls=

==Introduction==
The goal of this article is to present our current knowledge and progress of the implementation of native controls in the native Mac OS X version of OpenOffice.org.

-- [[User:Pdefilippis|Pdefilippis]] [mailto:aliscafo@gmail.com aliscafo@gmail.com]

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

Mac OS X Porting - Native Controls

2006-09-02T18:16:25Z

Pdefilippis: