I've finally had time to surf through your patch to figure out what it does
and doesn't do. Sorry for taking so long, but it was quite difficult to see
through all the diff noise.
The good news is you seem to have done a fine job of invoking most of the
necessary XP menu magic to switch layout modes. (You don't seem to have
provided implementations for the getState methods which control which menu
is currently checked, but I'm not worried about it -- that's an easy fix.)
The bad news is that I'm rejecting your patch again, for essentially the
same reason as last time:
http://www.abisource.com/mailinglists/abiword-dev/99/June/0125.html
In a nutshell, any time we add a new menu item (such as Normal View), we
start setting expectations in people's minds that the feature will
eventually Just Work, the way they expect it to.
As I explained before, I'm unconvinced that this particular feature can be
done by minor changes to the current design. Our current architecture
presumes that printing and display are completely WYSIWYG -- that you can
format a document once for display purposes and use that same layout for
printing. (You may draw them a bit differently, but they can both use the
exact same layout.) This assumption works fine for page layout, and can
conceivably work for Outline View.
However, I continue to worry that it's simply not feasible to implement a
Normal View that Just Works without violating this assumption. Before
applying *any* patches, I'd like to be convinced.
As you suggest, the following two problems (in particular) are non-trivial,
so I'd encourage you to focus your efforts on coming up with a viable design
which can address them.
At 10:27 AM 7/19/99 +0000, Aaron Lehmann wrote:
>* Print while in normal mode (crashes immediately - I suspect it's due to
>the non-standard fp_Page size.)
>
>* Have WYSIWYG columns. I remember one of the AbiSource employees
>mentioning this as essensial in a normal view mode. I haven't even taken a
>look at the column code, but I have a feeling that having all of the text
>in one column while the document is still divided into 2 or 3 (and prints
>that way!) is non-trivial compared to the rest of the stuff to do in the
>normal mode. Any ideas where to start?
Disclaimer -- I may not be the best person to ask. I have to admit that I
*like* the WYSIWYG nature of Page View, and over the past year I've been
thinking of Normal View and Print Preview as two UI design bugs which are
holdovers from early word processors targeted for really old hardware which
couldn't handle a proper editable Page View. But hey, that's just my (lazy)
opinion on turn-of-the-century GUI design. :-)
That having been said, I can think of two potential approaches.
1. The brute-force, memory intensive solution would be to have two mostly
orthogonal formatting algorithms and swap between them as needed:
- "side-by-side" (used for printing and page view)
- "linear" (used for normal view online only)
In a word, blech. I'd hate to see us ship this as our solution. This would
either require us to keep two parallel formatted views in memory, or else
wait for an entire reformat any time you switch views (or print from normal
view). The former is a memory pig and the latter could get really slow on
big documents.
2. I'd like to believe that there's still a clever hack which allows you to
use a single layout for both purposes. At one point in time, the FP_*
hierarchy of layout objects was location-agnostic -- each child knew its
position in parent-relative coordinates, rather than absolute view-relative
coordinates. (You'll have to check to see whether this is still true.)
If so, it occurs to me that you could *format* the entire document for
print, but somewhere in the upper portions of the hierarchy you'd tweak the
origins of various containers (such as columns and perhaps pages) to stack
them all vertically, instead of side-by-side. (It's not clear to me whether
these alternate "normal" origins and dimensions for various containers
should reside in the same classes or parallel ones, but that's not crucial
to the idea.)
Conceptually, it'd be like taking scissors to the columns of a magazine
article (or a newspaper) and taping them together in a vertical linear
sequence.
Does that make any sense? Convince me that it does (or that some other
approach does), and I'll gladly get out of your way.
Paul
motto -- applying patches is fun. rejecting them sucks.
PS: If this approach does turn out to be feasible, then we could apply a
similar principle to Page View so that zoomed pages could appear side by
side, rather than just always in a linear vertical sequence.