Subject: Re: chunks design -- ...
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Sun Sep 24 2000 - 18:25:56 CDT
On Sun, 24 Sep 2000, Paul Rohr wrote:
> Martin,
>
> Which patch are you referring to? The last code I remember seeing from
> Keith was followed by a lengthy exchange between Keith and Justin where they
> agreed that certain aspects of that code should morph into something a lot
> more like what I've been describing.
HI Paul,
Here is the link to the patch.
http://www.abisource.com/mailinglists/abiword-dev/00/March/0344.html
The only follow up to this post was this comment by Justin where he states
he wants to extend the concept on the formatter and layout side by adding
a group. Nowhere do I see agreement that there should be Field strux.
http://www.abisource.com/mailinglists/abiword-dev/00/April/0047.html
Unfortunately after the patch, Keith dissappeared from the List so we
don't know what he thinks of Justin's suggestion. :-(
In Keith's patch, rather than a strux, Kieth implements a new type of
field as a fragment.
The old inline fields also stay. So in Keith's approach there are now two
types of field. A "PieceTable" field and the old inline fields as before.
Abi knows which is which from the enumeration value of the list of field
types.
I like this approach because updating a PieceTable field requires
deleting the old text span and calculating a new one. This throws a CR_
changerecords like crazy and is way overkill for what we mostly use fields
for. Labels for Lists (done) Figures, Tables, Chapters, page numbers etc.
For these most commonly used and updated Fields the current inline
approach is quite appropriate and works.
Now even for the most complex fields like TOC might be doable in this
framework. Since a block and contain forced linebreaks and the
m_pField pointer can also be set in fp_tabRun's. I think we can construct
a TOC using Keith's approach. In fact I want to try to produce a dummy TOC
as a proof of concept that Keith's approach will work for us.
AS I said before I've integrated Keith's patch in the current CVS abi
and have been busily extending it along the lines Keith talked about in
his final post.
I've run into some difficulties.
1. Since the updating code is in the PieceTable it is difficult to get
info from the view and layout classes above it. In fact during a document
import this information is not available anyway. Some piecetable fields
can only be populated after an import is completed. So I have put a
m_pBlock pointer into the fd_Field Class along with set and get methods.
If m_pBlock is NULL the field cannot access view type information (which
would be needed for TOC). However I think this is a generic problem for
any field implemented at the PieceTable level.
2. Updates. Updating a PieceTable field requires deleting an old text
span and inserting a new one. Doing that requires a block reformat
following every PieceTable field update. This in turn moves the insertion
point to the end of the last updated field.
We can make Field updates conditional on anytype of document change we
wish by placing code in the View_listener classes.
At present undo-ing a deleted field also updates every other PieceTable
Field. If you have a PieceTable field at the end of a document and you
undo a delete on a field at the beginning the caret jumps to the end :-(.
I think I can fix these two problems, then I'll have a go at doing a dummy
TOC. I think it will work. If so I believe we can use this approach for
the rest of our fields and we can move onward to 0.90.
<more answers follow>
>
> At 12:12 PM 9/24/00 +1000, Martin Sevior wrote:
> >1. Do we really want to allow editting of Fields?
>
> Of course. The only question is when.
>
OK. I didn't want to get into that now! Keith's approach will definately
allow editting of fields.
> >This adds a whole of
> >complexity if we want to preserve editting of fields through field
> >updates.
>
> Huh? I thought the whole idea of updating a field is that you completely
> *replace* its contents.
Yes that's what I meant and why I don't want to allow editting of fields
yet.
>
> >My example is TOC. If a user decides to change on line of the TOC
> >it will be very hard to preserve this change when she adds a new chapter
> >and the TOC is updated.
>
> TOC is a tricky example, because it's a chunk which contains a lot of other
> fields -- specifically page and document references. Note that there are
> (at least) two different kinds of UI-driven updates to a TOC:
>
> - cascading update for just the embedded fields
> - regenerate the entire chunk from scratch
>
> I suppose that the first operation might preserve edits to the contents of
> the TOC chunk (depending on whether they modified an embedded field or not.)
> However, the whole point of doing the second operation is to get rid of all
> those edits, isn't it?
Exactly. I'd definately go for 2.
>
> >2. Is a chuck a subclass of a fl_BlockLayout? I'm not convinced we need
> >it. Can you give me an example of where Kevin's code will fail to give us
> >the Field we want?
>
> Feel free to ignore chunks for now. We should only worry about getting a
> robust implementation for so-called fields which do NOT allow embedded
> paragraph or section breaks. These fields are small, localized containers
> which live "inside" a containing block. For most purposes, the formatter
> can entirely ignore the fact that certain runs are inside a field.
>
YES!! This is what we've almost got :-)
> For stuff like TOC which generates a large chunk of content -- lots of
> paragraphs or even an entire section -- we'll need a separate mechanism.
> The chunks are at document scope, and are essentially orthogonal to our
> existing section/block hierarchy. (They can easily violate nesting,
> remember?)
I think a TOC could be implemented within a Block since a Block can have
line breaks and tabs and even extend over a page and even have page
break's included. It really helps a lot to embed a field in block.
>
> If you're thinking class hierarchies inside the formatter, both Field and
> Chunk could probably be subclasses of a common GeneratedContent class. For
> the most part, the field and chunk objects are external bookkeeping off on
> the side which control the regeneration of that content, if needed.
>
> When you're down at the line and run level, you rarely need to know that
> you're inside a chunk or field, and when you do, you can go look it up if
> needed.
>
> Is this making sense yet?
>
Yes it makes sense. I'm glad to put off chunks. Do you see what Keith was
doing? I think it will work and is likely to be working soon.
Martin
> Paul
>
> PS: However, it might make the implementation a bit easier if we subclass
> these off fl_Layout, just because it makes the handle exchange with the
> piece table easier.
>
This archive was generated by hypermail 2b25 : Sun Sep 24 2000 - 18:26:42 CDT