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 proposal.
When we're happy that we've reached consesus the way we want to go, 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 works. 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. Cheers! Martin 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 vital.
