How to get there from Here.

From: Martin Sevior (
Date: Tue Apr 23 2002 - 03:37:19 EDT

  • Next message: Karl Ove Hufthammer: "Re: selections and combining characters"

    Ok the final email on these new classes is a strategy for
    migrating our code base to use the new layout engine. Here is my

    When we're happy that we've reached consesus the way we want to

    1. Hub creates new CVS modules abi-1.2, abiword-plugins-1.2 which
    are initially just a copy of the current modules.

    2. We implement the fp_Container class heiracy and make the
    current code work for the new heiracy with fp_Lines as
    fp_ContainerObjects etc. We generalize fb_LineBreaker to break any
    fp_ContainerObjects into horizontally laid out lines.

    Once the new class heiracy works with existing documents we go to
    stage 3.

    3. We implement the new Layout class heiracy with fl_BLockLayout
    and fl_SectionLayout as subclasses of fl_ContainerLayout. The
    fl_ContainerLayout abstract base class is fully defined. We create
    the new fb_SectionBreaker class to layout any collection of
    objects vertically. Once we've made this new heiracy work with our
    existing code we go to stage 4.

    4. Put the new struxes into the piecetable and investigate the
    properties we need them to define. I suggest we use RTF as a model
    here. RTF version 1.6 is basically a blueprint on how MS Word 2000

    5. Now the fun really starts. We implement the new fp_Container
    classes, then the fl_Section classes and connect them to the
    piecetable via fl_Doclistener. Once this is done we define the new
    tags needed for our AbiWord_2 importer/exporter. This is actually
    very easy. We just invent tag names for our new struxes and
    include them in the "case" statements.

    6. Steal/invent a fast Table layout tool.

    7. Once we can import/export tables/footnotes/endnotes to *.abw we
    begin work on the Table/footnote/endnote/positioned object UI.

    IMHO MS Word provides a base from which to work here. In my
    opinion this is still rather cumbersome so I'd love to get some
    help for how to do a better Table UI.

    We will definately needed to rework how to do selections and how
    to keep the cursor inside a container. The latter can be done with
    a generalization of getEdittableBounds().

    In the case of the former may not want to draw a selection over
    footnotes/endnotes and positioned object's.

    For deletions that cross cell boundaries we will want
    to pop up a little window to ask above deleting cells/rows/columns
    etc the way Gnumeric/excell/MS Word does now. It should not be
    hard to trigger this. Just put a hook into in to detect attempts
    to delete Table or cell struxes.

    This strategy allows us several checkpoints to make sure we're on
    the right track to a much more sophisticated layout engine.



    PS. There are details that I haven't talked about like how to map clicks
    on the document window to a location in the document. This particualr item
    is straight foward. As we do now, find the container containing the click,
    scan the container until a run intercepts the x,y location of the click.
    Feel free to ask about other details. I might have overlooked something

    This archive was generated by hypermail 2.1.4 : Tue Apr 23 2002 - 03:38:33 EDT