Next Generation Layout classes.

From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Mon Apr 22 2002 - 11:21:18 EDT

  • Next message: F J Franklin: "commit: abiword-plugins: fix gnome version number detection"

    Hi Folks,
            To make the Tables/footnotes/positioned objects work we need
    additional fl_Layout classes as well as the fp_Container classes. The idea
    of course is to rewrite as little as possible of our current code.

    The fl_Layout classes contain the logical assembly of text and images
    in the document.
     
    Currently our fl_Layout classes consist of:

    fl_Layout - generic Base class.
    fl_DocLayout - overall class for the entire document - contains all
                       the sectionlayouts and pages.
    fl_SectionLayout - generic SectionLayout for collecting groups of
                       fl_BlockLayouts.
    fl_DocSectionLayout - Collection of fl_BlockLayout's within a given
                          section of the document. It positions lines in
                          columns.
    fl_HdrFtrSectionLayout - Collection of fl_BlockLayout's that make up an
                             invisible HdrFtr for a given DocSectionLayout
    fl_ShadowLayout - Collection of fl_BlockLayout's that are copies of
                             the master HdrFtr that are actually visible and
                             drawn to the screen.
    fl_BlockLayout - Container of text and image runs that make up the
                             document.
    fl_DocListener - Interface between the pieceTable and the Layout
                             classes

    The primary job of the layout classes is to assemble smaller pieces into
    larger collections. So fl_BlockLayout assembles runs into lines,
    fl_DocSectionLayout assembles lines into columns, fl_HdrFtrSectionLayout
    assembles lines into a header/footer etc.

    The current class heiracy is:

    fl_Layout |
              |--> fl_DocLayout
              |--> fl_BlockLayout
              |--> fl_SectionLayout
                 |--> fl_DocSectionLayout
                 |--> fl_HdrFtrSectionLayout
                 |--> fl_EndNoteSectionLayout

    Within fl_DocSectionLayout is a method called breakSection() and some
    associated methods. I think these should be liberated and placed into
    seperate classes called fb_BreakSection in analagy with fb_LineBreaker.

    The linked list of classes was:

    m_pFirstSection->DocSec<=>DocSec<=>DocSec<=>EndNoteSec<=>HdrFtrSec=>NULL

    Within each section is a linked list of fl_BlockLayouts.

    m_pFirstBlockLayout<=>Block<=>Block<=>Block<=>NULL.

    Each block has is own linked list runs and lines.

    So for the next generation code we add cells, tables, footnotes, endnotes
    and positioned objects. These must be contained by fl_DocSectionLayout and
    they also contain fl_BlockLayouts.

    So we need new classes derived from fl_SectionLayout to contain the
    fl_BlockLayouts for these new containers.

    These are fl_TableSectionLayout, fl_CellSectionLayout,
    fl_FootnoteSectionLayout, fl_PositionedSectionLayout. The class heiracy I
    propose is:

    fl_Layout |
              |--> fl_DocLayout
              |--> fl_ContainerLayout
                 |--> fl_BlockLayout
                 |--> fl_SectionLayout
                    |--> fl_HdrFtrSectionLayout
                       |-->fl_BreakSectionLayout
                          |--> fl_DocSectionLayout
                          |--> fl_EndNoteSectionLayout
                          |--> fl_TableSectionLayout
                             |--> fl_PositionedSectionLayout
                          |--> fl_CellSectionLayout
                          |--> fl_FootnoteSectionLayout

    The idea of putting fl_BlockLayout and fl_SectionLayout under a new
    base class is that methods like the following can be applied to any
    fl_ContainerLayout

    purgeLayout(void);
    collapse(void);
    isCollapsed(void);
    setNeedsReformat(void);
    needsReformat(void);
    setNeedsRedraw(void);
    markAllRunsDirty(void);
    format(void);
    getLayoutType(void);
    clearScreen(void);
    getNext(void);
    setNext(fl_ContainerLayout *);
    updateBackgroundColor(void);

    Maybe others too.

    This allows us to easily generalize the simple linked list of
    fl_BlockLayout classes which used to be all a DocSection could hold to
    something like:

    m_pFirstBlockLayout<=>fl_Block<=>fl_Table<=>fl_Block<=>fl_Position<=>
    fl_Table<=>fl_Footnote<fl_Block<=>fl_EndNote=>NULL

    Then each Table holds the following linked list
    m_pFirstCell<=>fl_Cell<=>fl_Cell<=>fl_Cell=>NULL

    Each Cell holds:

    m_pFirstBlock=>fl_Block<=>fl_Table<=>fl_Block=>NULL

    etc....

    By placing all these classes under generic heiracy we can apply the same
    methods to each.

    So a collapse method on a DocSectionLayout is translated down through
    all the layout classes under it's linked list.

    Now the other thing we do is to generalize fb_BreakSection to assemble not
    just lines into columns but any container found in the DocSection into a
    column. This code can also be made generic so that for example a cell can
    assemble text into itself and we allow containers to be broken.
     
    fl_TableSectionLayout of course needs a method to assemble cells into a
    table.

    What of fl_DocListener? Well we'll need new piecetable struxes to hold the
    properties of the new containers Table,cell,footnote, positionedObject. If
    a property of any of these containers change, the contents of the
    container are cleared and then recalculated and layed out, the same way we
    do things for DocSectionLayouts now.

    OK folks, opinions on this? Once again I think it will not be too hard to
    refactor the code to allow these generalizations.

    Cheers

    Martin



    This archive was generated by hypermail 2.1.4 : Mon Apr 22 2002 - 11:22:28 EDT