> Aaron,
>
> 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.
Erm - sorry for the diff noise, I was hoping that you knew FV_View well
enough to pjust patch it and then look at the new functions. For the
future, do you know any way to prevent diff from making a mistake like
this? Maybe using a larger context?
> 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.)
Should the menus get commited to CVS? I guess the question is whether you
plan to ever support other view modes.
> 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
I was expecting that, of course the patch is not ready.
> 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.
Ouch. I can see the bug reports in my mind already.
> 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.
I was pretty optimistic when I jumped into this project. I poked around
for a few minutes, found the FP_PAGE_VIEW_[XY] (or whatever it's called)
and changed them to 0. All of a sudden, the page view background
dissapeared. That was pretty amazing. I was hoping that everything else
was contructed in such a flexible way that it would be easy to add/change
functionality.
Once again, assumptions aren't a thing to go on.
> 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.
I'm sure I would feel the same way.
> 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.
Unfortunately, I am pretty unfamiliar with the internals of AbiWord. It is
a big project. I was hoping that you would be able to sugest an aproach
(which looks like what you did in a few paragraphs).
> 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. :-)
While you probably grew up with actual paper, I, as a 14 year old, grew up
with the Normal Mode of MS Word 5.1a for Macintosh. I think that the
Normal mode is the best becuase it focuses on the relevant medium. When
you're writting a document on a computer, you usually don't care about
actual paper, which Page Layout simulates. The exception is before [if]
you print the document, when you go through a Print Preview and make sure
it will formatted nicely. In Normal mode, you don't loose valuable screen
real-estate to pages and see more on the screen in a window of the same
size. Even with columns - you get to type naturally and have the computer
format it into however many columns you want instead of having to type in
cramped columns.
While I don't hate page layout, it isn't my prefered way of working. I
think that some companies have made major mistakes when it comes to this
descision (i.e. Adobe Acrobat is a digital document format that is mainly
distributed over the net and on CD-Roms and rarely printed, but Adobe
designed it in Page Layout mode, even though there is no such thing as a
page becuase it's meant to be an entirely digital solution! Yuck.
> 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.
I understand what you are trying to sugest, if that's your question. Right
now, you know better than I do whether it is feasable from a prespective
of the internal structure of AbiWord. I, of course, would love to go for a
clever hack.
Currently, we've mostly been brainstorming hacks to do this. How difficult
would it be to redesign relevant sections of code to be friendly to
multiple view types? Would this break everything in the tree, or could it
just be done as a healthy redesign. People always do things better the
second time.
> Paul
> motto -- applying patches is fun. rejecting them sucks.
Every time Linus Torvalds applys a patch, he gets to watch the tree get
bigger. Every time he rejects one, he has to fight in a flame-fest about
why he doesn't like the patch. Often when he applies a patch, he gets
blamed personally for the loss of stability.
> 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.
>
Side by side? Like a print preview? I don't quite understand why this has
anything to do with a normal mode. Maybe I'm too stupid.
Aaron