Re: A Proposal (why we should have setBold(true))


Subject: Re: A Proposal (why we should have setBold(true))
From: Paul Rohr (paul@abisource.com)
Date: Wed May 31 2000 - 20:33:42 CDT


At 05:53 PM 5/31/00 -0500, sam th wrote:
>However, everyone on the PT thread agreed that something needed to be
>done. I got started on this becuase the XHTML importer is needlessly
>difficult to write currently. If we keep the system the way it is, we
>will just run into more and more things that require workarounds or kludge
>solutions. Maybe it won't get into 1.0, but I think this needs to be
>done. (I like Jeff's suggestions, provided I understood it properly).
>I'll work on it if other people agree with me.

I'm probably gonna regret jumping into this thread so long after the fact,
but ...

... could someone summarize for me what problem this proposed rewrite is
intended to solve? I know it may seem a but odd to have a narrow
string-oriented API for manipulating document properties, but I've been
really really happy with how that design has worked out in practice.

Unlike a lot of messy, complicated document formats, the radically-flattened
AbiWord document model is really nice to work with. We've currently got a
simple, rock-solid mechanism in place which allows us to add formatting
properties to the file format without making *any* changes to the piece
table or the import/export code.

Moreover, the incremental work to add support for a new property is pretty
cleanly localized in the appropriate spots:

  - out in the UI,
  - deep in the formatter,
  - once for each importer or exporter. [1]

All of the hard work to make sure that *editing* happens is already done,
and the underlying plumbing never needs to be touched.

These are all Good Things, so I must be missing something here.

While I'm quite leery of the pre-1.0 work required to separate our overgrown
views into more traditional views and controllers, I kind of understand the
intent there. The existing View class has a *lot* of methods, and folks
with too much time on their hands could probably simplify things
(eventually) after doing a lot of refactoring. Even so, it's not clear what
the immediate functionality win would be.

However, I just plain don't understand why we'd ever want to mess with the
Piece Table APIs. Are we solving the right problem?

Paul,
confused

[1] = I do take for granted that some import/export conversions between
radically different file formats will be more difficult than others. The
more different a formatting model is from ours, the more work it'll take.
That's OK. So long as we're handling Word documents so well, we must be
doing *something* right. ;-)



This archive was generated by hypermail 2b25 : Wed May 31 2000 - 20:28:07 CDT