From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Tue Apr 23 2002 - 03:37:19 EDT
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.
This archive was generated by hypermail 2.1.4 : Tue Apr 23 2002 - 03:38:33 EDT