Subject: Re: styles
From: Paul Rohr (paul@abisource.com)
Date: Tue Dec 07 1999 - 14:05:58 CST
At 12:39 PM 12/7/99 -0600, Stephen Hack wrote:
>Is anybody working on styles? I'm considering creating the styles dialog and
>tieing in the pull down menubar.
Not to my knowledge. I did the original stylesheet hacking this spring, and
summarized how far I got in the sample document:
abi/test/wp/Styles.abw
The existing code is quite self-contained, and was easy to add. Most of the
remaining work should also be pretty localized. (I'm guessing this'll be
true for everything except #5 in that TODO list.)
However, in the two cases you mention, you may need to do some new API work
at other spots in the code:
1. To populate the toolbar combo will definitely require some API work.
IIRC, toolbar controls currently get populated once per frame at creation
time. However, what we really need is to be able to:
- populate *all* styles used (or defined, I'm not sure which), and
- update that set as it changes.
The current hack of a single fixed set was a lot simpler to add, but we'll
need a real fix.
AP_<platform>Toolbar_StyleCombo::populate(void)
As you can see from the original #ifdefs here, this may be as simple as
widening some APIs upstream of this method, so that it have access to the
View or Document. (To check, put a breakpoint here and look at the call
stack.)
2. The dialog work for browsing and editing style definitions shouldn't be
too bad, especially since we now have some XP preview widgets available.
The paragraph dialog would be a great place to start on this.
As a first cut, you may want to just mock up the full dialogs and allow
users to browse existing style definitions. I believe the current set of
Document-level methods provides just about all the access you'll need to the
underlying PD_Style objects, although it might be cleaner to go through
View-level wrapper functions (kind of like PD_Document hides a lot of
PT_PieceTable methods):
PD_Document::appendStyle()
PD_Document::getStyle()
PD_Document::enumStyles()
Among other things, it might be nice to come up with localizable
presentations of the raw properties, to avoid tainting users with the
hyphenated-english in our property names.
Where the real work will come is in editing and changing those style
definitions. In particular, we'll need to decide:
a. Which portions of a Style definition are editable? For example,
converting an existing character style to a paragraph style probably makes
no sense.
b. Should any or all of the permitted changes participate in the Undo
mechanism, and at what granularity? (Avoiding Undo entirely would make our
lives a lot easier, but will that make sense to users?)
Depending on the answers to these questions, it might be possible to just
modify existing PD_Style objects in place. Or, more likely, we'll need to
enhance the Piece Table to make it far more aware of the ways that style
definitions can change, so that it can undo those changes when needed by
consulting the appropriate change record.
After that, the real trick will be figuring out how to propagate formatting
changes to existing style definitions. Currently, as far as the formatter
is concerned, styles are read-only, and features like BASEDON cascading Just
Work, because they're hidden in the property lookup mechanism.
PP_evalProperty()
Thus, the only time we need to explicitly trigger style-driven reformats is
when we apply a different block-level style, and that code is pretty
straightforward, except down in the piece table, where it gets a bit more
complex:
FV_View::setStyle()
pt_PieceTable::changeStruxFmt()
fl_BlockLayout::doclistener_changeStrux()
However, once we allow folks to change an existing style definition, then
we'll need to reformat whichever portions of the document got affected by
that change. (In particular, the BASEDON cascading makes locating relevant
blocks and spans that much harder.) The brute force hack is to reformat the
entire document, which sounds ugly, but it's reliable, so perhaps that's our
best alternative.
And then of course, you also need to deal with the fact that documents can
have multiple views, all of which need that same reformatting to occur.
Sigh. You can see why this isn't going to be a two-day project. :-(
Paul
This archive was generated by hypermail 2b25 : Tue Dec 07 1999 - 14:00:53 CST