Subject: fields again
From: Justin Bradford (justin@ukans.edu)
Date: Tue Apr 04 2000 - 16:45:54 CDT
I've been reading through Keith's initial field implementation and I like
the approach (although I disagree with some of the specifics of the
implementation), but I want to extend it further, as well. However, before
going further with this, I want to get some feedback on the design (are
you back, Keith?)
An Abiword document piecetable consists of object and span fragments in a
block strux, with one or more block strux in a section strux.
Fields are more like strux than objects or spans, as they include a series
of spans (and potentially objects).
But, the formatter assumes document->section->block->run. A field strux
would have to be in between block and run. Furthermore, we would need a
whole set of "sub-block" strux (initially just "normal" and field).
But, currently a block is the lowest level of container. It has a list of
lines and a list of runs. Each line marks off a clump of those runs.
Introducing container structure under a block means that would have to
work in a substantially different way.
However, sub-block containers are irrelevant for layout/formatting
purposes. They're really just for grouping these spans and objects
together for some other purpose (like specifying calculated field values,
providing unique contextual clues via different rendering attributes,
etc).
So all we really need is an object which contains the meta-span
information (the attributes of the field) and for the spans in this
sub-block to know they're in a sub-block.
This is what Keith did, by adding a m_pField attribute to the fmt/Run
classes. He also extended the contructor methods to set this explicitly,
but I think we can take the same idea, coupled with a few modifications
and minor extensions and make something pretty versatile and less
obtrusive (which is my main concern with Keith's first draft).
In the piecetable, there is a new fragment type: group, which has
a generic "end" fragment to correspond to a normal "open" fragment.
A new class in the formatter (Group) is added. Blocks will now contain a
list of Groups contained in the block.
Additionally, a new simple Run subclass is made. These have widths of zero
and are basically group delimiters. These should also be useful in making
the selection tweaking logic less complex.
And, of course, the Run classes in the formatter get a m_pGroup attribute.
Now, you don't have to explicitly tell a run it's in a group. It can tell
from it's neighboring run's. Insert/deletes/splits of runs can determine
this automatically, and are capable of identifying the group they're in.
Now, when it comes to drawing, the specific display properties of this run
can be extracted from the group. So, the gray background you see when the
insertion point is on a field is dictated via the group object. We can
make the specific color an attribute of the <f> tag in the xml now. And,
we can have the group provide other certain coordinated behaviors. For
instace, the group could hide itself (return 0 for widths and don't draw).
Perhaps we can work in a click handler, for implementation of URLs.
Also, notice that any span or object can go in these. This includes
text, images, and other future objects. So a field could generate
something besides text. I'm not sure that's useful, but at least it would
be doable with the this new structure.
Justin
This archive was generated by hypermail 2b25 : Tue Apr 04 2000 - 16:46:05 CDT