show/hide rulers (was: commit - checkable unix menus)


Subject: show/hide rulers (was: commit - checkable unix menus)
From: Paul Rohr (paul@abisource.com)
Date: Tue Nov 30 1999 - 17:00:23 CST


At 12:41 AM 11/21/99 -0600, Stephen Hack wrote:
>BTW, I've been working on the hidable rulers. Currently, there is only one
>toggle, all on or all off.

Cool! :-) That alone should be a very nice feature for folks without a lot
of screen real estate. Do you have any idea yet how much work this'll take
on the other platforms?

>Under Word, there is also the ability to toggle
>either/or. Should I add the additional toggles?

Actually, it looks like they've got two orthogonal settings. One setting
says whether rulers are on or off as a whole. The second says whether the
left ruler should also be there when you're displaying rulers. (Presumably
this is because left rulers are conventional for page layout, but not for
normal view.)

It looks like they've got a reasonable UI for that, so if it's not much
extra work, I suppose it couldn't hurt. Or feel free to skip that second
setting for now, since all on or all off is the most common usage, and we
don't currently support normal view anyhow.

>Also, how should the options|view|rulers toggle function? Should it be a
>3-state? or just change the defaults and change all windows?

Like most aspects of our MSDI design, I tend to assume that we should:

  - keep it simple, and
  - follow browser UI design as a precedent.

So here's a proposal. The menu should definitely be a binary toggle (on or
off), which affects the current frame. In addition, it should probably also
change the default used for creation of more new windows, either in this
session or future sessions. Other existing windows would *not* change.

The place where I'm tempted to diverge from Word's behavior is that I think
the check mark should always be "accurate" for the current frame. (They use
it to show what the default will be for new windows.)

In any event, once you have any of these alternatives coded, we'll all be
able to play with it and see whether it "feels right" or not. Fine-tuning
these UI policy issues is hard to get right ahead of time, and a heck of a
lot easier once the underlying widget-hiding logic is in place.

Paul



This archive was generated by hypermail 2b25 : Tue Nov 30 1999 - 16:55:21 CST