User:Pdefilippis/Project Page

Mac OS X's Aqua Porting of OpenOffice.org

Welcome to the Aqua porting of OOo project page. This project is part of Google's Summer of Code 2006. Here you will know everything about the evolution of this project.

• You can reach me at aliscafo@gmail.com

Goals

Overall: Write a progressive implementation of the Aqua part of the VCL module using Mac OS X's Carbon API.

• Understand the organization of the VCL module.
• Write documentation about its classes and their purpose.
• Implement the missing parts of the Aqua VCL and test them using svdem

Daily Report

• Follow my day-to-day progress in this section.

Thu, Aug 17th 2006

Accomplishments

• Cleaned up the code in my app after reading a very interesting article published on Oreilly.com about Quartz 2D and its concepts. A must read for anybody interested in learning the API.
• A Simple Drawing Sample in Quartz 2D

Wed, Aug 16th 2006

Accomplishments

• Today I kept expanding my simple tutorial Application. Achievements include drawing in a simple HIView and using Bindings to keep the drawing in proportion with the size of the window.
• Also I have been working on some functions of AquaVCL today and we can now draw lines and polygones.

Here is the code: [cpp,N]


void AquaSalGraphics::drawPolyLine( ULONG nPoints, const SalPoint *pPtAry ) { //SalPoint -> salgtype.hxx //Wrapper function DrawPolyLine -> outdev.hxx if ( BeginGraphics() ) { CGContextBeginPath( mrContext ); CGContextMoveToPoint( mrContext, pPtAry[0].mnX, pPtAry[0].mnY ); int i; for( i = 1; i < nPoints; i++ ) { CGContextAddLineToPoint( mrContext, pPtAry[i].mnX, pPtAry[i].mnY ); } CGContextClosePath( mrContext ); CGContextDrawPath( mrContext, kCGPathStroke ); EndGraphics(); } }

// -----------------------------------------------------------------------

void AquaSalGraphics::drawPolygon( ULONG nPoints, const SalPoint *pPtAry ) { //SalPoint -> salgtype.hxx //Wrapper function DrawPolygon -> outdev.hxx if ( BeginGraphics() ) { CGContextBeginPath( mrContext ); CGContextMoveToPoint( mrContext, pPtAry[0].mnX, pPtAry[0].mnY ); int i; for( i = 1; i < nPoints; i++ ) { CGContextAddLineToPoint( mrContext, pPtAry[i].mnX, pPtAry[i].mnY ); } CGContextClosePath( mrContext ); CGContextDrawPath( mrContext, kCGPathFill ); EndGraphics(); } }

I will be releasing a patch soon when I am done implementing other functions in gdi.cxx.

Tue, Aug 15th 2006

• My sample application is well underway. Today's tasks involved creating a simple window without NIB files and writing some simple Event Handlers.

Mon, Aug 14th 2006

• This week is the last week of the Google Summer of Code Program. My plan is to finish up some code that I was working on and also to finish the 2 articles that I am writing. One that I will be submittimg the the OpenOffice Developers Article Contest and the other that will show with a simple application the various subjects of the Carbon API that a programmer needs to be somewhat comfortable with to work on the Mac Porting Team.

• Here is an unfinished graphic that will be used in the first paper just to give you an idea: VCL-Dependencies

Wed, July 26th 2006

• These last couple days I have started working on the implementation of bitmaps in vcl. Here are the websites that helped me understand the concept of bitmaps better:
  

A Beginners Guide to Bitmaps
About Bitmap Images
Quartz 2D: Bitmaps and Image Masks

• I modified the fullscreen patch with the advices from Pavel Janik and Florian Heckl (Thanks!). Here is the code:

[cpp,N]

/*

 * Function: Computes the current resolution of the screen
 * and stores it in pSize.
 */

static void ImplSalCalcFullScreenSize( const AquaSalFrame* pFrame, Rect* pSize ) { /** FIXME ** * Implement multiple displays here. That's why a pointer * to frame is passed. But pointer not currently used. **/ CGDirectDisplayID mainDisplayID = CGMainDisplayID(); printf("--PDF--: Display ID %d\n", mainDisplayID);

CGRect rect; rect = CGDisplayBounds( mainDisplayID ); printf( "--PDF--: Screen resolution: %fx%f\n", rect.size.width, rect.size.height );

// Rect made out of ints -> cast required -> CGRect made out of floats. pSize->top = 0; pSize->left = 0; pSize->bottom = static_cast<int>(rect.size.height); pSize->right = static_cast<int>(rect.size.width); }

// -- Algorithm -- // Get Main Display ID. // Get display resolution // Resize window to this size. void AquaSalFrame::ShowFullScreen( BOOL bFullScreen ) {

   fprintf(stderr, ">*>_> %s\n",__func__);

if( mbFullScreen == bFullScreen ) return;

mbFullScreen = bFullScreen; AquaSalFrame* pFrame = this; if( bFullScreen ) { Rect newBounds; ImplSalCalcFullScreenSize( pFrame, &newBounds ); GetWindowAttributes( mrWindow, &maFullScreenAttr ); ChangeWindowAttributes( mrWindow, kWindowNoAttributes, maFullScreenAttr ); GetWindowBounds( mrWindow, kWindowContentRgn, &maFullScreenRect ); SetWindowBounds( mrWindow, kWindowContentRgn, &newBounds ); SetSystemUIMode( kUIModeAllHidden, kUIOptionAutoShowMenuBar ); } else { SetWindowBounds( mrWindow, kWindowContentRgn, &maFullScreenRect ); ChangeWindowAttributes( mrWindow, maFullScreenAttr, kWindowNoAttributes ); SetSystemUIMode( kUIModeNormal, nil ); } }

• Here is the patch: FullScreen Patch

Tue, July 18th 2006

• I finally got a grasp of the organization of the code in vcl and the aqua part. I was therefore able to finish the FullScreen function of SalFrame.cxx.
• [UPDATE] Check Wed, July 26th 2006 for code.

Wed, June 21st 2006

Accomplishments

• I understood many things today. First if you create a simple main.c file, try to create a simple window with the Carbon API in it, and run it from the command line, you will never see the window appear on the screen, because you have to create an application bundle. Second I succeeded in creating a simple window that goes in fullscreen. Now I just have to put the code in VCL. I am not quite sure how to do that yet but I will find the solution.

Sun, June 18th 2006

• I will be flying back to the US to attend Summer school, so I won't be doing much since I will be travelling all day.
• [UPDATE] Alright, I just got home. I'm back in the game...

Fri, June 16th 2006

Accomplishments

• I decided to get my hands in the code today and just try things out. I decided to work on the ShowFullScreen() function of the Aqua SalFrame.cxx. I am using the same initial structure as in the code for Windows. I will then make the necessary changes to it to make it Aqua. So far this is the structure that I have:
  

- Make the taskbar disappear
- Save old position of the window
- Save the show state
- Set the window to screensize.

• I was able to find examples on the ADC website to give me an idea of what we can use to make this possible. As you may know QuickTime allows you to view movies in FullScreen (if you pay for the Pro version of course...) therefore in the QuickTime API there are two functions BeginFullScreen() and EndFullScreen() that we can use in any application to get a window fullscreen. I will try that out tomorrow after I ask/find where some things are in the code.

• I worked on my Carbon app and Pavel was nice enough to give me the code for his own Carbon testing app. That helped me a lot and we both decided that we will comment the app and put it on the wiki for anybody to use to learn the Carbon API. I already started putting comments while I was going through the code, I added link to websites that will help people learn.

• Here are some of the websites I have been reading lately:
  

Window Manager Reference
Window and Control Concepts
FullScreen Discussion on CocoaDev

Wed, June 14th 2006

Accomplishments

• Today I worked on the implementation of my svdem built with Xcode. I am also reading the documentation about EventHandlers at the same time to understand the concepts. So far I have been very pleased by the way the Carbon API is built. It is very logical and convenient. It therefore makes my learning much easier. To be more precise the way events are handled is very nice. Going from the more precise to the more general in the hierarchy of the GUI until it finds a handler, or just discarding the event if none are found, is a very nice and easy way of handling events at particular levels in the GUI. I will be writing documentation once I get a little further in my application and hopefully the result will be an app. with the same features as OOo's svdem. I had trouble finding enough time to make a significant progress these days, hopefully this shoulld be resolved by the end of the week...
• Here are some of the websites I have been reading lately:
  

Carbon Event Manager
Carbon Overview

Sun, June 11th 2006

Goals

• Work on the Carbon application resembling svdem to understand the Carbon API.
• Hopefully find a solution to make building OOo within XCode successful.

Accomplishments

• I finally got XCode to compile OOo. The thing I noticed today is that XCode runs scripts in bash so since I am still using tcsh none of my environment variables were set. Once I understood this, the road to compilation was quite straight. But unfortunately after importing all of OOo's modules into my XCode project, it becomes impossible to close the project without getting a hang when reopening it. If you look in Activity Monitor at this point you can see that more and more memory is allocated to XCode. So hopefully somebody can give me a clue as to why XCode cannot handle big projects. Here are the steps that I followed to compile OOo within XCode:

• Create a new project in XCode. Choose Carbon Application.
• Add all the modules of OpenOffice.org to the source directory under the Group & Files column in XCode either by dragging or by choosing Add to Project... under the Project menu.
• Choose the option Create Folder References for any added folders. You can check Copy items into destination group's folder or not it doesn't matter, XCode will crash when you reopen the project anyway.
• I would advise not to add all of OOo's modules at once since XCode might hang. It is better to add around 10 modules at a time and wait for XCode to finish indexing all the files. You can see that by opening the Activity Viewer in the Window menu.
• Then once you copied all of the modules, click on the arrow next to Targets in the Group & Files column of your project window.
• Right-click on the name of the executable and choose Add -> New Build Phase -> New Run Script Build Phase.
• Then in the window you can choose which shell executes your script and you can type your script.
• After that close the window and click on Build, XCode will use your script and output you the same thing that you would see on the command line.

• Here are the websites that helped me find a solution:
  

Building a Universal Binary from Open Source
Porting UNIX/Linux Applications to Mac OS X

Sat, June 10th 2006

Goals

• Keep working on my Carbon application in XCode.
• Find out where to set up a different build system in XCode.

Accomplishments

• I spent the whole day trying to figure out a way to manage the source code of OpenOffice.org with XCode. I was told that Mac developers did not use XCode with OOo because it does not use dmake. I found out that actually XCode can use any building tool that we want, we just have to specify the path to the executable. But for OOo I think it is better to use the option of running a shell script to build the project. This works fine and I was successful at compiling part of the code through XCode but unfortunately the shell that XCode uses to execute the script is different than the one of the command line. XCode's shell has a different path and I was unable to change it so far. Therefore XCode does not find executables required for building such as gcp or package config that I installed with Darwin ports. I will keep looking for information about setting the path, but Apple's documentation is quite limited on this topic, since it is so specific. Otherwise I will have to copy all the executables that I need in the path that XCode checks. Hopefully that works...
• Another idea came to mind today. Apparently the Mac team uses a unix tool to generate a file describing the dependencies of each module within the source of OOo. They use this file to generate a graphical representation of the dependencies. This is great since if some dependencies change then the graph is updated automatically and there is no need to do it by hand. Unfortunately I found out that the quality of the graph was not that great and therefore not very helpful for understanding. I think we can improve the graph by writing a small applescript that will read the file generated by the unix tool and send commands to OmniGraffle to draw a graph. OmniGraffle has a very good support for applescript, this should therefore be an easy task, but I don't know any applescript so if anyone is interested I can send them a sample output file.
• On a side note I have finally received my invite for testing Google spreadsheets and I got to play around with it for a couple minutes. So far it really looks promising. The only thing missing is support for Safari...

Fri, June 9th 2006

Accomplishments

• Worked on the wiki.
• Created a new page regrouping information about the Mac OS X port of OOo. The current information has been compiled from emails given by Erich Bachard of his correspondance with other members of the team.
• Started creating a Carbon application with XCode. The goal is to make a similar application to svdem to understand better the Carbon API and be more comfortable when using it in OOo.
• Looked at how to use dmake with XCode. Looks like it is possible since you can use another build system than XCode's but I haven't found were to enter the settings yet.

Thu, June 8th 2006

Accomplishements

• Today I worked some more on the wiki.
• I have now started a page explaining how to compile OpenOffice.org without X11, since I wasn't able to find such a page when I was trying this myself.>
• Also I have created a seperate page containing all of my findings about the Aqua VCL I am working on for my project. I will be updating this page regularly and my goal is to write some detailed explanations about the module.
• I have also looked some more at Carbon and tried to understand better why the porting team is using it rather than Cocoa.

Schedule

• Phase 1 (May 24th - June 7th)

- introduction to the team, get to know them and other Sun developers.
- discover the organization of OOo’s source code and of the scheduling.
- understand the role of the vcl module in the software.
- discover, study and document the native porting part of interest.
- analyze the current work, compile OOo without X11.
- understand thoroughly the use of svdem.

• Phase 2 (June 8th - July 20th)

- Study and contribution to the implementation of the drawing/painting part and other necessary classes.
- tracing points at particular coordinates.
- tracing segments of different colors.
- tracing of simple geometric shapes, intersections etc…
- events management.

• Phase 3 (July 21st - August 18th)

- Test and validation of a proof of concept.
- Documentation writing will be done during the project with an emphasis on reusability.

-- Pdefilippis 23:02, 7 June 2006 (CEST)