Subject: dogfood feedback (LONG)
From: Paul Rohr (firstname.lastname@example.org)
Date: Thu Feb 15 2001 - 21:24:05 CST
I wanted to see how well all these spiffy new features Just Work, so I went
ahead and started using a fresh spanking-new build to author a document I
At first, I thought of entering all the following in Bugzilla, but then I
decided it'd have more impact if I bundled them all up in one email. Plus
which, by now I've totally lost track of who added what when so I had no
idea who they should be assigned to.
These are the kinds of spit-and-polish efforts we'll certainly need to
address for 1.0, and it'd be nice to see some of them sneak into 0.9.
Especially since many of them are easy work. ;-)
1. The tabs and spaces both draw in black. Gray would be less obtrusive.
2. The logic for scaling proportionally (wrt the zoom level) is nicely
done. It might be more conventional to always draw tab markers to produce
symbols of the same width, instead of adjusting the length to fill the space
3. The page and column bounding boxes are cool. I'm less enamored of the
line immediately below the text inside each column. It flickers horribly
while typing (clashes with squiggles, no doubt), then leaves dirt behind as
you add more lines of content. We should probably just nuke this.
4. The Page and Column break markers are pretty cool, but they seem to draw
at the end of the last line in the container, instead of immediately below
it. This looks odd, and can lead to the effects Jesper might have been
5. As mentioned in an earlier thread, nothing draws for forced line breaks,
and none of these special markers look selectable. See Jesper's post
earlier today for more details.
1. I've been craving this feature since my LinuxWorld talk a year ago.
Thanks for finally getting it going, Dom.
2. The toolbar art probably needs to be rechecked for gray levels. I'm
getting what look like dithering artifacts which blur these to the point
that they're almost illegible. Compare to the simpler line art of the
bullets and numbering buttons. It also might be worth subtly varying the
color of the indent/outdent arrows, like we did with the sub/sup buttons.
3. If you select a portion of an existing list, this indents the whole
thing. I expected only the selected paragraphs to move -- even if that
means making them become a new list.
4. If you select a range of paragraphs with differing left margins, and try
to indent them, they should all be indented one level more. Instead, we
This is due to a UI subtlety that most folks miss on first glance. Both
FV_View::getBlockFormat() and FV_View::getCharFormat() only return
properties which are the same across the entire range. (This is not a bug
-- to see why, play around with the bold button when selecting ranges which
are only partially bold.)
Thus, when the logic here doesn't get a property for the entire span, a
slightly more complex algorithm is needed. Each block in the selection
needs to be adjusted separately, since the margins differ at least once.
1. For similar reasons, more complex algorithms are also needed in the
ruler drawing logic. For example, you probably want to draw dimmed versions
of *all* tabstops that are defined in *any* of the selected paragraphs,
rather than just drawing whatever's at the active end of the selection.
2. The status bar feedback when dragging ruler controls is really nice.
However, I'd change the left indent + first line indent prompt (which you
get when dragging the bottom triangle) should be changed to a single
"Hanging indent" prompt.
3. The hefty new widgets to control the section-level left and right page
margins also caught my eye. They're big for my taste, but without tooltip
or cursor feedback, the Word-like thin gray bar may be too small for people
to consistently find and use.
4. Evidently this margin-controlling logic still needs to be replicated on
the left toolbar. That way, we can control top and bottom margins, too.
1. Obviously, the leader controls don't work. Is the same true for the
Tabs to clear prompt? I'm not seeing anything there.
2. See the comment about tabstops in ruler item #1. I suspect something
similar will apply here.
1. Gee they're big. Are we using UCS_BULLET (x2022) for these, or some
2. How do I change the default formatting of those bullet fields? Is there
a style definition I can override? It looks like I can select and reformat
the contents explicitly, but the markup suggests that the bullet format is a
P property, not a field property.
3. I'd forgotten that the markup was this verbose. Yikes! Serves me right
for not finishing the fields-as-containers design.
1. What was the rationale for changing just the Normal style definition to
lowercase? It looks kind of odd.
2. That renaming also exposes a crashing bug on load if you attempt to open
an existing document which redefined the Normal style, due to a duplicate
entry in the alphahash code.
1. There's an extra character of whitespace in the document header:
<abiword version="unnumbered" fileformat="1.0">
2. Would someone be willing to figure out what the equivalent section-level
CSS-like properties should be for the temporary <pagesize> tag? It's an
incredibly cool hack, but it makes the format look uncomfortably like
(cough) KWord's. We can do better.
I'm quite encouraged by what I see. The fact that I'm noticing stuff at
this level means that most of the hard work on these features is behind us.
Way to go, folks!
motto -- yummy Alpo!
This archive was generated by hypermail 2b25 : Thu Feb 15 2001 - 21:16:34 CST