Subject: Re: clarifications on changing how fields work
From: Justin Bradford (justin@ukans.edu)
Date: Sun Mar 12 2000 - 21:32:04 CST
> Yes, I think this looks good. How would you handle the "if" type fields?
>
> Would it be:
> <field type="if" format="$bookmark1.pagenumber=1" bookmark1="firstpage"
> true="equal" false="not equal">not equal</field>
I am personally of the opinion that current word processors have tried to
cram way too much functionality into fields. I think if's should be
handled by scripts, but I do see some beneift in a simple alternative like
this (Rather than requiring scripting functionality for a simple if).
So, I guess I'll take the position that a simple if field is ok, but let's
try to keep scripting to scripting languages, rather than further
brutalize the field concept. Of course, that's just my opinion; many other
must be convinced, too.
> I disagree about the scale of the impact. I've started work on
> implementing fields by getting an pf_Frag_Object to create fp_Frag_Text
> objects to represent the text which then converts to fp_TextRuns,
> fp_TabRuns etc.
We have different interpreatations of large impact. My proposed field
solution was a one night, one person job. That said, your idea is better.
> In this scenario fp_FieldRuns would disappear (or maybe just be used
> for displaying the arguments to fields when chosen by the user).
I think it just evolves into the Field class you discuss below.
> I am still using a pf_Frag_Object which creates a Field class (or
> subclass) which handles the logic to update the field and links to the
> current field text in the ut_GrowBuf. (See my earlier mail on how such
> subclasses might work and be updated). The pf_Frag_Object has no
> visible representation in the document, it is the fp_Frag_Text objects
> it creates which give rise to visible runs.
Ok, this will work. Fields become a new kind of strux, effectively. Not a
"real" object, just has properties and groups other runs (like a
paragraph or section). I had a similar approach in mind, but was concerned
by the scale of changes (ie. I didn't want to write all of that code) and
convinced myself that a simpler solution would work.
For the sake of consistency, we should probably consider changing this
field to a pf_Frag_Strux (as that's what it is now).
> At the moment the user can individually format parts of the
> field, but it is lost at update. I agree this is undesirable, but could
> be got around in the same way as you describe for output. It could just
> be extracted from the fp_Frag_Text before the next update.
This gives us functionality comparable to Word, although it does appear to
have a bit of logic to extra some formatting in between updates. We could
easily duplicate it with this new model, too.
Anyway, I don't actually care much about fields. I've used them in other
word processors maybe a dozen times ever. You've obviously thought a lot
more about it than I have and you do have a more versatile solution. My
only interest in bringing this up was because it seemed some people were
stalled due to the pending field changes.
So, if you're not going to be able to work on your implementation for a
while, would you mind posting what you have so other s can take a look
and maybe help with it?
Justin
This archive was generated by hypermail 2b25 : Sun Mar 12 2000 - 21:32:47 CST