Subject: Re: A Proposal (why we should have setBold(true))
From: sam th (sam@bur-jud-118-039.rh.uchicago.edu)
Date: Wed May 31 2000 - 22:09:39 CDT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 31 May 2000, Paul Rohr wrote:
> ... 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.
These are very much good things, and that's precisely the point. Nothing
in EditMethods deals with the PT directly, which is good. FV_View
provides a nice interface for this. The problem is that the importers
(which was what sparked this discussion) don't behave like that. Instead,
they access the API of the PD_Document directly (which is little more than
a wrapper for the PT). This means that the importer has to think as the
same level as the PT, which is good for only one importer, the ABW
importer.
>
> 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?
>
I have now been given proper instruction, and see that the best solution
is, exactly as you say, to seperate the view into view and controller, and
then let the importer talk to a controller, rather than the PT directly
(while still allow that direct communication, since it works very nicely
for some importers). So, you are right, messing with the Piece Table APIs
is a bad idea.
> 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. ;-)
>
The way it looks to me from the Abi side of the word importer is that wv
provides us with all the properties for a span at once. However, in HTML,
you have to deal with lots of messy inheritance. I don't think we should
assume that every file format we deal with will be as nice to our system
as wv is currently. But then again, maybe HTML is an exception.
sam th
sam@uchicago.edu
http://sam.rh.uchicago.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5NdP0t+kM0Mq9M/wRArg2AJ9B3Ua79ga7EWXuc3AancKA8rYgaQCdFa/I
DdAPh+LuWhEIg2wx6QUE70Y=
=RQdL
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2b25 : Wed May 31 2000 - 22:09:39 CDT