[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
More frontend notes
- To: <heh>, <marcs>, <tribble>
- Subject: More frontend notes
- From: Ravi Pandya <ravi>
- Date: Thu, 21 Sep 89 13:02:27 PDT
- Cc: <us>
Bob & I were talking about it this morning, and we worked out a "least bad"
solution for moving headers vs. families. When you drag from a header tag
a grey outline follows the mouse and indicates the shape of what is being
dragged. The default is to drag a family (I think this is likely to be
the most common operation, but experience might prove me wrong. For now,
this is a religious issue.) If the command key is pressed, this drags the
header only, and changes the shape of the grey outline. You can switch in
the middle of a drag. Although this is an keyboard modifier (yech!) there
is immediate feedback as to which it is, and you can change at any time
by pressing or releasing the command key.
Adding the option key does a copy instead of a move. We should be able
to visually indicate this by what happens to the selection. It shouldn't
go away, but maybe it can be greyed for a move and not for a copy.
Headers that are collapsed carry their children around with them all
the time. If you want to drag just the header, uncollapse it.
Promotion/demotion are handled by dragging the outline left and right.
It snaps to whatever indentation it would assume if you released it.
It gets inserted before the line that its top line is over, and the
tree structure is mangled in whatever way is needed to make this
reasonable. (Having the outline only snap to indent levels that are
possible for the line it's going to will help.)
Multiple selections are handled by shift-clicking on a bunch of headers
and then dragging from the last one. In a case like this, or when the user
is dragging a big family, the outline might need to be indicative of the
structure rather than an outline of the actual appearance on the screen.
--ravi