Difference between revisions of "User:Ericb"
(→'''Sort out documentation about VCL around Native Mac OS X port''') |
m (fix spaces) |
||
Line 20: | Line 20: | ||
==='''2006'''=== | ==='''2006'''=== | ||
− | * | + | * June 2006: work in progress |
− | - Basis : frame, instances, threads, drawing, painting, resizing (Stephan Schaefer, Tino Rachui ) | + | - Basis: frame, instances, threads, drawing, painting, resizing (Stephan Schaefer, Tino Rachui) |
− | Done : | + | Done: |
implement threads | implement threads | ||
create, manage instance | create, manage instance | ||
− | create, manage windows ( including parents) | + | create, manage windows (including parents) |
create, manage events | create, manage events | ||
create manage drawing, resizing | create manage drawing, resizing | ||
− | create, add menus ( Pavel Janik ) | + | create, add menus (Pavel Janik) |
− | toggle window fullscreen( Pierre de Filippis ) | + | toggle window fullscreen (Pierre de Filippis) |
− | make font server work (Stephan Schaefer ) | + | make font server work (Stephan Schaefer) |
* Current status font support (Stephan Schaefer, 2006/07/28): the following features are basically working now | * Current status font support (Stephan Schaefer, 2006/07/28): the following features are basically working now | ||
Line 39: | Line 39: | ||
** simple font attributes (bold, italic) | ** simple font attributes (bold, italic) | ||
− | Next step : | + | Next step: document first part, and propose design |
− | - native filepicker ( Oliver Braun ) | + | - native filepicker (Oliver Braun) |
− | - native printing implementation | + | - native printing implementation (Oliver?) |
− | - native font implementation | + | - native font implementation (Eric Bachard) |
− | * September 2006 : | + | * September 2006: |
− | - first proofs of concept : | + | - first proofs of concept: fonts, filepicker .. (more?) |
− | - show the results ( OOoCon 2006 ? ) | + | - show the results (OOoCon 2006?) |
==='''2007'''=== | ==='''2007'''=== | ||
− | * January 2007 : first alpha implementation | + | * January 2007: first alpha implementation |
=='''Strategy for native port'''== | =='''Strategy for native port'''== | ||
Line 60: | Line 60: | ||
'''Possible Actions''': | '''Possible Actions''': | ||
− | Identify us : | + | Identify us: |
#Complete the arrays below | #Complete the arrays below | ||
− | #Update photos on frapr.com | + | #Update photos on frapr.com? |
− | Share the work : | + | Share the work: |
#Divide the work between little Teams | #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] | #Update Todo list regularly -> needs some love these days ... [http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s] | ||
− | Help : | + | Help: |
#Teach tools between us | #Teach tools between us | ||
Line 76: | Line 76: | ||
#write documentation | #write documentation | ||
− | Meet us : | + | Meet us: |
#IRC | #IRC | ||
− | #Mac Meeting | + | #Mac Meeting (like nov2005 in Hamburg?) |
Inform: | Inform: | ||
Line 87: | Line 87: | ||
− | '''WHO''' : | + | '''WHO''': |
− | Mac Team : | + | Mac Team: |
{| style="vertical-align:top; text-align:left; background-color:#efefef;" | {| style="vertical-align:top; text-align:left; background-color:#efefef;" | ||
Line 95: | Line 95: | ||
|Developer \ skills || build || write code || code review || debug/trace (higher is better) || contribute to documentation || | |Developer \ skills || build || write code || code review || debug/trace (higher is better) || contribute to documentation || | ||
|- | |- | ||
− | |ericb|| x || x || | + | |ericb|| x || x || || 1 || x || |
|- | |- | ||
− | |pjanik|| | + | |pjanik|| || || || || || |
|- | |- | ||
− | |ssa|| | + | |ssa|| || || || || || |
|- | |- | ||
− | |maho|| | + | |maho|| || || || || || |
|- | |- | ||
− | |tinor|| | + | |tinor|| || || || || || |
|- | |- | ||
− | |schmidtm|| | + | |schmidtm|| || || || || || |
|- | |- | ||
− | |ebischoff|| | + | |ebischoff|| || || || || || |
|- | |- | ||
− | |obr|| | + | |obr|| || || || || || |
|- | |- | ||
− | |cl|| | + | |cl|| || || || || || |
|- | |- | ||
− | |aliscafo|| | + | |aliscafo|| || || || || || |
|- | |- | ||
− | |fheckl|| | + | |fheckl|| || || || || || |
|- | |- | ||
− | |Fridrich|| | + | |Fridrich|| || || || || || |
|- | |- | ||
|} | |} | ||
− | '''Other resources''' : | + | '''Other resources''': |
fonts: ? | fonts: ? | ||
Line 136: | Line 136: | ||
− | '''WHAT''' : Status of most important tasks | + | '''WHAT''': Status of most important tasks |
{| style="vertical-align:top; text-align:left; background-color:#efefef;" | {| style="vertical-align:top; text-align:left; background-color:#efefef;" | ||
Line 146: | Line 146: | ||
|Bundle|| || 1 || x || || || || | || | |Bundle|| || 1 || x || || || || | || | ||
|- | |- | ||
− | |Drawing|| || 1 || x || | + | |Drawing|| || 1 || x || || || || || || |
|- | |- | ||
− | |Fonts|| || 1 || x || | + | |Fonts|| || 1 || x || || || || || || |
|- | |- | ||
− | |Events management|| || 2 || x || | + | |Events management|| || 2 || x || || || || || || |
|- | |- | ||
− | |Controls (see list)||ericb, aliscafo || 2 || x || | + | |Controls (see list) ||ericb, aliscafo || 2 || x || || || || || || |
|- | |- | ||
|Native FilePicker|| || 3 || x || x || || || || || | |Native FilePicker|| || 3 || x || x || || || || || | ||
|- | |- | ||
− | |Native Printing|| || 3 || x || | + | |Native Printing|| || 3 || x || || || || || || |
|- | |- | ||
− | |Native SpellChecker|| || 4 || | + | |Native SpellChecker|| || 4 || || || || || || || |
|- | |- | ||
− | |Player|| || 4 || x || | + | |Player|| || 4 || x || || || || || || |
|} | |} | ||
− | Other tasks : | + | Other tasks: |
Help for writing bug lists, status of bugs ..etc | Help for writing bug lists, status of bugs ..etc | ||
Line 172: | Line 172: | ||
'''WHEN''': | '''WHEN''': | ||
− | From Christian Lippka (last meeting, 25th of august 2006) : | + | 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, | + | 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 | fixing repaint issues, having aqua install and run out of the box | ||
Line 184: | Line 186: | ||
fix OpenOffice.org launch | fix OpenOffice.org launch | ||
fix drawing (repainting) | fix drawing (repainting) | ||
− | Implement missing methods and fix most important bugs (mainly the one leading to crash) in : | + | Implement missing methods and fix most important bugs (mainly the one leading to crash) in: |
ATS | ATS | ||
Salgraphics | Salgraphics | ||
Line 207: | Line 209: | ||
1) define location and date | 1) define location and date | ||
Easy to attend for all people coming | Easy to attend for all people coming | ||
− | Some University ? | + | Some University? |
An airport close to the meeting is prefered | An airport close to the meeting is prefered | ||
Line 221: | Line 223: | ||
3) define needed resources | 3) define needed resources | ||
− | rooms for 10 to 20 people ( as cheap as possible) | + | rooms for 10 to 20 people (as cheap as possible) |
− | Food ? | + | Food? |
− | Hardware : | + | Hardware: 1 per workshop -> 4 machines would be great |
4) Find money for travels, rooms and food | 4) Find money for travels, rooms and food | ||
− | By plane ? | + | By plane? |
− | come together by car ? | + | come together by car? |
− | Note : I'll propose the amount of money we need to Louis. | + | Note: I'll propose the amount of money we need to Louis. |
5) Location | 5) Location | ||
− | not defined, but Pavel proposed CZ (Prague ? ) and fheckl has never been to Prague so it would be OK for him | + | not defined, but Pavel proposed CZ (Prague?) and fheckl has never been to Prague so it would be OK for him |
[FIXME] | [FIXME] | ||
− | 6) Duration | + | 6) Duration |
− | A weekend : e.g. Saturday 2nd | + | A weekend: e.g. Saturday 2nd / Sunday 3rd december 2006 |
7) Content | 7) Content | ||
− | Common sessions / Workshops around native issues : | + | Common sessions / Workshops around native issues: |
- windowing (salinst*) | - windowing (salinst*) | ||
Line 259: | Line 261: | ||
− | Saturday : | + | Saturday: |
- Common session from 12:00 to 15:00 | - Common session from 12:00 to 15:00 | ||
− | - Workshops : From 16:00 to 19:00 | + | - Workshops: From 16:00 to 19:00 |
− | [Saturday evening : | + | [Saturday evening: some dinner in the city? ] |
− | Sunday : | + | Sunday: |
- Workshops from 10:00 to 12:00 | - Workshops from 10:00 to 12:00 | ||
Line 282: | Line 284: | ||
==Description of the Native Port problem== | ==Description of the Native Port problem== | ||
− | === How does OpenOffice.org work on Mac OS X ? === | + | === 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. | + | 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. | - 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, | - 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. | 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. | ||
Line 298: | Line 300: | ||
All events are managed by OpenOffice.org and X11, using the Xlib | All events are managed by OpenOffice.org and X11, using the Xlib | ||
− | Only .ttf fonts type is currently available. Note : '''system fonts are available ''' | + | 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. | 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) | + | 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 ==== | ==== Other links ==== | ||
Line 312: | Line 314: | ||
[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST) | [[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST) | ||
− | == What do we have to do ?== | + | == What do we have to do?== |
− | * Implement direct access to Apple graphical engine, | + | * 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 | + | like: instantiate, manage events and threads for a graphical instance + all needed objects, drawing: manage all drawing cases |
− | * Implement native events management, using CarbonEventManager | + | * 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 ) | + | * 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 | + | Work in progress: http://wiki.services.openoffice.org/wiki/Fonts_starting_point_and_documentation |
− | * Implement native sound, using QuickTime (replacing Java Media Framework ): [[Mac OS X Porting - Native Audio and Video]] | + | * Implement native sound, using QuickTime (replacing Java Media Framework): [[Mac OS X Porting - Native Audio and Video]] |
− | * Implement native Drag and drop, | + | * Implement native Drag and drop, Implementing Pasteboard Manager: [[Mac OS X Porting - Native Drag and drop]] |
* Implement Native Filepicker | * Implement Native Filepicker | ||
− | * Implement Native Printing : current uses cups, but native printing is mandatory: [[Mac OS X Porting - Native_Printing]] | + | * Implement Native Printing: current uses cups, but native printing is mandatory: [[Mac OS X Porting - Native_Printing]] |
* Implement Apple Spellchecker | * Implement Apple Spellchecker | ||
− | =='''Where is located the code to be modified ?'''== | + | =='''Where is located the code to be modified?'''== |
− | Most of the changes are located in vcl ( Visual Class Layer ), for everything graphical, events, fonts, rendering and printing. | + | 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). | + | 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 ) | + | For drag and drop, dtrans is concerned (Pasteboard Manager implementation) |
− | [FIXME] : Filepicker ? Apple Spellchecker ? | + | [FIXME]: Filepicker? Apple Spellchecker? |
[[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST) | [[User:Ericb|Ericb]] 11:39, 3 June 2006 (CEST) | ||
− | =='''How will the new implementation be tested ?== | + | =='''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, | Currently, all openOffice.org code can be compiled without using the Xlib. but of course, a lot of features are missing, | ||
Line 352: | Line 354: | ||
and the final package simply won't work | and the final package simply won't work | ||
− | In vcl module", a '''toy''' called svdem is built at buildtime. | + | 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. | + | 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. | Everything implemented in aqua vcl code will be included in libvclplug_aqua, and svdem source code will contain a specific part to proceed tests. | ||
Line 360: | Line 362: | ||
<div class="messagebox cleanup metadata" style="border:1px solid blue;background-color:#B3FFF5;padding:7px;"> | <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 !!''' | + | '''The magic is: when all needed features will work with svdem, it will work in the new version of OpenOffice.org !!''' |
</div> | </div> | ||
Line 366: | Line 368: | ||
− | [FIXME] : add more complete list of features to implement and test. | + | [FIXME]: add more complete list of features to implement and test. |
== '''Sort of documentation about VCL around Native Mac OS X port''' == | == '''Sort of documentation about VCL around Native Mac OS X port''' == | ||
− | Do we really need to understand how it works ? | + | Do we really need to understand how it works? ;-) |
− | vcl content : | + | vcl content: |
ls -laR | wc -l | ls -laR | wc -l | ||
− | + | 1750 | |
− | -> Uff 1750 files to analyse | + | -> 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. | 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 ? | + | 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. |
[UPDATE] After some investigations, the use of Design patterns seems to be the most efficient approach to describe vcl. Will try to do so asap. | [UPDATE] After some investigations, the use of Design patterns seems to be the most efficient approach to describe vcl. Will try to do so asap. | ||
Line 389: | Line 391: | ||
[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". | [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". | + | 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. | 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 ? | + | 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 === | === VCL organisation === | ||
− | Thank's to Philipp Lohmann for this short, but precise description : | + | 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.). | 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.). | ||
Line 421: | Line 423: | ||
SalI18NImeStatus handles how the status window of an Input Method Editor (IME) should display (this is mainly X11 specific). | 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 :-) | + | 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. | 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. | ||
Line 437: | Line 439: | ||
==== '''Directories in vcl. Short description''' ==== | ==== '''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] | + | ''' 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 ''' : | + | ''' 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 | ''' 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). | + | '''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. | 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. | + | ''' 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. | 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. | + | ''' 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. | + | ''' 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 | + | '''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 ... :) ) | + | - display a window first (al least ...:)) |
- close cleanly this window | - close cleanly this window | ||
Line 485: | Line 487: | ||
To increase readability, it's recommended to closely follow the base class name. | 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. | + | * '''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 | + | '''[[ 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 | - do not freeze because bad event loops | ||
− | - event types implementation : currently, they are defined in vcl/aqua/inc/aquavclevents.hxx | + | - 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. | + | 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 ?'''== | + | == '''What do we have to build in vcl?'''== |
Two libraries, corresponding ressources (localized) and a toy so called « svdem » | Two libraries, corresponding ressources (localized) and a toy so called « svdem » | ||
− | '''Common part''' : | + | '''Common part''': |
− | in grey on right. | + | 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 | + | '''Specific part " a plugin " ''': |
− | Light yellow : aqua part will only concern Mac OS X (non X11) the name will probably be | + | 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 | As you can see, win means windows part, in blue | ||
− | For Unix build ( Linux, Solaris or current Mac OS X X11), in purple. | + | For Unix build (Linux, Solaris or current Mac OS X X11), in purple. |
− | Result will be : | + | 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). | + | 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 : | + | 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". | + | '''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 === | === Current Aqua content === | ||
− | A more complete description of aqua (Mac OS X / no X11 specific ) : [[Image:Vcl_aqua_organisation_02_tree.jpg]] | + | 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== | ==EXISTING objects to build in aqua== | ||
− | ===Sal APP | + | ===Sal APP "everything application"=== |
[FIXME] add all objects descriptions | [FIXME] add all objects descriptions | ||
Line 536: | Line 538: | ||
* '''Defined in plugin exclusively''' (i.e. for headers) | * '''Defined in plugin exclusively''' (i.e. for headers) | ||
− | Unix : unx/source/app/saldata.cxx (header in unx/inc ) | + | Unix: unx/source/app/saldata.cxx (header in unx/inc) |
− | '''Aqua : aqua/source/app/saldata.cxx (header in win/inc )''' | + | '''Aqua: aqua/source/app/saldata.cxx (header in win/inc)''' |
− | Windows : win/source/app/saldata.cxx (header in aqua/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''' | + | * 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. | 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 ) | + | '''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. | + | 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. | + | [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 | + | saldatax.cxx uses classes SalInstance, SalObject, SalFrame, SalVirtualDevice, SalPrinter and fontList. |
− | Current list of possible objects who can be instantiated/released : | + | 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. | + | structure SalData: does contain pointers on all kind of objects from other classes used in saldata. |
− | inline functions : [FIXME] : complete the description | + | inline functions: [FIXME]: complete the description |
− | - SetSalData : | + | - SetSalData: |
− | - GetSalData : | + | - GetSalData: |
− | - GetAppSalData : | + | - GetAppSalData: |
==== salinst ==== | ==== salinst ==== | ||
Line 571: | Line 573: | ||
Role: | Role: | ||
− | * get environment, mutexes, instantiate AquaSalInstance (Ctor, Dtor ), | + | * get environment, mutexes, instantiate AquaSalInstance (Ctor, Dtor), |
− | * instantiates/releases a lot of other objects using Get( ) / CreateObject() / DestroyObject() methods. | + | * instantiates/releases a lot of other objects using Get() / CreateObject() / DestroyObject() methods. |
− | Current list of possible objects who can be instantiated/released : | + | Current list of possible objects who can be instantiated/released: |
− | * VirtualDevice [FIXME] : exact role ? | + | * VirtualDevice [FIXME]: exact role? |
− | *Printer | + | *Printer |
− | - | + | - GetDefaultPrinter/ CreatePrinter() / DestroyPrinter - what a name ;-) - |
− | - InfoPrinter ( Get/Create/Delete ) | + | - InfoPrinter (Get/Create/Delete) |
− | - PrinterQueue ( DeletePrinterQueueInfo / GetPrinterQueueInfo / GetPrinterQueueState ) | + | - PrinterQueue (DeletePrinterQueueInfo / GetPrinterQueueInfo / GetPrinterQueueState) |
− | * System ( Create / Delete ) | + | * System (Create / Delete) [FIXME]: what means system here? |
− | * Events : | + | * Events: |
− | AquaSalInstance::SetEventCallback( ) | + | AquaSalInstance::SetEventCallback() |
− | AquaSalInstance::SetErrorEvenCallback( ) | + | AquaSalInstance::SetErrorEvenCallback() |
− | AquaSalInstance::GetConnectionIdentifier( ) | + | AquaSalInstance::GetConnectionIdentifier() |
− | * Menu / MenuItem : | + | * Menu / MenuItem: |
− | AquaSalInstance::CreateMenu( ) / same for DestroyMenu( ) | + | AquaSalInstance::CreateMenu() / same for DestroyMenu() |
− | AquaSalInstance::CreateMenuItem / same DestroyMenuItem( ) | + | AquaSalInstance::CreateMenuItem / same DestroyMenuItem() |
− | * Sound : | + | * Sound: |
− | AquaSalInstance::CreateSalSound( ) | + | AquaSalInstance::CreateSalSound() => object to a pointer of SalSound type |
− | Note : AquaSalInstance::DestroySalSound is not implemented | + | Note: AquaSalInstance::DestroySalSound is not implemented (?) |
− | * Timer : CreateTimer( ) / | + | * Timer: CreateTimer() / |
− | AquaSalInstance:: DestroyTimer( ) is not yet implemented ( ? ) | + | AquaSalInstance:: DestroyTimer() is not yet implemented (?) |
− | Class MacImeStatus : inherits of SalI18NImeStatus | + | Class MacImeStatus: inherits of SalI18NImeStatus |
− | -> only there to see if there is a window to toggle into menubar [FIXME] ?? | + | -> only there to see if there is a window to toggle into menubar [FIXME]?? |
− | AquaSalInstance::CreateI18NImeStatus( ) : | + | AquaSalInstance::CreateI18NImeStatus(): instantiates MacImeStatus |
'''For futher informations, see: ''' '''[[Content of salinst.cxx]]''' | '''For futher informations, see: ''' '''[[Content of salinst.cxx]]''' | ||
− | ( [[User:Ericb|Ericb]] 16:11, 20 May 2006 (CEST) | + | ([[User:Ericb|Ericb]] 16:11, 20 May 2006 (CEST) ) |
==== salmain ==== | ==== salmain ==== | ||
− | Role : if possible, runs the standard vcl application code SVMain( ) | + | Role: if possible, runs the standard vcl application code SVMain() |
− | ( [[User:Ericb|Ericb]] 16:15, 20 May 2006 (CEST) ) | + | ([[User:Ericb|Ericb]] 16:15, 20 May 2006 (CEST)) |
==== salsound ==== | ==== salsound ==== | ||
− | ==== salsys | + | ==== salsys ==== |
==== saltimer ==== | ==== saltimer ==== | ||
− | === Sal GDI ( everything Graphical Display Interface ) === | + | === Sal GDI (everything Graphical Display Interface) === |
====salgdinativewidgets==== | ====salgdinativewidgets==== | ||
Line 676: | Line 678: | ||
====audioconvert==== | ====audioconvert==== | ||
− | (obsolete ?) | + | (obsolete?) |
====devaudio==== | ====devaudio==== | ||
− | (obsolete ? ) | + | (obsolete?) |
====native sound==== | ====native sound==== | ||
Line 696: | Line 698: | ||
− | [FIXME]: is session manager usefull ? | + | [FIXME]: is session manager usefull? |
− | == What is used for Linux, Windows, Mac OS X ...build | + | == What is used for Linux, Windows, Mac OS X ...build ? == |
'''[[Description of the dependencies]]''' | '''[[Description of the dependencies]]''' | ||
Line 718: | Line 720: | ||
'''Content of vcl/inc''' | '''Content of vcl/inc''' | ||
− | Notes : | + | Notes: |
1) Where to find includes | 1) Where to find includes | ||
− | <foo/bar.hxx> | + | <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) | 2) | ||
− | suffix .h (for C calls or first version ?) or .hxx (C++ ) | + | suffix .h (for C calls or first version?) or .hxx (C++) |
− | '''A) Family of includes''' : | + | '''A) Family of includes''': |
− | Looking more closely at the list brings to the fore (expression from dictionary ;-) | + | 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. | 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). | 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 : | + | Partial list, for example: |
salatype.hxx | salatype.hxx | ||
Line 749: | Line 751: | ||
salgeom.hxx | salgeom.hxx | ||
− | sallayout.hxx ( main header for fonts services ) | + | sallayout.hxx (main header for fonts services) |
... | ... | ||
salmenu | salmenu | ||
Line 759: | Line 761: | ||
'''B) Includes of includes''' | '''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. | + | 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 : | + | To verify, a simple test to do in vcl/inc: |
− | egrep -H "#include" ./* | wc -l | + | 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 know more, the precedent command line can be modified to make appear the numerous call | ||
Line 771: | Line 773: | ||
egrep -H "#include" ./* | cut -d"#" -f2 | sort > liste.txt | 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** | + | 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 | **see http://wiki.services.openoffice.org/wiki/Source_code_directories | ||
Line 800: | Line 802: | ||
[[salgeom.hxx]] | [[salgeom.hxx]] | ||
− | '''[[ sallayout.hxx ]]''' | + | '''[[ sallayout.hxx ]]''' <-- see Native Fonts implementation |
[[salgtype.hxx]] | [[salgtype.hxx]] | ||
Line 809: | Line 811: | ||
'''B2) Classicals includes''' | '''B2) Classicals includes''' | ||
− | file : abstdlg.hxx | + | file: abstdlg.hxx [ means abstract dialog ] |
This includes does contain the following classes definitions: | This includes does contain the following classes definitions: | ||
− | [FIXME] | + | [FIXME] : choose a precise presentation template for classes |
Line 822: | Line 824: | ||
VclAbstractRefreshableDialog, | VclAbstractRefreshableDialog, | ||
− | VclAbstractDialogFactory, | + | VclAbstractDialogFactory, |
− | uses <tools/solar.h> , <tools/string.hxx> | + | uses <tools/solar.h> , <tools/string.hxx> + |
"dllapi.h" | "dllapi.h" | ||
− | Note | + | 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 : | + | Classes: |
− | Window -> what ? [FIXME] | + | Window -> what? [FIXME] |
− | ResId | + | ResId -> what? |
Does contain the prototype of VclAbstractDialog, inherit of VCL_DLLPUBLIC | Does contain the prototype of VclAbstractDialog, inherit of VCL_DLLPUBLIC | ||
− | file : dllapi.h [ dll for dynamic linked library ] | + | file: dllapi.h [ dll for dynamic linked library ] |
− | Uses : <sal/config.h> and >sal/types/h> | + | Uses: <sal/config.h> and >sal/types/h> |
− | includes : VCL_DLLPUBLIC macro | + | includes: VCL_DLLPUBLIC macro |
− | file : accel.h | + | file: accel.h [ means accelerator ] |
− | Classes : | + | Classes: |
Accelerator | Accelerator | ||
Line 854: | Line 856: | ||
ImplAccelEntry | ImplAccelEntry | ||
{ | { | ||
− | public members : | + | public members: |
Names | Names | ||
Line 869: | Line 871: | ||
ImplGetKeyCode / void / KeyFuncType eFunc, ref rCode1 , ref rCode2, ref rCode3 | ImplGetKeyCode / void / KeyFuncType eFunc, ref rCode1 , ref rCode2, ref rCode3 | ||
− | file : accel.hxx | + | file: accel.hxx |
− | Uses : <sv.h> , "dllapi.h" ,<tools/resid.hxx>, <<tools/rc.hxx> | + | Uses: <sv.h> , "dllapi.h" ,<tools/resid.hxx>, <<tools/rc.hxx> |
Line 881: | Line 883: | ||
== Important Links == | == Important Links == | ||
− | |||
− | |||
'''[[Progressive implementation]]''' | '''[[Progressive implementation]]''' | ||
− | '''Native Font server Implementation''' | + | '''Native Font server Implementation''' '''[[Fonts starting point and documentation]]''' |
− | '''Native Sound Implementation''' | + | '''Native Sound Implementation''': [[Mac OS X Porting - Native Audio and Video]] |
− | '''Native Printing Implementation''' : [[Mac OS X Porting - Native_Printing]] | + | '''Native Printing Implementation''': [[Mac OS X Porting - Native_Printing]] |
− | '''Drag and Drop implementation''' : [[Mac OS X Porting - Native Drag and drop]] | + | '''Drag and Drop implementation''': [[Mac OS X Porting - Native Drag and drop]] |
This work is part of http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Work_Areas/Todo%27s | 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 for Mac OS X port''': [[Mac OS X port: wish list]] |
− | [to be continued :-) ] | + | [to be continued:-) ] |
Revision as of 08:33, 24 September 2006
Contents
- 1 Public Documentation License Notice
- 2 Mac OS X Native port
- 3 Native Port Roadmap
- 4 Strategy for native port
- 5 2nd Mac porters meeting
- 6 IRC Mac port meetings
- 7 Description of the Native Port problem
- 8 What do we have to do?
- 9 Where is located the code to be modified?
- 10 How will the new implementation be tested?
- 11 Sort of documentation about VCL around Native Mac OS X port
- 12 Naming convention
- 13 What do we have to build in vcl?
- 14 EXISTING objects to build in aqua
- 15 TO BE IMPLEMENTED (missing in Aqua)
- 16 What is used for Linux, Windows, Mac OS X ...build ?
- 17 Content of Aqua
- 18 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
**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 ... [1]
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:
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
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.
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#
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): Mac OS X Porting - Native Audio and Video
- Implement native Drag and drop, Implementing Pasteboard Manager: Mac OS X Porting - Native Drag and drop
- Implement Native Filepicker
- Implement Native Printing: current uses cups, but native printing is mandatory: Mac OS X Porting - Native_Printing
- Implement Apple Spellchecker
Where is located the code to be modified?
Most of the changes are located in vcl (Visual Class Layer), for everything graphical, events, fonts, rendering and printing.
Other, for sound and movies will be in avmedia (where the player is implemented in OpenOffice.org sources).
For drag and drop, dtrans is concerned (Pasteboard Manager implementation)
[FIXME]: Filepicker? Apple Spellchecker?
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.
[FIXME]: add more complete list of features to implement and test.
Sort of documentation about VCL around Native Mac OS X port
Do we really need to understand how it works? ;-)
vcl content:
ls -laR | wc -l
1750
-> Uff 1750 files to analyse :-/
Our purpose is to describe the vcl organisation. The content of vcl is so important, that at the begining, the content will looks a bit confused. e.g. class names ..etc have nothing to do, only description with words and sense, but this will need some time before we can understand everything.
How analyse with more efficiency? After some months to anlalyse "horizontaly", it appears that list all the content of a directory is not the solution. Of course, we learned a lot, but we now have to complete with "orthogonal" method (compared to the previous one). The first method wasn't obviously not the good/best way to describe vcl.
[UPDATE] After some investigations, the use of Design patterns seems to be the most efficient approach to describe vcl. Will try to do so asap.
[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).
Ericb 16:12, 1 July 2006 (CEST)
Sub-directories description
Organisation of vcl directories
Directories in vcl. Short description
aqua : The name Aqua means Apple look and feel, and is well known as 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
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):
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
(Ericb 16:11, 20 May 2006 (CEST) )
salmain
Role: if possible, runs the standard vcl application code SVMain()
(Ericb 16:15, 20 May 2006 (CEST))
salsound
salsys
saltimer
Sal GDI (everything Graphical Display Interface)
salgdinativewidgets
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
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
sallayout.hxx <-- see Native Fonts implementation
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
Native Font server Implementation Fonts starting point and documentation
Native Sound Implementation: Mac OS X Porting - Native Audio and Video
Native Printing Implementation: Mac OS X Porting - Native_Printing
Drag and Drop implementation: Mac OS X Porting - Native Drag and drop
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:-) ]
--Ericb 15:00, 22 Jul 2005 (EDT)