I agree that there is much bogosity in passing around properties in
the form of strings and lists of same.
In fact, I got fed up with this once and tried to fix the situation.
I did not complete the task, but I did learn just how widespread and
pervasive this particular implementation tactic is. Lots and lots
of code will have to be fixed in order to remedy this situation.
Have a look at the toolbar state management code.
Bottom line: In principle, your proposal is very sensible, and
it should probably have been done a long time ago. Just try to clear
your schedule for 2-3 days when you sit down to try and make the
code change. :-)
--
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>In working on the XHTML importer, I have come upon the following problem:
>
>Currently, there is a 1-1 relationship between the text of the attributes
>of an element in the XML produced by abiword and the representation of
>formatting in the pt. (actually, the piece table uses a hash table, but
>the principle is the same.) This makes life very easy for the .abw
>importer - all it has to do is pass the attributes unchanged into the
>piece table. However, this means that the means of acessing the piece
>table are (IMHO) the worst sort of low level routines. It works well for
>the abw importer, since it doesn't have to get down and dirty
>parsing attributes, constructing string arrays, and then passing them to
>the pt. Additionally, the abw file format has very little concept of
>inheritance. It never has to inherit within the same level, such as a
>block. The following is illegal abw:
>
><section>
><p props="font-weight:bold">text<p props="font-weight:normal"> more
>text</p></p>
></section>
>
>This means the formatter (which does deal with inheritance) does the work
>for the importer.
>
>However, life is much trickier for the XHTML importer (and for me). The
>following is legal html:
>
><body>
>text
><p>more text</p>
><p> a <strike>third</strike> <span> line <b> that is bold <i> and
>italic</i></b></span></p>
><b>
><p>a fourth line, which is bold</p>
></b>
></body>
>
>This makes my life very difficult. The XHTML importer has to essentially
>have only one section, and then create new paragraphs for everything else.
>However, I am not allowed to replicate the HTML nesting in the pt (which
>is a good thing).
>
>The upshot of this is that I have to keep track of what state everything
>is in, so that I can regenerate the property list for each new element
>that I create. Needless to say, this makes for ugly code. However, I
>don't think this should be the importer's job. Here's how I think the
>importer should go:
>
>beginElement(...)
>{
>...
>case TT_BOLD:
> [sanity check here]
> m_pDocument->setBold(true);
> boldRefCount++; // since turning bold on lots of times is possible
>...
>}
>
>
>endElement(...)
>{
>...
>case TT_BOLD:
> [sanity check]
> boldRefCount--;
> if(boldRefCount==0)
> m_pDocument->setBold(false);
>...
>}
>
>This would naturally be extended to all the props elements (with some
>taking more than true and false). The style elements are easier to deal
>with (since only one style at a time is possible, right now) but the may
>become more difficult later.
>
>However, this additon wouldn't just make my life easier.
>
>1 - take a look at _toggleSpan in ap_EditMethods.cpp (line 3415)
>The code there is a bunch of low-level string manipulation. This is
>exactly what should not be in EditMethods. Instead, EditMethods should do
>what it does nicely with most commands - call a fairly easy-to-use
>function in fv_View that does the low-level work - where it should be.
>
>2 - think about scripting. Eventually, we will want to add a scripting
>interface to AbiWord calls. And that language won't be C++. It probably
>will have a hard time do anything like the hackery neccessary to currently
>manipulate properties. And we can ask our users to think about that sort
>of thing either.
>
>3 - the current system locks down the implementation of the ptbl to how it
>is accessed. Granted, no one is talking about changing the ptbl right
>now. But someone might, especially if it was going to be used, at least
>in part, in some other abisuite application. Right now, changing it would
>require changing not only the ptbl API, but also the abw file format. As
>Justin pointed out a while back, an XML-based word processor could just
>manipulate the DOM tree. But that's not the route AbiWord took. Let's
>not just get the limitations of that choice, but also the benifits.
>
>Therefore, I propose:
>
>Adding to PD_Document methods such as the following:
>
>UT_Bool setBold(UT_Bool newVal);
>UT_Bool setItalic(UT_Bool newVal);
>UT_Bool setFont(XML_Char * newFont);
>
>UT_Bool isBold();
>// things that can't be toggled (such as fonts) won't need the same
>// accessor functions.
>etc..
>
>I think this will result in minimal added overhead, and greatly improve
>the usablility of the ptbl.
>
>well, what do you think?
>
> sam th
> [EMAIL PROTECTED]
> http://sam.rh.uchicago.edu
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.1 (GNU/Linux)
>Comment: For info see http://www.gnupg.org
>
>iD8DBQE5L57Vt+kM0Mq9M/wRAk8KAKCvmSRWshMMs6SBCAWoeeUPpprOnACgqBy1
>wnGtMJepOrKbHVWjllKrilQ=
>=H7Vt
>-----END PGP SIGNATURE-----
Eric W. Sink, Software Craftsman
SourceGear Corporation
[EMAIL PROTECTED]
