From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Mon Apr 22 2002 - 00:21:43 EDT
Hi Folks,
thanks very much for your feedback. I've taken your suggestions on
board and my next itteration of the container class heiracy is this:
fp_ContainerObject----|
|--> fp_Run ---> Lots of subclasses
|--> fp_Container --|
|--> fp_TableContainer
|--> fp_CellContainer
|--> fp_VerticalContainer
|--> fp_Column
|->fp_ShadowColumn
|->fp_PositionedColumn
|-->fp_HdrFtrContainer
|-->fp_EndNoteContainer
|-->fp_FootnoteContainer
|--> fp_RowContainer
|-----> fp_Line
I've thought through a number of suggestions to make fp_Line derive from
fp_RowContainer. They make sense if fp_Run also derives from
fp_ContainerObject. Since fp_Run has all the required methods defined
this is no problem at all.
The big win from this is to be able to "pack" arbitary collections of
containers, left,right, center and full justfied by using a
generalized fb_LineBreaker class.
Given this I thought we should have a fp_verticalContainer that
enables the "breakSection" method in fl_DocSectionLayout to layout
vertical containers. fp_Column now dervices this too since columns are
vertical collections of containers.
In answer to Tomas I think we want fp_Column to derive from fp_Container
so we can cast a getContainer() to fp_Column. The getContainer method of
fp_Column should always return NULL though.
Further thought revealed that restricting the tableContainer to a
vertical collection of rows is much too restrictive. You couldn't make
tables like this then.
|---------|--------|--------|--------|--------|
| | | | | |
| | | | | |
|---------| |--------| |--------|
| | | | | |
| | | | | |
|---------|--------|--------|--------|--------|
So tables need to have their own layout algorithmn to size and position
their containers. Such algorithimns already exist. We could easily just
grab the methods in GtkTable for a simple 4-pass algorithmn.
I know SourceGear invented a 2 pass algorthimn in developing IE but I
don't if they'd donate that to us. Comments Eric?
Then in addition to these methods available to all fp_ContainerObjects.
getContainerType(void)
draw( drawArgs)
clearScreen()
getX(void)
getY(void)
getWidth(void)
getHeight(void)
getXLayoutUnits(void)
getYLayoutUnits(void)
getWidthLayoutUnits(void)
getHeightUnits(void)
getNext(void)
getPrev(void)
getSectionLayout(void)
setX(UT_sint32 )
setY(UT_sint32 )
setWidth(UT_uint32)
setHeight(UT_uint32 )
setXLayoutUnits(UT_uint32 )
setYLayoutUnits(UT_uint32 )
setWidthLayoutUnits(UT_uint32)
setHeightUnits(UT_uint32)
setNext(fp_ContainerObject *)
setPrev(fp_ContainerObject *)
The fp_Container class have:
getColumn(void);
getContainer(void);
UT_Vector * (fp_ContainerObject *) getContainerChildren();
The getColumn would work by just recursively calling getColumn until a
column was obtained.
The getContainer() would just return the holding container.
The getContainerChilder(0 method returns a pointer to vector of pointers
to the children of the container. This is a useful generic way of
obtaining all the children of a given container.
fp_Column classes have:
getPage()
getColumnLeader()
getFollower()
methods.
OK further opinions? This approach is a bit =further away from what we do
now but it is likely to be flexible enough to allow us to grow.
Cheers
Martin
This archive was generated by hypermail 2.1.4 : Mon Apr 22 2002 - 00:23:02 EDT