Difference between revisions of "User:Ericb"
(→Contents) |
(→Contents) |
||
| Line 81: | Line 81: | ||
Notes : | Notes : | ||
| − | 1) | + | 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) | 2) | ||
Revision as of 20:07, 28 March 2006
Contents
Sort of documentation about VCL around 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.
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 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 :-) Depending on the OS and the architecture, binaries are built or not.
qa does contain all quality assurancy stuff
source : This directory does contain all 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.
Events types : A lot of events have to be managed in runtime. Here is a short description
- do not freeze because bad event loops
Apart : exact sense of hedabu ? -> [FIXME] looks like a hash list of available includes is build while products are delivered in every module... not sure
What is used for Linux, Windows, Mac OS X ...build ?
Description of the dependencies
Contents
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 dictionnary ;-) ) 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 :
salatypes.hxx
salbmp.hxx
salctrlhandle.hxx
salctype.hxx
salframe.hxx
salgdi.hxx
salgeom.hxx ... 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 proof 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 ]
I'm nearly sure that a complete analyze of just this result will give us a lot of informations.
I propose to change the order of analyse starting with dllapi.h and sv.h.
[to be continued]
B1) "sal" includes family
salinst.hxx This seems to be the main include file
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 intersting because when we have to find (for example) a library suffix, SAL_DLLEXTENSSION can replace all suffixes (every OS's and archs). Just includes 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;
[to be continued :-) ]
--Ericb 15:00, 22 Jul 2005 (EDT)
