4. Design Discussion
The design of this package has been discussed, at some length, by a number of people. Here's a reasonably complete record, up to November 14, 1986:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
8 Aug 86 Swinehart.pa Some design ideas for acceleration of pop- . . .
Date: Fri, 8 Aug 86 12:02:04 PDT
From: Swinehart.pa
Subject: Some design ideas for acceleration of pop-up menus (long-promised)
To: Windex^
Cc: Swinehart
[Members of {Windex^ ) {TiogaImplementors^ * WalnutSupport^}} should delete this now, or go back and delete the individual earlier messages. Sorry to trouble you again.]
I have been meaning to distribute these messages for some time. Some variant of the design proposed in the last few messages still feel like a great way to add intelligibility to menus in Cedar. Any further comment? Any volunteers to try this approach? I plan to dump some variant of this into CSL-Notebook.
Dan
--------------------------------------
Date: Thu, 19 Jun 86 10:45:47 PDT
From: donahue.pa
Subject: Would it be possible to clean up the menu mess some?
To: TiogaImplementors^, WalnutSupport^
Cc: Donahue
I hadn't used PopupCmd and PopupMenu until Michael's message yesterday about the new stuff in Forms.df. After I did, I had a strong urge to make some changes in Walnut to use popup menus for several of the less frequent operations in WalnutSend and Walnut.
Then, this morning Peter Kessler sent a message that got me even more curious about how much better we could do — I quote part of it:
P.P.S. Okay, I looked through WalnutDoc and notice that there are now a bunch of buttons in the MsgOps menu that aren't described. Similarly, could some of the buttons in the Sender menu be moved to a subsidiary menu? I'm running WalnutVoice, and the Play button falls off the edge of the viewer, and I didn't even know about the Attach button until I just adjusted the center line. Probably a similar suggestion could be applied to the menu on messages, where Remind is over (under) the edge.
How much could be gained by a redesign of the Tioga menus to use popup menus for things like Places and Levels and . . .? It seems like this might not be a terribly hard job and I suspect the gain might be substantial. I would gladly commit to making some changes to Walnut and WalnutSend to adapt to a new menu regime.
Jim
--------------------------------------
Date: Thu, 19 Jun 86 12:54:26 PDT
From: PeterKessler.pa
Subject: Re: Would it be possible to clean up the menu mess some?
In-reply-to: "donahue's message of Thu, 19 Jun 86 10:45:47 PDT"
To: donahue
Cc: TiogaImplementors^, WalnutSupport^, Crow, Jacobi
Reply-to: PeterKessler.pa
PopupMenus are preemptive, which I find distasteful. I much prefer the pulldown menu style, but maybe I've been brainwashed.
... peter
P.S. There's also a nasty interaction of PopupMenu with FastMouse, in which PopupMenu tries to move the cursor (to the first option?) by calling Interminal.SetMousePosition[], which FastMouse notices as a mouse motion and tries to accelerate. Sigh. Of course you don't want PopupMenu to turn off FastMouse while it sets up the menu, since FastMouse might not even be loaded. Maybe there's a solution by separating the mouse position and the cursor position. FastMouse would look for changes in mouse position and change the cursor position as it deemed appropriate, but other people could change the cursor position, too. Then everything (e.g. button pushes, etc.) would have to be based on the cursor position instead of the mouse position (since that's what the user is using). I haven't thought about this much. There's a hacky solution, which is to have PopupMenu set up the menu relative to the cursor position, rather than moving the cursor relative to the menu position.
--------------------------------------
Date: Thu, 19 Jun 86 15:18:55 PDT
From: Swinehart.pa
Subject: Re: Would it be possible to clean up the menu mess some?
In-reply-to: "donahue's message of Thu, 19 Jun 86 10:45:47 PDT"
To: Donahue
Cc: TiogaImplementors^, WalnutSupport^
Reply-to: Swinehart.pa
There was a design several years ago that (I thought) combined the best features of pull-down menus and the overloading of buttons that we do. The design was due to Bill Paxton, Butler Lampson, and someone else that I've forgotten. I've looked and looked for the messages about it, but have failed to find them. Here is what I remember, possibly augmented by some of
The idea is that each always-visible button is the representative of a pull-down menu, in the "standard" way. But it wouldn't always "pull down". (What I mean by a pull-down menu is one that pops up just below a button when you push it, but disappears after the operation is selected -- rather than one that pops up at the cursor position. It doesn't stay on the screen. Tell me if this is nonstandard terminology.) Suppose that the menu, when pulled down, displayed the commands A, B, C, D, E, ..., one above the other. Here is how this menu would be used:
Basic features:
The always-visible button would probably be labelled "A".
Clicking the left mouse button would invoke menu operation "A" (the first one). The pull-down menu would not appear.
Clicking the middle mouse button would invoke menu operation "B" (the second one), without pulling down the menu.
Clicking the right mouse button would invoke menu operation "C", without pulling down the menu.
Holding any of the mouse buttons for a second or so would cause the menu to pull down, positioned over the selected one of the first three menu items. Subsequently one could use the standard slider approach to select any menu item, releasing the button over the chosen item. Which mouse button was held would now be irrelevant. So the idea is that mouse clicks are accelerators for the most common interpretations of the "A" button, but all interpretations are visible on request.
Possible extensions:
Shift <left-click> could select item D, similarly for E and F. ctrl could do G, H, and I. Or the pull-down menu could be arranged in rows and columns, the columns corresponding to the shift keys. This spells out all the cases for complicated buttons.
Pull-down menu "buttons" could be quite verbose, so that they could document themselves. Or maybe they become more verbose if you leave the button down without moving the mouse. This possibly conflicts with the rows-and-columns design.
If self-documenting buttons were not chosen, one of the menu items could at least always be a "Help" command that would provide detailed documentation of the choices.
Comments:
This design is intended to provide a standard extensible interpretation for buttons that behave differently depending on which button you attack them with. I don't know if they are a reasonable replacement for multiple-line menus like the ones that do Levels and Places or even Voice. I like having the Places buttons be always available; less adamant about things like Levels. Maybe some user parameterization?
The fact that Voice buttons don't make their own menu line is a bug. I plan to fix it.
--------------------------------------
Date: Thu, 19 Jun 86 15:45:07 PDT
From: donahue.pa
Subject: Re: Would it be possible to clean up the menu mess some?
In-reply-to: "Your message of Thu, 19 Jun 86 15:18:55 PDT"
To: Swinehart, TiogaImplementors^, WalnutSupport^
Cc: donahue
Reply-to: donahue.pa
You've come to the right place (aren't databases wonderful) — I happen to have the collection of messages from three years ago on overloaded buttons. Here they are:
Date: Sun, 27 Mar 83 10:08 PST
From: Taft.PA
Subject: Overloaded buttons
To: CedarDiscussion
A number of Cedar tools have chosen to conserve screen real-estate by multiplexing several functions onto each button in the menu. Left, middle, and right clicks of a button have different meanings, and for a few buttons the meaning is further modified by the shift and/or control keys.
As the number of tools has increased, there has been an explosion of independent meanings assigned to the different mouse buttons and control/shift mouse button combinations. There is no consistent user model for these assignments. I am finding it increasingly difficult to remember all of them, and I think the situation has gotten rather badly out-of-hand.
I have an alternative proposal. The "primary" function of a button (i.e., the one corresponding most directly to the button's label) should be invoked by the left mouse button, as it is now.
All the other, "secondary" functions should be collected together in a subsidiary menu, which is brought up when you click the button with the middle mouse button. I have in mind something along the lines of the Smalltalk/Tajo-style pop-up menu, though I imagine there are other possible arrangements that would also be satisfactory.
I don't have any systematic use for the right mouse button. Perhaps the most frequently-used secondary function can be invoked by it. Users can learn about this if they want to, but they don't have to since the secondary function is also available in the subsidiary menu. For completeness, the subsidiary menu should also include the primary function.
Examples:
Compile: left click: compiles file
middle click: brings up menu {Compile, Bind, CompileAndBind}
Set: left click: sets breakpoint at selected place
middle click: brings up menu {Set, BreakEntry, BreakExit}
In order for this scheme to have any benefit, all tools must be converted to use it. This suggests that the Menus interface should be changed along the following lines.
Current:
ClickProc, MenuProc: TYPE = PROC [parent: REF ANY, clientData: REF ANY ← NIL, mouseButton: MouseButton ← red, shift, control: BOOL ← FALSE] ;
CreateEntry: PROC [name: Rope.ROPE, proc: ClickProc, clientData: REF ANY ← NIL, documentation: REF ANY ← NIL, fork: BOOL ← TRUE, guarded: BOOL ← FALSE] RETURNS [entry: MenuEntry] ;
Proposed:
ClickProc, MenuProc: TYPE = PROC [parent: REF ANY, clientData: REF ANY ← NIL, function: ATOM] ;
CreateEntry: PROC [functions: LIST OF ATOM, proc: ClickProc, clientData: REF ANY ← NIL, fork: BOOL ← TRUE, guarded: BOOL ← FALSE] RETURNS [entry: MenuEntry] ;
The primary name of the button is the print name of the first atom in the functions list, and clicking it with the left mouse button calls proc[..., function: a] where a is that atom. The second atom in the list is similarly associated with the right mouse button. The middle mouse button brings up a subsidiary menu consisting of the entire functions list, and releasing the middle mouse button over one of the buttons in that menu calls proc[..., function: a] where a is the corresponding atom.
I think this scheme also subsumes the purpose presently served by the "documentation" argument, so I have omitted it.
Comments?
Ed
Date: 27-Mar-83 16:43:59 PST
From: teitelman.pa
Subject: Re: Overloaded buttons
In-reply-to: Taft's message of Sun, 27 Mar 83 10:08 PST
To: Taft.pa
cc: CedarDiscussion^
Reply-To: teitelman
I agree that the buttons are overloaded and that something has to be done. I have long pushed for a universal "documentation" button (and personaly believe it would continue to be useful in addition to a subsidiary menu, e.g. suppose you don't understand what some of the items on the subsidiary menu mean?). However, your proposal makes it impossible to button ahead, or simply button quickly, some esoteric command even if it is one that an individual user performs often. In other words, it makes the system easier to learn to use at the expense of giving up the ability to become expert.
I would modify your proposal slightly, which is to retain some universal way of obtaining a subsidiary menu, but in addition allow the user to specify the semantics of the right button via a mapping in his user profile. I would also prefer seeing the subsidiary menu invoked via some use of shift/ctrl, or possibly double clicking of left button so that the individual user could also specify the semantics of the middle button.
But I agree wholeheartedly with you that we need some more standardization.
warren
Date: 28-Mar-83 9:00:15 PST
From: paxton.pa
Subject: Re: Overloaded buttons
In-reply-to: Taft's message of Sun, 27 Mar 83 10:08 PST
To: Taft.pa
Reply-To: Paxton
cc: CedarDiscussion^
Ed,
YES! We should have a standard convention for menu buttons. And as Warren points out, we should still be able to include accelerators for "non-primary" operations. How about the following proposal:
Holding CTRL down when click a menu button brings up a pop up menu (no matter which mouse button is used, so you just have to remember CTRL). The pop up menu stays up as long as CTRL is held down, and while it is up you cannot click anything else (perhaps this restriction can be relaxed, but do we really want several pop-up menus up at once?). You can do multiple operations in the pop-up menu, but as soon as you release CTRL, the menu goes away. Perhaps the menu should include a HELP entry that defines the different menu commands. This would take care of the desire for documentation without dedicating a mouse button.
There will be a standard mapping from entries in the pop up menu to buttons as an accelerator for use by "expert" users. For example,
1st menu entry available by LEFT button
2nd available by MIDDLE button
3rd available by RIGHT button
4th by LEFT-SHIFT
5th by MIDDLE-SHIFT
6th by RIGHT-SHIFT
This proposal satisfies the need for a standard convention. It is upward compatible with the current user-interface. It is easy to explain to new users. The mapping from pop-up entries to mouse buttons is simple so users will quickly learn to use the accelerators. It supports new users without penalizing experts.
Let's do it.
--Bill
Date: 28-Mar-83 9:17:19 PST
From: McGregor.pa
Subject: Re: Overloaded buttons
In-reply-to: Taft's message of Sun, 27 Mar 83 10:08 PST
To: Taft.pa
cc: CedarDiscussion^
Reply-to: McGregor
Ed;
Thanks for your pop-up menu proposal-- I think it has quite a bit of merit.
When designing a menu system, I try to keep the following criteria in mind:
1) How simple is the user model? i.e. how easy is it for the user to remember/guess the action that will result from invoking a command with the various comninations of mouse buttons and shift keys.
2) How much functionality is provided for the cost of the resources? Perhaps you could measure this in units of commands per screen area or some such.
3) How fast and easy is the mechanism to use for experts (assuming you've already paid the overhead to remember all the functions)?
The current scheme does pretty well by metrics (2) and (3), but as you point out, pretty lousy on metric (1). A pop-up scheme for the "secondary" functions would really improve (1) at some cost of (3) since now the user has to scan the list visually to find the function and has no way to "click ahead". (As an example, the various Tioga operations on 'Clear' and 'Get' are commands that are very useful to "click ahead").
As an additional thing to think about, I have some inclination to make us more compatible with the Xerox product 2-button mouse, in which case the pop-up scheme becomes valuable to preserve the functionality we have today.
Command schemes are interesting to me and I'd be interested in other people's thoughts...
Scott.
Date: 28 March 1983 12:33 pm EST (Monday)
From: Lampson.PA
Subject: Re: Overloaded buttons
In-reply-to: Your message of 28-Mar-83 9:00:15 PST
To: Paxton
cc: CedarDiscussion^
I like this proposal, and have one small extension to propose. Different users may well have different ideas about what is common, so it would be nice if the choice of operations invoked by buttons could be set in the profile, as Warren suggested. How about a list of atoms which determines the order of menu items (and hence, by your proposal, the meaning of button clicks)? The only problem I can see with this is that it will be hard to use a Cedar with an unfamiliar profile, but this probably happens seldom, and it's always possible to use the menu for everything in case of confusion.
If there is going to be a standard HELP entry, I think it should be in a standard place in each pop-up menu, namely first, and your table of menu-button correspondences should be shifted by one:
2nd menu entry available by LEFT button
3rd available by MIDDLE button
4th available by RIGHT button
5th by LEFT-SHIFT
6th by MIDDLE-SHIFT
7th by RIGHT-SHIFT
About two-button mouse compatibility: could we standardize on Left+Right=Middle? A user with a two-button mouse could use a profile which minimizes the use of this combination.
Date: Mon, 28 Mar 83 09:52 PST
From: Taft.PA
Subject: Re: Overloaded buttons
In-reply-to: "Your message of 28-Mar-83 9:00:15 PST"
To: Paxton
cc: CedarDiscussion^
Bill, I would be very happy with your version of the proposal.
I have one comment to make about a point that was brought up by both Warren and Scott, with regard to "buttoning ahead". It is currently the case (and rightly so) that feedback from clicking menu buttons is immediate, even if the action invoked by the button is deferred. I see no reason in principle why this should not extend to the operation of a pop-up menu. That is, CTRL-click on a menu button should bring up the pop-up menu immediately, and the button selected from it should have its action queued for later execution, just the same as is now done for top-level buttons.
Ed
Date: 28-Mar-83 10:26:03 PST
From: Horning.pa
Subject: Re: Overloaded buttons
In-reply-to: Taft's message of Mon, 28 Mar 83 09:52 PST
To: Taft.pa
cc: Paxton, CedarImplementors^
Reply-To: Horning
Ed,
This lack of uniformity has bothered me for some time, but I didn't have a concrete solution. Your proposal, as modified by Paxton and Lampson, seems to be an improvement on the present situation in all dimensions. Let's go for it!
Jim H.
Date: 28-Mar-83 10:43:07 PST
From: teitelman.pa
Subject: Re: Overloaded buttons
In-reply-to: Taft's message of Mon, 28 Mar 83 09:52 PST
To: Taft.pa
cc: Paxton, CedarDiscussion^
Reply-To: teitelman
I liked Bill's proposal with Butler's modification. I think having HELP be a standard entry in the popup menu answers my concerns about online documentation. I would be willing to do the work to convert user profile entries into the appropriate invokations if that is at all helpful.
I wanted to make one comment about Ed's response: "That is, CTRL-click on a menu button should bring up the pop-up menu immediately, and the button selected from it should have its action queued for later execution, just the same as is now done for top-level buttons."
Depending on anything happening "immediately" is not a good idea, because even very simple operations can take a long time if the system is heavily engaged in some other high priority task. I tend to view use of the popup menu as for those cases where you are not sure of the right coombination of mouse and control buttons, or simply need prompting. It would be nice if it were fast, but I think the expert user would always tend to use the more esoteric way of invoking the operation directly, e.g. using a different mouse button or ctrl/shift combination.
warren
Date: 28 March 1983 3:13 pm PST (Monday)
From: Spreitzer.PA
Subject: Re: Overloaded buttons
In-reply-to: Taft's message of Sun, 27 Mar 83 10:08 PST
To: Taft
cc: CedarDiscussion^
Reply-To: Spreitzer
I, too, have noticed this problem, and like the latest proposal+ammendments, but... must it be restricted to MENU buttons? Other buttons are overloaded as well (perhaps even more). One problem leaps to mind, however: where to put the submenu for a general button. A few solutions: 1) put the submenu in the MessageWindow, 2) add it to the menu of the top level Viewer containing the Button, or 3) add parameters to Buttons.Create that allow a client to determine where the submenu goes.
Mike
Date: 28 March 1983 6:29 pm PST (Monday)
From: Swinehart.PA
Subject: Re: Overloaded buttons
In-reply-to: Your message of 28-Mar-83 9:00:15 PST
To: Paxton
cc: CedarDiscussion^, Swinehart
Reply-To: Swinehart
Your proposal for treatment of menu buttons (as amended) is WONDERFUL; it eliminated in one fell swoop all of the objections that I was about to make to Ed's proposal -- most of which were mentioned by one or another of the other respondants.
Random comments:
I think it can be proven, based on Stu Card's results if not pure intuition, that pop-up menus should always appear with the same list element under the cursor (as opposed to the Tajo approach of remembering the most recently-invoked operation and putting that under the cursor next time.) One's mind and body will both be able to learn where the buttons are much more reliably if things don't move around.
I'd rather not have HELP as the first element, unless the cursor is always presented positioned over the second.
In any case, this is going to shave off one more of the rough edges in the Cedar user interface; soon it will look positively spherical.
Dan
--------------------------------------
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
14 Aug 86 To: CedarUs... Overloading Buttons, again (finally?)
Date: Thu, 14 Aug 86 15:54:56 PDT
From: Spreitzer.pa
Subject: Overloading Buttons, again (finally?)
To: CedarUsers^.pa
Cc: Spreitzer
Reply-to: Spreitzer.pa
There's this problem we all hate, which is that Buttons tend to get a lot of functionality behind them by the obscure method of decoding which mouse button was used to click them and whether any control or shift key was held down. Since this decoding isn't visible, it's easy to forget, and hard to intuit in the first place. There's this solution that's been kicking around. It says that if you click down on a Button, but don't let up quickly, you get a pop-up menu, with mnemonic entries, that correspond to the tricky decoding. That is, quickly left-clicking the Button is equivalent to letting the pop-up menu appear and choosing the first entry; middle-click gets the second, and so on. Thus, if you don't know the decoding, just slow-click and choose from the pop-up menu. On the other hand, if you know the coding and want to go fast, you can.
Well, I finally got tired of anticipation, and decided to take a whack at it. Have a look at [Cedar]<CedarChest6.1>Top>PopUpButtons.DF=>PopUpButtons.Mesa. Is this what we want?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
14 Aug 86 Nickell.pasa Re: Overloading Buttons, again (finally?)
Date: Thu, 14 Aug 86 16:52:48 PDT
From: Nickell.pasa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Thu, 14 Aug 86 15:54:56 PDT"
To: Spreitzer.pa
Cc: Nickell
Mike:
Looks good. Here's some initial thoughts (shooting from the hip...I've haven't tried the implementation as PopUpButtonsImpl.BCD doesn't seem to be there).
1) I have some worries about the delay time cross-over point, i.e. the user is letting up on the button just as PopUpButtons has decided that the user needs the menu.
2) I have a slight preference for having the client specify the mapping from control/shift/mouse combinations to ATOMs explicitly, such as...
Create:
PROC [
viewerInfo: ViewerClasses.ViewerRec ← [],
proc: PopUpButtonProc,
clientData: REF ANY ← NIL,
choices: LIST OF Choice ← NIL,
documentation: ROPEList ← NIL,
showShortCuts: BOOL ← TRUE
] RETURNS [button: Viewer];
Choice:
TYPE ~
RECORD [
map: ATOM,
shift, control: Option ← ignore,
left, middle, right: Option ← up
];
Option: TYPE ~ {up, down, ignore};
The implementation (obviously) would go through the choices and find the first appropriate one. A choice where none of left, middle, and right are down is understood to be an ATOM that can be generated ONLY via the pop up menu. Also note that if showShortCuts is TRUE, then PopUpButtons would append to each ATOM found in choices, a combination which would activate that ATOM.
This approach is somewhat more verbose for the client programmer than the original you proposed, but possibly more self-documenting, and also more flexible for the client. He has more control over the order of ATOMs in the menu, while making it easier for a casual or novice user to learn new shortcuts. And he can have 5 or 7 items in the list, skipping some unused combination in the middle.
(Should documentation be moved to inside each choice?)
3) I don't know how you're doing the implementation, but both schemes might be amenable to automatically crafting a TIP table on the fly if necessary to get performance. It's also possible, I guess, to build data structures to construct the pop-up menu and decode the results more quickly, if we're bogging the poor DLions down.
For what's it's worth...
Eric
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
14 Aug 86 To: Nickell.pasa Re: Overloading Buttons, again (finally?)
Date: Thu, 14 Aug 86 17:06:52 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Thu, 14 Aug 86 16:52:48 PDT"
To: Nickell.pasa
Cc: Spreitzer
I worry about 1 too, a little. Perhaps when the pop-up menu pops up, it should do so such that the cursor is not in it, so letting up will do nothing, which is better than picking some menu item, when you thought you were using the accellerator.
I'm not sure why you want (2). The client already specifies the mapping from control/shift/mouse combinations to ATOMs explicitly --- by position in the list. The way I have it so far, you can have 5 or 7 items in the list --- it just fills up from the "start" for as much as you've got. We could allow NIL ATOMs to designate "holes" in the code space.
Perhaps it should be a LIST OF <choice, document> rather than <LIST OF choice, LIST OF document>.
I'm not sure of the implementation yet myself either. I hope to be able to take advantage of the existing PopUpMenu package.
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
14 Aug 86 Nickell.pasa Re: Overloading Buttons, again (finally?)
Date: Thu, 14 Aug 86 17:37:09 PDT
From: Nickell.pasa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Thu, 14 Aug 86 17:06:52 PDT"
To: Spreitzer.pa
Cc: Nickell
Re (2). I agree that either scheme, given appropriate conventions, can be made to work. Consider the situation where a programmer want to provide functionality on all three mouse buttons, but only overload the left mouse button. As I understand the current scheme of things, the client code will look something like
button ← PopUpButtons.Create[
viewerInfo: [],
proc: MyButtonProc,
choices: LIST[$LeftAction, $MiddleAction, $RightAction, $LeftShiftAction, $MiddleAction, $RightAction, $LeftControlAction, $MiddleAction, $RightAction, NIL, $MiddleAction, $RightAction, $ActionAvailableOnlyFromPopUpMenu],
documentation: LIST[leftDoc, middleDoc, rightDoc, leftShiftDoc, middleDoc, rightDoc, leftControlDoc, middleDoc, rightDoc, NIL, middleDoc, rightDoc]
];
The second scheme, however, would require the client call to look like ...
button ← PopUpButtons.Create[
viewerInfo: [],
proc: MyButtonProc,
choices:
LIST [
[map: $LeftAction, doc: "Whatever the user puts here...", left: down, shift: up, control: up],
[map: $LeftShiftAction, doc: leftShiftDoc, left: down, shift: down, control: up],
[map: $LeftControlAction, doc: leftControlDoc, left: down, shift: up, control: down],
[map: $MiddleAction, doc: middleDoc, middle: down],
[map: $RightAction, doc: rightDoc, right: down],
[map: $ActionAvailableOnlyFromPopUpMenu]
]
];
My feeling is that this second, though slightly more verbose, documents itself better. Further, under the first scheme, the implementation would have to eliminate duplicate ATOM's by hand or abuse the user with multiple identical entries in the pop-up menu. (Note that the client desire to have shift and control ignored only for the middle and right buttons.)
Note also that the client has more control over the presentation of the pop-up menu. For example, he could call with
button ← PopUpButtons.Create[
viewerInfo: [],
proc: MyButtonProc,
choices:
LIST [
[map: $ActionAvailableOnlyFromPopUpMenu],
[map: $LeftAction, doc: "Whatever the user puts here...", left: down, shift: up, control: up],
[map: $MiddleAction, doc: middleDoc, middle: down],
[map: $RightAction, doc: rightDoc, right: down],
[map: $LeftShiftAction, doc: leftShiftDoc, left: down, shift: down, control: up],
[map: $LeftControlAction, doc: leftControlDoc, left: down, shift: up, control: down]
]
];
instead. I think that such flexibility could
aid the end user rather than confuse him,
if it's coupled with automatically documenting the short-cut in the menu. I.e., this pop-up menu would read...
ActionAvailableOnlyFromPopUpMenu
LeftAction (Left)
MiddleAction (Middle)
RightAction (Right)
LeftShiftAction (Shift-Left)
LeftControlAction (Control-Left)
Anyway, that's why I had the preference.
Eric
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
14 Aug 86 To: Nickell.pasa Re: Overloading Buttons, again (finally?)
Date: Thu, 14 Aug 86 17:47:57 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Thu, 14 Aug 86 17:37:09 PDT"
To: Nickell.pasa
Cc: Spreitzer
Ah. I thought it unlikely that anyone would want to have such a non-uniform decoding. Do you have instances where you actually want it?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
14 Aug 86 Nickell.pasa Re: Overloading Buttons, again (finally?)
Date: Thu, 14 Aug 86 18:09:37 PDT
From: Nickell.pasa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Thu, 14 Aug 86 17:47:57 PDT"
To: Spreitzer.pa
Cc: Nickell
I think there might be. For example, the existing system "Color" button provided by ColorDisplay provide 3 options. Left turns the cd on and off. Right builds a ColorDisplay Tool. Middle shuts down the display (giving the dorado a bit more cpu) for about 10 secs. With a non-uniform coding available, I might leave the left and right buttons alone, but change the middle button so that middle selects 24-bit, shift-middle selects 8-bit dithered, control-middle selects 8-bit gray, and might as well throw 1-bit on control-shift-middle. The cpu-hack, and 2-bit and 4-bit could be on the pop-up, although they don't get key combinations.
The idea is that left has a single meaning, and is frequently used. Right is used less frequently, but enough to warrant its own key. Middle is unlikely to be used, but some experts who switch back and forth a lot between two color display configurations might appreciate extreme overloading on that button.
(I'm not even suggesting that the scheme outlined above is the best, but I see no reason to exclude it.)
While I did show a non-uniform coding, I think that the second approach is more self-documenting to a program reader even when a uniform coding is used. The first approach requires a program reader to mentally construct the decoding based on the values of decodeX ("left", "middle", "right", then, uh, "control-left", "control-middle", "control-right"), and then match them against then list elements. The second approach places that information at the decode explicitly.
Eric
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15 Aug 86 Plass.pa Re: Overloading Buttons, again (finally?)
Date: 15 Aug 86 11:21:21 PDT
From: Plass.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Spreitzer's message of Thu, 14 Aug 86 15:54:56 PDT"
To: Spreitzer
cc: Windex^.pa
It looks like a pretty good first cut, Mike. I suggest that when the pop-up menu comes up, it should be positioned so that the item selected is the one selected by the chord; as it is now, if my timing is a little slow I will get a NOP instead of the chord-selected operation. The time delay could then be made very short without much affecting the semantics of the click.
Maybe the pop-up should disappear when the cursor moves outside of it. This would make it easy to browse the operations hidden under a cluster of buttons by sliding the mouse around. It would also make it feel a little less preemptive, I think. It might make life a little exciting for fastmouse users, though.
The interface should say wether or not the PopUpButtonProc is forked.
Is it feasible to put this functionality under Menu items also?
The documentation doesn't show up on the message window as the interface claims.
The cursor doesn't change back to its normal shape until you move the mouse.
Michael.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15 Aug 86 PeterKessler.pa Re: Overloading Buttons, again (finally?)
Date: Fri, 15 Aug 86 11:42:12 PDT
From: PeterKessler.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Plass' message of 15 Aug 86 11:21:21 PDT"
To: Spreitzer
Cc: Windex^
Reply-to: PeterKessler.pa
Would it be possible to decide that one wanted pull-down menus instead of pop-up menus? Pull-down menus don't take up a lot of real estate, so you can leave them up if you have found one you use a lot. That assumes that someone has written them to disappear if you click them one way, and to stick around if you click them some other way. Plus, pull-down menus don't do as much violence to the tiling paradigm. Maybe I should try to get my thoughts together on this whole can of worms.
How do popup menus handle guarded buttons? For example, the PressPrintMsgSet button in Walnut isn't guarded any more.
... peter
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15 Aug 86 To: Plass Re: Overloading Buttons, again (finally?)
Date: Fri, 15 Aug 86 13:30:07 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Plass' message of 15 Aug 86 11:21:21 PDT"
To: Plass
Cc: Spreitzer, Windex^, Nickell.pasa, Jacobi.pa
Reply-to: Spreitzer.pa
``I suggest that when the pop-up menu comes up, it should be positioned so that the item selected is the one selected by the chord; as it is now, if my timing is a little slow I will get a NOP instead of the chord-selected operation. The time delay could then be made very short without much affecting the semantics of the click.''
Sounds like a good idea to me. I think I'll do it --- it looks easy.
``Maybe the pop-up should disappear when the cursor moves outside of it. This would make it easy to browse the operations hidden under a cluster of buttons by sliding the mouse around. It would also make it feel a little less preemptive, I think. It might make life a little exciting for fastmouse users, though.''
Also sounds good to me. Would require changes to PopUpMenu.
``The interface should say wether or not the PopUpButtonProc is forked.''
It already does. See position 1591..1633 (including comment ndoes) --- the second-to-last sentence in the first comment paragraph after the declaration of Create.
``Is it feasible to put this functionality under Menu items also?''
I think so, modulo the fact that Menus are part of the Cedar Release.
``The documentation doesn't show up on the message window as the interface claims.''
The existing implementation does not yet fully implement the interface. I want to be able to use Christian Jacobi's PopUpMenu package, and he hasn't yet implemented the documentation function (although he told me he likes the idea and will look into it).
``The cursor doesn't change back to its normal shape until you move the mouse.''
I think that's a bug in PopUpMenus.
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15 Aug 86 To: Windex^... Re: Overloading Buttons, again (finally?)
Date: Fri, 15 Aug 86 13:33:54 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
To: Windex^.pa, Jacobi.pa
Cc: Spreitzer.pa, Nickell.pasa
Reply-to: Spreitzer.pa
Eric and I have been having this interesting discussion about how the client specifies the relation between quick-clicks and the pop-up menu. I wonder what other people think.
--------------------------------------
Date: Thu, 14 Aug 86 16:52:48 PDT
From: Nickell.pasa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Thu, 14 Aug 86 15:54:56 PDT"
To: Spreitzer.pa
Cc: Nickell
Mike:
Looks good. Here's some initial thoughts (shooting from the hip...I've haven't tried the implementation as PopUpButtonsImpl.BCD doesn't seem to be there).
1) I have some worries about the delay time cross-over point, i.e. the user is letting up on the button just as PopUpButtons has decided that the user needs the menu.
2) I have a slight preference for having the client specify the mapping from control/shift/mouse combinations to ATOMs explicitly, such as...
Create:
PROC [
viewerInfo: ViewerClasses.ViewerRec ← [],
proc: PopUpButtonProc,
clientData: REF ANY ← NIL,
choices: LIST OF Choice ← NIL,
documentation: ROPEList ← NIL,
showShortCuts: BOOL ← TRUE
] RETURNS [button: Viewer];
Choice:
TYPE ~
RECORD [
map: ATOM,
shift, control: Option ← ignore,
left, middle, right: Option ← up
];
Option: TYPE ~ {up, down, ignore};
The implementation (obviously) would go through the choices and find the first appropriate one. A choice where none of left, middle, and right are down is understood to be an ATOM that can be generated ONLY via the pop up menu. Also note that if showShortCuts is TRUE, then PopUpButtons would append to each ATOM found in choices, a combination which would activate that ATOM.
This approach is somewhat more verbose for the client programmer than the original you proposed, but possibly more self-documenting, and also more flexible for the client. He has more control over the order of ATOMs in the menu, while making it easier for a casual or novice user to learn new shortcuts. And he can have 5 or 7 items in the list, skipping some unused combination in the middle.
(Should documentation be moved to inside each choice?)
3) I don't know how you're doing the implementation, but both schemes might be amenable to automatically crafting a TIP table on the fly if necessary to get performance. It's also possible, I guess, to build data structures to construct the pop-up menu and decode the results more quickly, if we're bogging the poor DLions down.
For what's it's worth...
Eric
--------------------------------------
Date: Thu, 14 Aug 86 17:06:52 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Thu, 14 Aug 86 16:52:48 PDT"
To: Nickell.pasa
Cc: Spreitzer
I worry about 1 too, a little. Perhaps when the pop-up menu pops up, it should do so such that the cursor is not in it, so letting up will do nothing, which is better than picking some menu item, when you thought you were using the accellerator.
I'm not sure why you want (2). The client already specifies the mapping from control/shift/mouse combinations to ATOMs explicitly --- by position in the list. The way I have it so far, you can have 5 or 7 items in the list --- it just fills up from the "start" for as much as you've got. We could allow NIL ATOMs to designate "holes" in the code space.
Perhaps it should be a LIST OF <choice, document> rather than <LIST OF choice, LIST OF document>.
I'm not sure of the implementation yet myself either. I hope to be able to take advantage of the existing PopUpMenu package.
Mike
--------------------------------------
Date: Thu, 14 Aug 86 17:37:09 PDT
From: Nickell.pasa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Thu, 14 Aug 86 17:06:52 PDT"
To: Spreitzer.pa
Cc: Nickell
Re (2). I agree that either scheme, given appropriate conventions, can be made to work. Consider the situation where a programmer want to provide functionality on all three mouse buttons, but only overload the left mouse button. As I understand the current scheme of things, the client code will look something like
button ← PopUpButtons.Create[
viewerInfo: [],
proc: MyButtonProc,
choices: LIST[$LeftAction, $MiddleAction, $RightAction, $LeftShiftAction, $MiddleAction, $RightAction, $LeftControlAction, $MiddleAction, $RightAction, NIL, $MiddleAction, $RightAction, $ActionAvailableOnlyFromPopUpMenu],
documentation: LIST[leftDoc, middleDoc, rightDoc, leftShiftDoc, middleDoc, rightDoc, leftControlDoc, middleDoc, rightDoc, NIL, middleDoc, rightDoc]
];
The second scheme, however, would require the client call to look like ...
button ← PopUpButtons.Create[
viewerInfo: [],
proc: MyButtonProc,
choices:
LIST [
[map: $LeftAction, doc: "Whatever the user puts here...", left: down, shift: up, control: up],
[map: $LeftShiftAction, doc: leftShiftDoc, left: down, shift: down, control: up],
[map: $LeftControlAction, doc: leftControlDoc, left: down, shift: up, control: down],
[map: $MiddleAction, doc: middleDoc, middle: down],
[map: $RightAction, doc: rightDoc, right: down],
[map: $ActionAvailableOnlyFromPopUpMenu]
]
];
My feeling is that this second, though slightly more verbose, documents itself better. Further, under the first scheme, the implementation would have to eliminate duplicate ATOM's by hand or abuse the user with multiple identical entries in the pop-up menu. (Note that the client desire to have shift and control ignored only for the middle and right buttons.)
Note also that the client has more control over the presentation of the pop-up menu. For example, he could call with
button ← PopUpButtons.Create[
viewerInfo: [],
proc: MyButtonProc,
choices:
LIST [
[map: $ActionAvailableOnlyFromPopUpMenu],
[map: $LeftAction, doc: "Whatever the user puts here...", left: down, shift: up, control: up],
[map: $MiddleAction, doc: middleDoc, middle: down],
[map: $RightAction, doc: rightDoc, right: down],
[map: $LeftShiftAction, doc: leftShiftDoc, left: down, shift: down, control: up],
[map: $LeftControlAction, doc: leftControlDoc, left: down, shift: up, control: down]
]
];
instead. I think that such flexibility could
aid the end user rather than confuse him,
if it's coupled with automatically documenting the short-cut in the menu. I.e., this pop-up menu would read...
ActionAvailableOnlyFromPopUpMenu
LeftAction (Left)
MiddleAction (Middle)
RightAction (Right)
LeftShiftAction (Shift-Left)
LeftControlAction (Control-Left)
Anyway, that's why I had the preference.
Eric
--------------------------------------
Date: Thu, 14 Aug 86 17:47:57 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Thu, 14 Aug 86 17:37:09 PDT"
To: Nickell.pasa
Cc: Spreitzer
Ah. I thought it unlikely that anyone would want to have such a non-uniform decoding. Do you have instances where you actually want it?
Mike
--------------------------------------
Date: Thu, 14 Aug 86 18:09:37 PDT
From: Nickell.pasa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Thu, 14 Aug 86 17:47:57 PDT"
To: Spreitzer.pa
Cc: Nickell
I think there might be. For example, the existing system "Color" button provided by ColorDisplay provide 3 options. Left turns the cd on and off. Right builds a ColorDisplay Tool. Middle shuts down the display (giving the dorado a bit more cpu) for about 10 secs. With a non-uniform coding available, I might leave the left and right buttons alone, but change the middle button so that middle selects 24-bit, shift-middle selects 8-bit dithered, control-middle selects 8-bit gray, and might as well throw 1-bit on control-shift-middle. The cpu-hack, and 2-bit and 4-bit could be on the pop-up, although they don't get key combinations.
The idea is that left has a single meaning, and is frequently used. Right is used less frequently, but enough to warrant its own key. Middle is unlikely to be used, but some experts who switch back and forth a lot between two color display configurations might appreciate extreme overloading on that button.
(I'm not even suggesting that the scheme outlined above is the best, but I see no reason to exclude it.)
While I did show a non-uniform coding, I think that the second approach is more self-documenting to a program reader even when a uniform coding is used. The first approach requires a program reader to mentally construct the decoding based on the values of decodeX ("left", "middle", "right", then, uh, "control-left", "control-middle", "control-right"), and then match them against then list elements. The second approach places that information at the decode explicitly.
Eric
--------------------------------------
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15 Aug 86 To: PeterKessler Re: Overloading Buttons, again (finally?)
Date: Fri, 15 Aug 86 13:35:48 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Fri, 15 Aug 86 11:42:12 PDT"
To: PeterKessler
Cc: Spreitzer, Windex^.pa, Nickell.pasa, Jacobi.pa
Reply-to: Spreitzer.pa
What's a pull-down menu?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15 Aug 86 To: PeterKessler Re: Overloading Buttons, again (finally?)
Date: Fri, 15 Aug 86 13:38:31 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Fri, 15 Aug 86 11:42:12 PDT"
To: PeterKessler
Cc: Spreitzer, Windex^.pa, Jacobi.pa, Nickell.pasa
Reply-to: Spreitzer.pa, Windex^.pa, Jacobi.pa, Nickell.pasa
I haven't had any good ideas about what it should mean for a PopUpButton to be guarded.
Some ideas:
1) You must remove the guard, and then you get PopUpButton behavior.
2) A guarded PopUpButton always forces you to go through the PopUpMenu.
Evaluations? Other ideas?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15 Aug 86 Nickell.pasa Re: Overloading Buttons, again (finally?)
Date: Fri, 15 Aug 86 13:45:10 PDT
From: Nickell.pasa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Fri, 15 Aug 86 13:30:07 PDT"
To: Spreitzer.pa, Jacobi.pa
Cc: Nickell, Plass.pa, Windex^.pa
Reply-to: Nickell.pasa
Mike & Christian,
If you're feeling particularly ambitious, you might consider implementing a PopUpViewer package while you're fiddling around in this area, which allows a client to preempt a (1) viewer, (2) column, (3) display, or (4) Terminal.Virtual with his own Viewer and TIP table. This package would handle some of what PopUpMenu currently does. PopUpMenu would be greatly simplified, as it became a client of PopUpViewer. PopUpViewer could also be used, however, to implement Mac-style dialogue boxes (but note that the client has the option of preempting a single viewer or the whole world, as appropriate) or possibly even allow Magnify to be simplified.
Eric
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15 Aug 86 Frailong.pa Re: Overloading Buttons, again (finally?)
Date: Fri, 15 Aug 86 16:18:42 PDT
From: Frailong.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Thu, 14 Aug 86 15:54:56 PDT"
To: Spreitzer
Cc: Frailong
I am a little surprised that your initiative had to wait for a little more than 3 years! It's obviously (at least in my mind) an excellent idea. There is a slight problem as to where the pop-up menu appears and where the mouse is positionned with respect to the pop-up menu. I don't really know what the good solution is. It's probably to have the mouse positionned at a fixed place in the pop-up menu in order to ensure repetitivity of user actions. The time delay after which the pop-up menu appears feels OK.
Another of the suggestions mentionned in the PopUpButtonsDoc is to have a systematic HELP facility. I believe it would be most welcome to novice users (and also to experts faced to a little used command or a new package).
A difficulty I see is the number of people that will have to change their user interface. It's for the better, but I expect some feet dragging.
Jean-Marc
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15 Aug 86 Swinehart.pa Buttons discussions
Date: Fri, 15 Aug 86 17:15:44 PDT
From: Swinehart.pa
Subject: Buttons discussions
In-reply-to: "Spreitzer's message of Fri, 15 Aug 86 13:38:31 PDT"
To: Spreitzer
Cc: Windex^, Nickell.pasa, Swinehart
I'm obviously interested in all this, but haven't the time for careful perusal, since vacation looms large. Most of the discussion so far seems constructive. My personal prejudice is for not hairing up this implementation too much. After all, the whole idea is to put an ultimately simple model underneath what is now a hodge-podge of mysterious buttons. Some of the Nickell ideas seem to imply that the order of items in a menu wouldn't necessarily correspond to a learned standard ordering of accelerators (left, middle, right, left-SHIFT, ...., and so on.) Maybe I'm misinterpreting? It seems to document things better for the programmer, but not for the user. I'd buy it if the client specifications were used to sort the entries into the menu. Otherwise, it seems to add user level complexity, just when we were getting rid of some. I guess it might make sense to implement it that way, then to make it easy to produce menus in some "standard" configuration, in the interests of standard Cedar flexibility.
Nickell's concern about the crossover point is allayed by having the menu come up selecting the corresponding accelerated entry, right? (a la Plass and a few of the much earlier proposals) The results of a down-click, hold, up-click want to be the same, however long the button is held, as long as the mouse is not moved.
I have a preference for iconic indications of the shortcuts, rather than symbolic ones. Some sort of picture of the mouse and the shift/control keys to the left of each entry. Check out Viewpoint. What does Gargoyle do?
It would be interesting to treat guarded buttons as buttons with no acceleration -- that forced you through the Pop-up menu. The menu would pop up with the cursor positioned over an empty entry or outside the box or something, so that you would be forced to move the mouse to the selected actual operation. Otherwise, you could just do it as now, with the guard being removed by the first click, then the menu accelerated or popped up with the second.
Guarded buttons have largely lost their value anyway:
The original ones paused half a second or so before removing the guard, so that you couldn't just double-click them. If double-clicking is acceptable behavior, the button shouldn't be guarded!
When things are really dangerous, existing programs now require further confirmation beyond removal of the guard -- like buttons to push in the message window. I favor adding a second guard, and/or even a longer timeout. A message would appear in the message window as soon as the button was pushed, indicating just how dangerous the next move was. Otherwise, why not just do the confirmation bit and forget the guard, which is supposed to be a metaphor for the kinds of physical protection often afforded to dangerous pushbuttons in the real world.
I thought a pull-down menu was a pop-up menu that looked like was being pulled down, like a window shade, from a roller mounted under the button that invoked it (as opposed to the kind that pop up at the cursor location in response to a particular mouse button, which have traditionally been called pop-up menus). In that sense, this design already is an implementation of pull-down menus. I believe Peter considers the Levels and Places menus to be pull-down menus. Who invented the term, and what concept did it apply to? We should be historically accurate here.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
16 Aug 86 lamming.pa Re: Overloading Buttons, again (finally?)
Date: 16 Aug 86 10:50:34 PDT
From: lamming.pa
Subject: Re: Overloading Buttons, again (finally?)
To: Spreitzer.pa, Jacobi.pa
cc: lamming
Reply-To: lamming
I want to add my vote to Eric Nickell's suggestion for PopUpViewers. It would help round off a lot of sharp corners in Cedar. i.e. Having to use the commandtool as a scratch pad for filesnames etc; having the message window solicit confirmation etc.
-- Mik --
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
18 Aug 86 To: Jacobi.pa Indicating the mouse-button&shift key <-> . . .
Date: Mon, 18 Aug 86 11:48:19 PDT
From: Spreitzer.pa
Subject: Indicating the mouse-button&shift key <-> atom code in PopUpButtons
To: Jacobi.pa
Cc: Spreitzer
Dan Swinehart had this to say:
I have a preference for iconic indications of the shortcuts, rather than symbolic ones. Some sort of picture of the mouse and the shift/control keys to the left of each entry. Check out Viewpoint. What does Gargoyle do?
Would it be possible to make PopUpMenu allow the client to draw pictures in the border?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
18 Aug 86 Frailong.pa Buttons and Pop-up menus
Date: Mon, 18 Aug 86 13:40:04 PDT
From: Frailong.pa
Subject: Buttons and Pop-up menus
To: Windex^.pa, Jacobi.pa, Nickell.pasa
Cc: Frailong.pa
Reply-to: Frailong.pa
Having discussed the matter recently with Mike Spreitzer, I have two points that I believe might be of interest regarding the management of buttons and pop-up menus in Cedar.
1. Help and buttons
Providing help information has up to now not been a strong point of Cedar. The facilities provided today are still very primitive: the command description for CommandTool commands (often very terse, syntax not systematic) and the full package-level documentation (but it's often hard to find the name of the documentation for a given program - in general, there is no way to retrieve the DF-file name of a file). I believe that there should be help information at various scopes:
a. Viewer documentation
Most often, viewers are tightly linked to a top-level application. Since top-level viewers always (at least I can think of no exception) have a caption bar, hiding a "Help" button behind the caption bar (as one of the standard viewers buttons) should be quite easy. This help button would probably open up the full-blown documentation file for the top-level package that manages the viewer, or possibly a restricted documentation if more adequate.
b. Command documentation
Viewers that accept textual commands should also provide a systematic way to get information about each command. The CommandTool does that quite decently. The help provided should be very systematic: command syntax, function, reference to the full documentation. It would also be nice if there was an easy way to access the full documentation. Bertrand Serlet has provided an embryo of such a mechanism through a top-bar "Doc" button that basically offers the standard catalogs or looks up a file named <Cmd>Doc.tioga in the version maps.
c. Button and action documentation
The latest model for buttons has been to separate buttons and actions. Buttons may either call actions directly (depending on which mouse key was clicked and the SHIFT/CNTRL status) or may offer the user a pop-up menu giving a choice of actions. My belief is that documentation should be button-oriented. The reason is that buttons usually cluster actions that are tightly related and that the user will probably be interested in all such clustered actions as a group.
My suggestion is thus that each button should provide some help information, such as a list of its possible actions andif necessary open the full-blown documentation (at the right place if relevant...). I do not know what the access mechanism to that help info should be. For buttons that invoke a pop-up menu, the answer is obvious: have systematically a "Help" entry in the menu. For buttons that do not call pop-up menus, the answer is less obvious. The trick might be to do as for pop-up buttons, i.e. call the help info is the button is clicked for a long enough time.
2. Pop-up buttons
There are various ways to implement pop-up menus and pop-up buttons. I would like to describe an alternate method that may be of interest (although I do not know if it would be more convenient that the current method).
Currently, pop-up buttons show their pop-up menus only when they have been clicked. How would things be if pop-up menus appeared when the mouse is on the button (independently of clicks) ? With this new interface, clicking a mouse button would always mean "perform an action". The buttons would just stand for a shortened pop-up menu to save screen real-estate, and would reveal themselves whenever pointed at. Symmetrically, pop-up menus should disappear more easily, by just moving the mouse out of them. Actions would still be taken only when clicking at an entry in the menu.
If I am not mistaken, the MacIntosh has this type of interface. I see one major difference between the Mac and Cedar that would raise trouble for such an interface in Cedar: on the Mac screen, pop-up buttons are only on the screen top caption. Hence, the mouse position never wanders there by chance. In Cedar, buttons are spread all over the screen and I am a bit nervous about the possibility of pop-up menus appearing without the user wanting it, just because the mouse happened to go over the button on the way between two viewers.
Jean-Marc
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
18 Aug 86 To: Windex^.... Re: Overloading Buttons, again (finally?)
Date: Mon, 18 Aug 86 13:47:53 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "My message of Thu, 14 Aug 86 15:54:56 PDT"
To: Windex^.pa, Jacobi.pa, Nickell.pasa, Frailong.pa
Cc: Spreitzer
Reply-to: Spreitzer.pa
Tioga has this wonderful user interface architecture where TIP tables and menu entries both simply send ATOMs (and occasionally other cruft, like mouse positions and repetition counts) to an interpreter which looks up those ATOMs in an extensible registry and executes the commandProcs found there. This means that randoms, like EditorComforts and DefDWIM, can improve or otherwise change the behavior of Tioga.
Unfortunately, there's something that's too fixed. The menu entries must decide which ATOM to send to the interpreter. They do so based on which mouse button was used to click the menu entry, and whether control or shift keys were held down. They do not always depend on the mouse button or keyboard keys used. For example, the standard "Def" menu entry will send one of 6 ATOMs, depending on which mouse button was used and whether the shift key was used, but not whether the control key was used. The dependencies, and codings into ATOMs, were decided back in the mists of time, when Tioga was being created --- and this stuff is not extensible or changeable.
Sometimes a package discovers it wants to change the ATOM coding used by one of those menu entries. For examples, Editor comforts needed to hack the "Position" button, and DefDWIM needed to hack the "Def" button. Not only did they change the interpretation of the ATOMs sent to the interpreter, but they needed to change how the menu entry decided which ATOM to send. Fortunately, this is possible without too much pain. Because of the way menus and menu entries work, there is only one RECORD (it's a Menus.MenuEntryRec) in an entire VM that describes the "Position" menu entry. Once some fields have been changed in this one record, wherever you click "Position", the behavior is as determined by the new field values.
Buttons do not work this way, but they should. If you have many Gargoyle viewers, each one will have a "Load" button, and each such button has a RECORD that specifies its behavior. To change whether the "Load" button cares about which mouse button you click it with, you'd have to find each instance of that button, and change the corresponding record. And you'd have to hack each new instance as it comes into existence. It would be better if there were Button classes and instances. Then you'd only have to find and change the "Load" class.
Thus, I think it would be a good idea if PopUpButtons had classes and instances. Consider using them for something like Tioga's menus. EditorComforts would want to change not only the interpretations of some of the ATOMs sent to Tioga's interpreter, but would also want to change the list of ATOMs that pop up when the "Position" button is held down. It should be able to do this by changing the "Position" class.
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
18 Aug 86 Jacobi.pa Buttons and Pop-up menus
Date: Mon, 18 Aug 86 15:11:56 PDT
From: Jacobi.pa
Subject: Buttons and Pop-up menus
To: Windex^.pa, Spreitzer.pa
Cc: Jacobi
Reply-to: Jacobi.pa
I have tried out pop up menus which display help information in the message window. It is very distracting to change from looking at a pop up menu on the color screen to looking at the message window and back. I have to try out other schemes.
Anyway, did you know: the message window can not display messages while any process holds the viewer lock. Not even when it is the same process.
The message window has the very nice feature of displaying messages for a minimal time. When you move around a pop up menu you want the help information to be changed instantaneously.
Christian
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
19 Aug 86 To: Windex^.... Re: Overloading Buttons, again (finally?)
Date: Tue, 19 Aug 86 11:50:54 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "My message of Thu, 14 Aug 86 15:54:56 PDT"
To: Windex^.pa, Jacobi.pa, Nickell.pasa, Frailong.pa
Cc: Spreitzer
Reply-to: Spreitzer.pa
Currently Buttons and PopUpButtons can have one of three "display styles": BlackOnWhite, WhiteOnBlack, and BlackOnGrey. The idea is that the coloring tries to convey three independent state bits. One is whether or not the procedure behind the button is executing in some process(es). Another is whether a mouse button is depressed over the Button. And the third is available to the client (but the presence of a third display style invites the attempt to cram some more client state bits in); an example is the "boolean" buttons
Text,
Looks,
Format,
Style, and
Comment in the EditTool's search area. The encoding of those three state bits into colors goes like this:
[foreground, background] ←
(IF a mouse button is depressed over the Button THEN Invert ELSE Identity)[
IF the procedure behind the button is executing in some process(es)
THEN [black, sparseGrey]
ELSE SELECT displayStyle FROM
BlackOnWhite => [black, white],
WhiteOnBlack => [white, black],
BlackOnGrey => [black, sparseGrey]]
This is at least a little silly. The third display style sticks out like a sore thumb. At least it should either be eliminated, or a fourth display style, WhiteOn(dense)Grey, should be added (I've heard people claim that white on dense grey doesn't look good, but I don't believe it's so bad it should be forbidden; you can see it for yourself when you depress a BlackOnGrey button). Actually, I'd say mandating this much detail is just wrong. The client should be able to parameterize that whole expression. Thus, it should look more like:
displayStyle: ARRAY --button depressed--BOOL OF ARRAY --executing--BOOL OF RECORD [foreground, background: Color];
[foreground, background] ← displayStyle[depressed][executing];
One might claim, however, that it be important to change the
depressed bit quickly, and thus its encoding should be fixed at inverting. Thus:
displayStyle: ARRAY --executing--BOOL OF RECORD [foreground, background: Color];
[foreground, background] ← (IF depressed THEN Invert ELSE Identity)[displayStyle[executing]];
I'm not convinced of the latter point. One need only repaint when the button is depressed or let up --- and these events are infrequent, since they happen only as fast as a human user can twitch his or her fingers. Is that really infrequently enough?
Thoughts?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
19 Aug 86 To: Windex^.... Re: Overloading Buttons, again (finally?)
Date: Tue, 19 Aug 86 12:21:14 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "My message of Thu, 14 Aug 86 15:54:56 PDT"
To: Windex^.pa, Jacobi.pa, Nickell.pasa, Frailong.pa
Cc: Spreitzer
Reply-to: Spreitzer.pa
When I made my first cut, I decided to identify the operations of a PopUpButton by a LIST OF ATOM. The ATOM's print-name is the text displayed in the pop-up menu, and the ATOM itself is what's given the ButtonProc to identify the operation chosen. This has the advantage that one can write some straightforward client code to specify the operations and decode the choice given:
Create[choices: LIST[$TakePosition, $MessagePosition, $InsertPosition], ...]
PositionButt: PopUpButtonProc = {
SELECT choice
FROM
$TakePosition => ...
$MessagePosition => ...
$InsertPosition => ...}
I could have used a LIST OF ROPE, but decoding the choice in the PopUpButtonProc would then involve a more messy construct with lots of Rope.Equal[]s, which is messier to read and more expensive to execute:
Create[choices: LIST["TakePosition", "MessagePosition", "InsertPosition"], ...]
PositionButt: PopUpButtonProc = {
SELECT
TRUE
FROM
Rope.Equal[choice, "TakePosition"] => ...
Rope.Equal[choice, "MessagePosition"] => ...
Rope.Equal[choice, "InsertPosition"] => ...}
or, if you allow yourself to use object-oriented notation:
PositionButt: PopUpButtonProc = {
SELECT
TRUE
FROM
choice.Equal["TakePosition"] => ...
choice.Equal["MessagePosition"] => ...
choice.Equal["InsertPosition"] => ...}
If you want to have spaces, or any other non-alphanumeric character, in the choice names, it gets more interesting. The LIST OF ROPE technique doesn't care --- it's just as mediocre as it was with "identifier-like" choice texts. However, the technique with ATOMs gets clumsier, since Cedar doesn't have a literal notation for ATOMs with general print-names (sounds of curses and I-told-you-so):
take: ATOM = Atom.MakeAtom["Take Position"];
message: ATOM = Atom.MakeAtom["Message Position"];
insert: ATOM = Atom.MakeAtom["Insert Position"];
Create[choices: LIST[take, message, insert], ...]
PositionButt: PopUpButtonProc = {
SELECT choice
FROM
take => ...
message => ...
insert => ...}
Christian Jacobi has suggested that it might be worthwhile to decouple the text displayed in the PopUpMenu from the value used to indicate which choice is chosen. Thus, the general client would specify a list of pairs of <text displayed, REF given to ButtonProc>:
Create[choices: LIST[["Take Position", $take], ["Message Position", $message], ["Insert Position", $insert]], ...]
PositionButt: PopUpButtonProc = {
SELECT choice
FROM
$take => ...
$message => ...
$insert => ...}
With this scheme, one could provide a sugaring procedure that converts a simple LIST OF ATOM to the general choice spec, and clients satisfied by the first approach could use this more general one with hardly any more pain:
Create[choices: Atoms[LIST[$TakePosition, $MessagePosition, $InsertPosition]], ...]
PositionButt: PopUpButtonProc = {
SELECT choice
FROM
$TakePosition => ...
$MessagePosition => ...
$InsertPosition => ...}
Christian has even revealed that some clients of his PopUpMenu package have already asked to be able to display not text, but a random image of their own drawing, in a menu entry. That would be very general, and avoid the need for creeping featurism in the display of menu entries. The only thing that doesn't allow is animating the menu entries!
Thoughts?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
19 Aug 86 To: Windex^.... Re: Overloading Buttons, again (finally?)
Date: Tue, 19 Aug 86 12:59:07 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "My message of Thu, 14 Aug 86 15:54:56 PDT"
To: Windex^.pa, Jacobi.pa, Nickell.pasa, Frailong.pa
Cc: Spreitzer
Reply-to: Spreitzer.pa
How should PopUpButtons with only one choice behave? With 0 choices? What about the per-entry documentation? What about the button-wide documentation?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
19 Aug 86 Frailong.pa Re: Overloading Buttons, again (finally?)
Date: Tue, 19 Aug 86 14:20:11 PDT
From: Frailong.pa
Original-Date: Tue, 19 Aug 86 14:08:03 PDT
Originally-From: Frailong.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Tue, 19 Aug 86 12:59:07 PDT"
To: Windex^.pa, Jacobi.pa, Nickell.pasa
Cc: Frailong
Reply-to: Frailong.pa
This a reply to your last 3 messages on the subject.
1. Display styles for buttons
No obvious answer from me. The only point I would like to mention is another MacIntosh trick. When an option of a menu does not make sense at a given time (like Reset on an empty file), it set in a diferent tone (greyish I think) that indicates that the operation is not currently available. I believe this is rather better that removing entries when they are not useful, because it is easier for the user to have a fixed set of entries, some of them unavailable, rather than a list that fluctuates with time.
Regarding the display style, having the buttons change slightly when busy is a good point (already enforced by most programs I know). It is especially valuable when a viewer allows multiple buttons to be used at the same time (I'm not sure there are any examples of that currently! ). As far as the encoding itself, I'm blank...
2. Menu entries displayed.
I believe that identifying buttons and actions by atoms is the correct choice (faster and clearer). But I fully agree with Christian Jacobi as for decoupling action names (atoms) from action texts (displayed ropes). The major reason is that action names have a very restricted syntax and that their names may turn out to be fairly complex to avoid damaging overloading (for example, hitting CTL-Left on Def in a Tioga viewer gives $FindNextDefCtl: that doesn't tell me anything about what it does - in fact, it does nothing... I suspect a bug in TiogaDWIM...). So I agree with choices being (Atom, Rope) pairs. Having a simplified version for casual clients might be OK. Being able to display a micro-viewer (graphics in general) instead of a rope might be interesting (especially for illiterate users...) if not excessively costly. It raises a few problems such as what does display style for choices means then?
3. Limit cases & documentation
Limit cases (1/0 choices) are defined by the guy (systems programmer) who wrote the buttons application program. Let him roast in Hell forever...
Jean-Marc
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
19 Aug 86 To: Frailong Re: Overloading Buttons, again (finally?)
Date: Tue, 19 Aug 86 14:29:20 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Tue, 19 Aug 86 14:20:11 PDT"
To: Frailong
Cc: Spreitzer, Windex^.pa, Jacobi.pa, Nickell.pasa
Reply-to: Spreitzer.pa
About point 2, you said:
``It [arbitrary images in the menu entries] raises a few problems such as what does display style for choices means then?''
It's an open question whether the style attributes of the button (font, colors, whatever else I've forgotten) should also apply to the menu. If you wanted them to, it would mean the arbitrary images in the menu entries couldn't be completely arbitrary --- they could only use two colors (foreground and background). Either that, or you'd have to have a more complicated concept of display style.
About point 3, I'm not sure what you mean. Are you saying the client of PopUpButtons gets to decide how they behave in degenerate cases? I think not; the implementor of PopUpButtons is the one who decides (although he may decide to provide a certain fixed set of options to the client). I think it's reasonable to have a button that's not overloaded!
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
19 Aug 86 Frailong.pa Re: Overloading Buttons, again (finally?)
Date: Tue, 19 Aug 86 14:49:37 PDT
From: Frailong.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Tue, 19 Aug 86 14:29:20 PDT"
To: Spreitzer
Cc: Frailong, Windex^.pa, Jacobi.pa, Nickell.pasa
Reply-to: Frailong.pa
What I mean in point 3 is that 1-entry pop-up menus don't really make sense (0-entry is even worse...) and so the user of PopUpButtons should get burned. Do you know any case where one might need 0/1 choices? (Notice that I suggested earlier that temporarily unavailable choices should still be visible in the pop-up menu, albeit in a distinguished style marking them as unusable).
Jean-Marc
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
19 Aug 86 To: Frailong Re: Overloading Buttons, again (finally?)
Date: Tue, 19 Aug 86 14:59:37 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Tue, 19 Aug 86 14:49:37 PDT"
To: Frailong
Cc: Spreitzer, Windex^.pa, Jacobi.pa, Nickell.pasa
Reply-to: Windex^.pa, Jacobi.pa, Nickell.pasa, Frailong.pa
I mean PopUpButtons to be a replacement for Buttons, not an alternative. Thus, if you want a button, but don't want to do any decoding of the mouse button or keyboard keys, there should be a way to get that with PopUpButtons. My question about degenerate cases is: what is a reasonable way to indicate this to PopUpButtons, and what is a reasonable way for such a button to behave.
Should, for example, you pass a one-element list as choices, and forbid choices to be an empty list? Or perhaps forbid one-element lists, and use the empty list to mean no decoding? Or perhaps allow them both, with perhaps some difference of interpretation? Should a menu appear for degenerate cases? The issue of documentation may be relevent: if you say degenerate cases never pop up a menu, then there'd better be a way to get to the documentation without going through a menu.
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
20 Aug 86 Jacobi.pa Re: Overloading Buttons, again (finally?)
Date: Wed, 20 Aug 86 19:51:02 PDT
From: Jacobi.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "Your message of Tue, 19 Aug 86 14:20:11 PDT"
To: Spreitzer.pa
Cc: Windex^.pa, Jacobi.pa, Nickell.pasa, Frailong.pa
Reply-to: Jacobi.pa
Help ropes, but no fancy nothing
See PopUpMenuDoc.tioga
...
4. Experimental Help Feature
This feature should not yet be used in important applications; I might consider an interface change to make this feature nicely available; If this change will happen, you would have to change all calls of RequestSelection which already use the help feature.
This feature also might disappear again.
parameter of RequestSelection may get a LIST OF Rope.ROPE. In that case the first rope is general documentation for this pop up menu; all other entries in the list are documentation for the corresponding choice.
To interactively invoke the help feature: Move the mouse slightly on top of the menu.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
22 Aug 86 Jacobi.pa Re: PopUpButtons for CedarChest 6.1
Date: Fri, 22 Aug 86 11:54:55 PDT
From: Jacobi.pa
Subject: Re: PopUpButtons for CedarChest 6.1
In-reply-to: "Your message of Thu, 21 Aug 86 19:00:23 PDT"
To: Spreitzer
Cc: Jacobi
I like the classes and instances.
I tried to lift CDMenus out of ChipNDale and clean it up; would you like
a module
PopUpMenus.mesa
Copyright © 1986 by Xerox Corporation. All rights reserved.
Created by: Christian Jacobi, August 22, 1986 11:00:59 am PDT
Last Edited by: Christian Jacobi, August 22, 1986 11:52:57 am PDT
DIRECTORY
Rope USING [ROPE];
PopUpMenus: CEDAR DEFINITIONS =
BEGIN
ROPE: TYPE = Rope.ROPE;
Menu: TYPE = REF MenuRep;
MenuRep:
TYPE =
PRIVATE
RECORD [
header, doc: ROPE,
entries, docs: LIST OF ROPE,
time: INT, timePair: Pair,
pairs: LIST OF Pair,
clientData: REF
];
Pair: TYPE = RECORD [proc: EntryProc, entryData: REF];
EntryProc:
TYPE =
PROC [menu: Menu, entryData:
REF, callData:
REF]
RETURNS [
REF←
NIL];
Type of procedure called on menu selection
menu: menu used
entryData: as defined for the menu entry
callData: as given by call
returned value is passed to caller of menu
Create:
PROC [header:
ROPE←
NIL, doc:
ROPE←
NIL, clientData:
REF←NIL]
RETURNS [Menu];
Creates a new menu (class)
header: header line of menu
doc: documentation for header line and outside
clientData: stored for the client
Entry:
PROC [menu: Menu, entry:
ROPE←
NIL, proc: EntryProc←
NIL, entryData:
REF←
NIL, doc:
ROPE←
NIL]
RETURNS [sameMenu: Menu];
Makes an entry line for a menu
Replaces existing line if entry rope is already used
entry: text for menu line
proc: will be called on selection
entryData: passed to proc on call
a NIL proc and a entryData of type Menu: call menu on selection
a NIL proc and a NIL entryData: remove entry from menu
a NIL proc: on call returns entryData
doc: documentation for this line
sameMenu: for conveniance returns menu again
Timeout:
PROC [menu: Menu, time:
INT𡤀, proc: EntryProc←
NIL, entryData:
REF←
NIL]
RETURNS [sameMenu: Menu];
Defines behavior of menu on timeout
time: in seconds; 0 for no timeout
proc: will be called on timeout when menu is called
entryData: passed to proc on timeout call
a NIL proc and a NIL entryData: no-op on time out
a NIL proc: on timeout returns entryData
sameMenu: for conveniance returns menu again
Call:
PROC [menu: Menu, callData:
REF←
NIL, position:
REF←
NIL, default:
REF←
NIL]
RETURNS [
REF];
Calls a menu (draws it, waits for interactive action and calls EntryProc)
returns data returned from called EntryProc
or entryData if EntryProc was NIL
menu: to be called
callData: passed to the EntryProc
position: (see documentation) defaults to current mouse position
default: hint what entry line to select at the beginning (see documentation)
defaults to: no line should be selected
ClientData:
PROC [menu: Menu]
RETURNS [
REF] =
INLINE {
returns clientData as given on Create
RETURN [menu.clientData]
};
END.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
22 Aug 86 To: Windex^.... Re: Overloading Buttons, again (finally?)
Date: Fri, 22 Aug 86 14:07:02 PDT
From: Spreitzer.pa
Subject: Re: Overloading Buttons, again (finally?)
In-reply-to: "My message of Tue, 19 Aug 86 12:21:14 PDT"
To: Windex^.pa, Jacobi.pa, Nickell.pasa, Frailong.pa
Cc: Spreitzer
In many applications, the operations of a button are organized into a 2 or 3 dimensional space. For example, Tioga's Find, Word, and Def menu entries provide 6 operations, organized into a 2-dimensional space: {case sensitive, case insensitive} * {search forward, search backward, search forward then backward}. Decoding these two parameters from one ATOM is awkward. On the other hand, if the ButtonProc got a general REF, which in this case happens to be a 2-long LIST OF REF ANY, decoding the parameters would go more smoothly. This is thus an additional reason for taking the general approach to the relation between the text displayed and the data passed to the ButtonProc: "the client specifies a list of pairs of <text displayed, REF given to ButtonProc>".
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
22 Aug 86 To: Willie-... Including a design discussion in a pack . . .
Date: Fri, 22 Aug 86 14:17:48 PDT
From: Spreitzer.pa
Subject: Including a design discussion in a package's document
To: Willie-Sue.pa, Donahue.pa, Beach.pa
Cc: Spreitzer
We're having this interesting design discussion about PopUpButtons, mostly on Windex^.pa. It would be nice if all these messages could be part of the document for PopUpButtons. What's a good way to do that?
I asked Willie-Sue this, and I think I got the following answer. As either myself or an invented-specially-for-this-purpose Grapevine R-Name, have a Walnut database dedicated to this discussion. Include in PopUpButtonDoc.Tioga the name of the root of that Walnut database. Let the database be publicly readable.
Is this good? Any better ideas?
Thanks,
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
22 Aug 86 donahue.pa Re: Including a design discussion in a pac . . .
Date: Fri, 22 Aug 86 14:22:14 PDT
From: donahue.pa
Subject: Re: Including a design discussion in a package's document
In-reply-to: "Spreitzer's message of Fri, 22 Aug 86 14:17:48 PDT"
To: Spreitzer
Cc: Willie-Sue, Donahue, Beach
That's the best way to do this that I know of.
Jim
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
10 Sep 86 Nickell.pasa Re: Buttons discussions
Date: Wed, 10 Sep 86 10:44:36 PDT
From: Nickell.pasa
Subject: Re: Buttons discussions
In-reply-to: "Swinehart.pa's message of Fri, 15 Aug 86 17:15:44 PDT"
To: Swinehart.pa
Cc: Spreitzer.pa, Nickell
I've been swamped enough to not answer this (therefore the small audience), but after seeing the effects of the initial implementation, I still say that the model I put forth is superior,
particularly for novice or casual users. In case you've already deleted the message referenced, here is some context:
``I'm obviously interested in all this, but haven't the time for careful perusal, since vacation looms large. Most of the discussion so far seems constructive. My personal prejudice is for not hairing up this implementation too much. After all, the whole idea is to put an ultimately simple model underneath what is now a hodge-podge of mysterious buttons. Some of the Nickell ideas seem to imply that the order of items in a menu wouldn't necessarily correspond to a learned standard ordering of accelerators (left, middle, right, left-SHIFT, ...., and so on.) Maybe I'm misinterpreting? It seems to document things better for the programmer, but not for the user. I'd buy it if the client specifications were used to sort the entries into the menu. Otherwise, it seems to add user level complexity, just when we were getting rid of some. I guess it might make sense to implement it that way, then to make it easy to produce menus in some "standard" configuration, in the interests of standard Cedar flexibility.''
My feeling is that it is documented better for BOTH the programmer and the user, if the package itself adds some icon to show how to obtain the quick-click, whenever it displays the pop-up menu.
Actual in-the-field experience: We have casual Cedar users who are confused by the ERROR option in a pop-up button menu found in one of our applications based on ViewRec. It is there, because ViewRec doesn't use SHIFT-middle.
Also: Applications which ignore the shift key, and applications which ignore the control key currently present identical user-interfaces.
Thus, I still feel (even after experience with the current scheme) that iconic indication of the shortcuts is far superior than positional indication of the shortcuts, and that iconic indication of the shortcuts obviates the need for positional indication of the shortcuts, and that positional indication of the shortcuts has some inherent drawbacks (i.e. the need to fill in holes with dummy buttons).
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
10 Sep 86 swinehart.pa Re: Buttons discussions
Date: Wed, 10 Sep 86 11:14:30 PDT
From: swinehart.pa
Subject: Re: Buttons discussions
In-reply-to: "Nickell.pasa's message of Wed, 10 Sep 86 10:44:36 PDT"
To: Nickell.pasa
Cc: Swinehart, Spreitzer
My prediction, based on experience and on work by Stu Card on learning, is that positional stability is important. It does not obviate the need for the iconic indication, which is quite a good idea. I agree that any of your designs document the interface better for the user than a pure positional one without other indications. The question is whether the result for experienced users is as good.
My positions are more like predictions than convictions; they need to be tested, and could easily be wrong. We will learn some things from just choosing one and trying it. Or even choosing both and trying them. I wish we were in a better position to do some controlled testing of these hypotheses, so that we'd have something other than experiential evidence that we're heading in the right or wrong or some other direction. Failing that, we're really just expressing expert personal opinion.
The easiest way to try both options would be to implement yours and then enforce ours, when desired, by convention and/or some sort of programmed constraints.
Dan
P.S. I'd have left the unused position blank, and made its actions a no-op (or the message window indication "not used". No point turning non-errors into errors.
Mike, perhaps this exchange could be forwarded to Windex^, possibly after we have finished having our says (I've had mine.)
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
10 Sep 86 Nickell.pasa Re: Buttons discussions
Date: Wed, 10 Sep 86 15:56:42 PDT
From: Nickell.pasa
Subject: Re: Buttons discussions
In-reply-to: "swinehart.pa's message of Wed, 10 Sep 86 11:14:30 PDT"
To: swinehart.pa
Cc: Nickell, Spreitzer.pa
My hunch is that positional stability (between different menus, and different types of menus, mind you) might help if presented properly. I'm not convinced that 12 unadorned names enable you to easily spot the position well enough.
The positional help might be significantly enhanced in the following ways:
1. Present the menu as a rectangular array, say, of mouse buttons by control/shift options. This, I think would allow someone to quickly decompose the position of a button into the proper hand motions to execute it.
2. Change the current ``decodeMouseButton, decodeShift, decodeControl: BOOL ← TRUE'' in the ClassSpec to ``decodeMouseButton: BOOL ← TRUE, decodeShiftControl: {neither, shift, shiftAndControl} ← shiftAndControl''. The implication here is that a pop-up menu with 6 entries must mean that mouse and shift buttons are being decoded, rather than mouse and control.
I guess I can agree that leaving the ordering of the menu items completely at the discretion of the package implementor could cause some confusion if he chooses to violate convention. I like Dan's idea of requiring the package interface to specify things in a non-positional manner (as providing more readable implementation documentation), but have the package sort and present the menu items in a standard order.
Eric
(I've had my say, too.)
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
11 Sep 86 To: Swinehar... Re: Buttons discussions
Date: Thu, 11 Sep 86 14:27:20 PDT
From: Spreitzer.pa
Subject: Re: Buttons discussions
In-reply-to: "A bunch of messages I've been too busy with other things to get to until now"
To: Swinehart.pa, Nickell.pasa
Cc: Spreitzer
I'm not sure what all is being talked about here, and if we're all properly understanding what the other is trying to say.
There is this proposal on the table, but not in the implementation, of using a two dimensional array with row and column labels to indicate the coding to the user. There would be three columns and four rows. Over each of the three columns would be an icon indicating a mouse button. Beside each row would be an icon indicating a control/shift key combination. In the elements of the array would be the texts or pictures for the operations. Dan seems to like transposing the array, but I like it this way because text is almost always longer than it is high, often by a lot. If some control/shift keys or mouse buttons are not decoded, a smaller array, with only the appropriate icon labelling would be used.
Another option might be to always have a one-dimensional array, as we have now, and beside each element put an iconic indication of the corresponding mouse button&control&shift combination(s).
Yet another option would be to use the existing one-dimensional text array, and add some text to each element indicating the corresponding mouse button&control&shift combination(s).
Still yet another option is to leave things as they are.
I favor the first of these four. I think Dan does too. What does Eric think?
There is another issue on the table: how the programmer calling PopUpButtons indicates the coding. I think this is completely independent of how the user gets clued in, and verse vica. Right?
I agree the explicit specification of the decoding in the call to PopUpButtons (as opposed to the implicit, positional, specification currently employed) makes it better documented for the programmer. But I don't think it makes the call a lot more readable. It's not that hard to count. And it's so much verbiage just to avoid a little counting. I now have some experience writing and reading these calls, and the counting is not a real bother. I'm inclined to claim that the cost of the excess verbiage outweighs the benefit in explicitness.
Then there's this issue of a button with a hole in its quick-click space (e.g., a ViewRec Name-Value button). If we use a two-dimensional array for presentation to the user, we can't avoid presenting this hole to the user. If we use a one-dimensional array, we can simply not mention it. But a two-dimensional array sets up this row-and-column structure that necessarily allocates some screen real estate to the hole. We could either not address it in PopUpButtons, which leaves each client to implement its own this-is-not-a-command commands, or deal with it in PopUpButtons. Anybody want to offer any convincing arguments about what is the universally right thing for PopUpButtons to do? Barring that, I'm inclined to leave it up to the clients, and let them experiment (which means I also don't have to address how the programming client indicates the hole).
You may have had your say, but that doesn't mean I've understood it. Want to try again?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
11 Sep 86 Nickell.pasa Re: Buttons discussions
Date: Thu, 11 Sep 86 15:07:45 PDT
From: Nickell.pasa
Subject: Re: Buttons discussions
In-reply-to: "Spreitzer.pa's message of Thu, 11 Sep 86 14:27:20 PDT"
To: Spreitzer.pa
Cc: Swinehart.pa, Nickell
I favor the first option of the four. (Dan: Why do you prefer the transposition? I like, for example, the way the Gargoyle help is layed out.)
As to the specification in the calling client, here's a new suggestion. Change the definition of Choice so that it has a default value, a la
Choice:
TYPE =
RECORD [
key:
REF
ANY,
This is what's passed to the PopUpButtonProc to identify the choice taken.
doc:
ROPE,
This describes this choice for the user. This doc should be short enough to fit in the message window. This doc may be NIL, but you don't want to shaft your users, do you?
image: Image ←
NIL
This specifies what's displayed in the pop-up menu. If NIL, it is taken from the key, which must then be reasonably straightforward to convert to a ROPE.
] ← [NIL, NIL, NIL];
Now, a quick change in the definition of a ClassSpec, and some implementation details, and we can allow the programmer to conveniently specify his options without counting, or in order if he prefers.
Click: TYPE ~ {l, m, r, sl, sm, sr, cl, cm, cr, csl, csm, csr};
ClassSpec:
TYPE =
RECORD [
classData: REF ANY ← NIL,
proc: PopUpButtonProc,
choices: ARRAY Click OF Choice,
image: Image ← NIL,
doc: ROPE ← NIL
];
The implementation could determine the equivalent of decodeShift and decodeControl by seeing if any of the appropriate values are not defaulted. (Does decodeMouseButton~FALSE make sense anywhere? If so, then Click should include the items n — for `no click' — and sn and cn and csn.) This should provide for a terse but mnemonically useful specification.
Re: Holes. I'd have the implementation just leave some blank real estate and ignore key clicks on it.
Eric
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
11 Sep 86 To: Nickell.pasa Re: Buttons discussions
Date: Thu, 11 Sep 86 15:14:38 PDT
From: Spreitzer.pa
Subject: Re: Buttons discussions
In-reply-to: "Nickell.pasa's message of Thu, 11 Sep 86 15:07:45 PDT"
To: Nickell.pasa
Cc: Spreitzer, Swinehart
We want to be able to have more than 12 choices --- some will just be available only through the menu.
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
11 Sep 86 Nickell.pasa Re: Buttons discussions
Date: Thu, 11 Sep 86 15:18:18 PDT
From: Nickell.pasa
Subject: Re: Buttons discussions
In-reply-to: "Spreitzer.pa's message of Thu, 11 Sep 86 15:14:38 PDT"
To: Spreitzer.pa
Cc: Nickell, Swinehart.pa
True. This is certainly a disadvantage of the array presentation... where does one put those which aren't attach to a menu?
Eric
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
11 Sep 86 To: Nickell.pasa Re: Buttons discussions
Date: Thu, 11 Sep 86 15:38:12 PDT
From: Spreitzer.pa
Subject: Re: Buttons discussions
In-reply-to: "Nickell.pasa's message of Thu, 11 Sep 86 15:18:18 PDT"
To: Nickell.pasa
Cc: Spreitzer, Swinehart
Um, "those which aren't attach to a menu"? Perhaps you meant "those that aren't attached to a quick-click"? If there are more than 12 choices, the two-dimensional array could have more than 4 rows. Perhaps with a heavy line seperating the first 4 rows from the rest. And of course no icon indicating a control/shift key combination; perhaps someone can think of an icon indicating impossibility of quick-click-invocation?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
11 Sep 86 Nickell.pasa Re: Buttons discussions
Date: Thu, 11 Sep 86 17:52:27 PDT
From: Nickell.pasa
Subject: Re: Buttons discussions
In-reply-to: "Spreitzer.pa's message of Thu, 11 Sep 86 15:38:12 PDT"
To: Spreitzer.pa
Cc: Nickell, Swinehart.pa
Then it would be possible to add to the ClassSpec record an item for popUpOnlyChoices: LIST OF Choice ← NIL.
Eric
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
12 Sep 86 To: Windex^.p... PopUpButtons, coding
Date: Fri, 12 Sep 86 11:35:40 PDT
From: Spreitzer.pa
Subject: PopUpButtons, coding
To: Windex^.pa, Nickell.pasa, Jacobi.pa, Frailong.pa
Cc: Spreitzer.pa
Eric and Dan and I have been having this discussion, and we thought we'd let the rest of the world in on it.
--------------------------------------
Date: Wed, 10 Sep 86 10:44:36 PDT
From: Nickell.pasa
Subject: Re: Buttons discussions
In-reply-to: "Swinehart.pa's message of Fri, 15 Aug 86 17:15:44 PDT"
To: Swinehart.pa
Cc: Spreitzer.pa, Nickell
I've been swamped enough to not answer this (therefore the small audience), but after seeing the effects of the initial implementation, I still say that the model I put forth is superior,
particularly for novice or casual users. In case you've already deleted the message referenced, here is some context:
``I'm obviously interested in all this, but haven't the time for careful perusal, since vacation looms large. Most of the discussion so far seems constructive. My personal prejudice is for not hairing up this implementation too much. After all, the whole idea is to put an ultimately simple model underneath what is now a hodge-podge of mysterious buttons. Some of the Nickell ideas seem to imply that the order of items in a menu wouldn't necessarily correspond to a learned standard ordering of accelerators (left, middle, right, left-SHIFT, ...., and so on.) Maybe I'm misinterpreting? It seems to document things better for the programmer, but not for the user. I'd buy it if the client specifications were used to sort the entries into the menu. Otherwise, it seems to add user level complexity, just when we were getting rid of some. I guess it might make sense to implement it that way, then to make it easy to produce menus in some "standard" configuration, in the interests of standard Cedar flexibility.''
My feeling is that it is documented better for BOTH the programmer and the user, if the package itself adds some icon to show how to obtain the quick-click, whenever it displays the pop-up menu.
Actual in-the-field experience: We have casual Cedar users who are confused by the ERROR option in a pop-up button menu found in one of our applications based on ViewRec. It is there, because ViewRec doesn't use SHIFT-middle.
Also: Applications which ignore the shift key, and applications which ignore the control key currently present identical user-interfaces.
Thus, I still feel (even after experience with the current scheme) that iconic indication of the shortcuts is far superior than positional indication of the shortcuts, and that iconic indication of the shortcuts obviates the need for positional indication of the shortcuts, and that positional indication of the shortcuts has some inherent drawbacks (i.e. the need to fill in holes with dummy buttons).
--------------------------------------
Date: Wed, 10 Sep 86 11:14:30 PDT
From: swinehart.pa
Subject: Re: Buttons discussions
In-reply-to: "Nickell.pasa's message of Wed, 10 Sep 86 10:44:36 PDT"
To: Nickell.pasa
Cc: Swinehart, Spreitzer
My prediction, based on experience and on work by Stu Card on learning, is that positional stability is important. It does not obviate the need for the iconic indication, which is quite a good idea. I agree that any of your designs document the interface better for the user than a pure positional one without other indications. The question is whether the result for experienced users is as good.
My positions are more like predictions than convictions; they need to be tested, and could easily be wrong. We will learn some things from just choosing one and trying it. Or even choosing both and trying them. I wish we were in a better position to do some controlled testing of these hypotheses, so that we'd have something other than experiential evidence that we're heading in the right or wrong or some other direction. Failing that, we're really just expressing expert personal opinion.
The easiest way to try both options would be to implement yours and then enforce ours, when desired, by convention and/or some sort of programmed constraints.
Dan
P.S. I'd have left the unused position blank, and made its actions a no-op (or the message window indication "not used". No point turning non-errors into errors.
Mike, perhaps this exchange could be forwarded to Windex^, possibly after we have finished having our says (I've had mine.)
--------------------------------------
Date: Wed, 10 Sep 86 15:56:42 PDT
From: Nickell.pasa
Subject: Re: Buttons discussions
In-reply-to: "swinehart.pa's message of Wed, 10 Sep 86 11:14:30 PDT"
To: swinehart.pa
Cc: Nickell, Spreitzer.pa
My hunch is that positional stability (between different menus, and different types of menus, mind you) might help if presented properly. I'm not convinced that 12 unadorned names enable you to easily spot the position well enough.
The positional help might be significantly enhanced in the following ways:
1. Present the menu as a rectangular array, say, of mouse buttons by control/shift options. This, I think would allow someone to quickly decompose the position of a button into the proper hand motions to execute it.
2. Change the current ``decodeMouseButton, decodeShift, decodeControl: BOOL ← TRUE'' in the ClassSpec to ``decodeMouseButton: BOOL ← TRUE, decodeShiftControl: {neither, shift, shiftAndControl} ← shiftAndControl''. The implication here is that a pop-up menu with 6 entries must mean that mouse and shift buttons are being decoded, rather than mouse and control.
I guess I can agree that leaving the ordering of the menu items completely at the discretion of the package implementor could cause some confusion if he chooses to violate convention. I like Dan's idea of requiring the package interface to specify things in a non-positional manner (as providing more readable implementation documentation), but have the package sort and present the menu items in a standard order.
Eric
(I've had my say, too.)
--------------------------------------
Date: Thu, 11 Sep 86 14:27:20 PDT
From: Spreitzer.pa
Subject: Re: Buttons discussions
In-reply-to: "A bunch of messages I've been too busy with other things to get to until now"
To: Swinehart.pa, Nickell.pasa
Cc: Spreitzer
I'm not sure what all is being talked about here, and if we're all properly understanding what the other is trying to say.
There is this proposal on the table, but not in the implementation, of using a two dimensional array with row and column labels to indicate the coding to the user. There would be three columns and four rows. Over each of the three columns would be an icon indicating a mouse button. Beside each row would be an icon indicating a control/shift key combination. In the elements of the array would be the texts or pictures for the operations. Dan seems to like transposing the array, but I like it this way because text is almost always longer than it is high, often by a lot. If some control/shift keys or mouse buttons are not decoded, a smaller array, with only the appropriate icon labelling would be used.
Another option might be to always have a one-dimensional array, as we have now, and beside each element put an iconic indication of the corresponding mouse button&control&shift combination(s).
Yet another option would be to use the existing one-dimensional text array, and add some text to each element indicating the corresponding mouse button&control&shift combination(s).
Still yet another option is to leave things as they are.
I favor the first of these four. I think Dan does too. What does Eric think?
There is another issue on the table: how the programmer calling PopUpButtons indicates the coding. I think this is completely independent of how the user gets clued in, and verse vica. Right?
I agree the explicit specification of the decoding in the call to PopUpButtons (as opposed to the implicit, positional, specification currently employed) makes it better documented for the programmer. But I don't think it makes the call a lot more readable. It's not that hard to count. And it's so much verbiage just to avoid a little counting. I now have some experience writing and reading these calls, and the counting is not a real bother. I'm inclined to claim that the cost of the excess verbiage outweighs the benefit in explicitness.
Then there's this issue of a button with a hole in its quick-click space (e.g., a ViewRec Name-Value button). If we use a two-dimensional array for presentation to the user, we can't avoid presenting this hole to the user. If we use a one-dimensional array, we can simply not mention it. But a two-dimensional array sets up this row-and-column structure that necessarily allocates some screen real estate to the hole. We could either not address it in PopUpButtons, which leaves each client to implement its own this-is-not-a-command commands, or deal with it in PopUpButtons. Anybody want to offer any convincing arguments about what is the universally right thing for PopUpButtons to do? Barring that, I'm inclined to leave it up to the clients, and let them experiment (which means I also don't have to address how the programming client indicates the hole).
You may have had your say, but that doesn't mean I've understood it. Want to try again?
Mike
--------------------------------------
Date: Thu, 11 Sep 86 15:07:45 PDT
From: Nickell.pasa
Subject: Re: Buttons discussions
In-reply-to: "Spreitzer.pa's message of Thu, 11 Sep 86 14:27:20 PDT"
To: Spreitzer.pa
Cc: Swinehart.pa, Nickell
I favor the first option of the four. (Dan: Why do you prefer the transposition? I like, for example, the way the Gargoyle help is layed out.)
As to the specification in the calling client, here's a new suggestion. Change the definition of Choice so that it has a default value, a la
Choice:
TYPE =
RECORD [
key:
REF
ANY,
This is what's passed to the PopUpButtonProc to identify the choice taken.
doc:
ROPE,
This describes this choice for the user. This doc should be short enough to fit in the message window. This doc may be NIL, but you don't want to shaft your users, do you?
image: Image ←
NIL
This specifies what's displayed in the pop-up menu. If NIL, it is taken from the key, which must then be reasonably straightforward to convert to a ROPE.
] ← [NIL, NIL, NIL];
Now, a quick change in the definition of a ClassSpec, and some implementation details, and we can allow the programmer to conveniently specify his options without counting, or in order if he prefers.
Click: TYPE ~ {l, m, r, sl, sm, sr, cl, cm, cr, csl, csm, csr};
ClassSpec:
TYPE =
RECORD [
classData: REF ANY ← NIL,
proc: PopUpButtonProc,
choices: ARRAY Click OF Choice,
image: Image ← NIL,
doc: ROPE ← NIL
];
The implementation could determine the equivalent of decodeShift and decodeControl by seeing if any of the appropriate values are not defaulted. (Does decodeMouseButton~FALSE make sense anywhere? If so, then Click should include the items n — for `no click' — and sn and cn and csn.) This should provide for a terse but mnemonically useful specification.
Re: Holes. I'd have the implementation just leave some blank real estate and ignore key clicks on it.
Eric
--------------------------------------
Date: Thu, 11 Sep 86 15:14:38 PDT
From: Spreitzer.pa
Subject: Re: Buttons discussions
In-reply-to: "Nickell.pasa's message of Thu, 11 Sep 86 15:07:45 PDT"
To: Nickell.pasa
Cc: Spreitzer, Swinehart
We want to be able to have more than 12 choices --- some will just be available only through the menu.
Mike
--------------------------------------
Date: Thu, 11 Sep 86 15:18:18 PDT
From: Nickell.pasa
Subject: Re: Buttons discussions
In-reply-to: "Spreitzer.pa's message of Thu, 11 Sep 86 15:14:38 PDT"
To: Spreitzer.pa
Cc: Nickell, Swinehart.pa
True. This is certainly a disadvantage of the array presentation... where does one put those which aren't attach to a menu?
Eric
--------------------------------------
Date: Thu, 11 Sep 86 15:38:12 PDT
From: Spreitzer.pa
Subject: Re: Buttons discussions
In-reply-to: "Nickell.pasa's message of Thu, 11 Sep 86 15:18:18 PDT"
To: Nickell.pasa
Cc: Spreitzer, Swinehart
Um, "those which aren't attach to a menu"? Perhaps you meant "those that aren't attached to a quick-click"? If there are more than 12 choices, the two-dimensional array could have more than 4 rows. Perhaps with a heavy line seperating the first 4 rows from the rest. And of course no icon indicating a control/shift key combination; perhaps someone can think of an icon indicating impossibility of quick-click-invocation?
Mike
--------------------------------------
What do y'all think?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15 Sep 86 To: Windex^,... Re: PopUpButtons, coding
Date: Mon, 15 Sep 86 12:55:57 PDT
From: Spreitzer.pa
Subject: Re: PopUpButtons, coding
In-reply-to: "Spreitzer's message of Fri, 12 Sep 86 11:35:40 PDT"
To: Windex^, Nickell.pasa, Jacobi, Frailong
I think I like the idea of dealing, in the pop-up menu, with holes in the mouse*keyboard space by having white space that simply does nothing (not even highlighting (i.e. inverting) itself when the mouse is in it). It has a nice feel --- absence of lexical feedback indicating absence of semantics (or, more correctly, very boring lexical feedback indicating very boring semantics). But this principle should be applied to the button itself, too. Otherwise, the user who quick-clicks an unassigned way is left wondering "what did it do?". Perhaps we could make the button not highlight itself while the user has an unassigned mouse button/control/shift combination depressed.
There are some questions in my mind about when to decode the mouse button & control & shift key. The old Buttons package does it when the mouse button is let up. Currently PopUpButtons does it both when the mouse button is depressed and when it is let up. Remember that the cursor is positioned over the "appropriate" menu entry when, if ever, the menu is first popped up. I choose to make "appropriate" mean "the one indicated by the mouse/keyboard combination used when the mouse button went down". The other candidate would be "the one indicated by the mouse/keyboard combination present when the menu pops up". Currently the TIP table does not decode the mouse button & control/shift key combination for mouse movements --- only on mouse button transitions. Does anybody know how much more expensive it would be to decode during mouse movement? Should we care? Perhaps the right approach is to decode once when the mouse button goes down, and that's all she wrote (unless the menu pops up, of course). Any thoughts?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
15 Sep 86 Jacobi.pa Re: PopUpButtons, coding
Date: Mon, 15 Sep 86 13:02:17 PDT
From: Jacobi.pa
Subject: Re: PopUpButtons, coding
In-reply-to: "Spreitzer's message of Mon, 15 Sep 86 12:55:57 PDT"
To: Spreitzer
Cc: Windex^, Nickell.pasa, Jacobi, Frailong
Reply-to: Jacobi.pa
decode control/shift key during mouse movement: Must be very fast; doing any actions on mouse movements is already now nearly to slow for dandylions.
Christian
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
23 Sep 86 To: Windex^.... Buttons & Process Properties
Date: Tue, 23 Sep 86 17:22:05 PDT
From: Spreitzer.pa
Subject: Buttons & Process Properties
To: Windex^.pa, CedarImplementors^.pa, Frailong.pa, Jacobi.pa, Nickell.pasa
Cc: Spreitzer
Why shouldn't a process forked to execute a ButtonProc inherit the process properties of the process that created the button? Huh? Better than the really boring set of process properties a new process gets, right?
Sounds like a change that should be made to at least PopUpButtons, right?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
24 Sep 86 To: Windex^,... Re: Buttons & Process Properties
Date: Wed, 24 Sep 86 15:10:45 PDT
From: Spreitzer.pa
Subject: Re: Buttons & Process Properties
In-reply-to: "My message of Tue, 23 Sep 86 17:22:05 PDT"
To: Windex^, CedarImplementors^, Frailong, Jacobi, Nickell.pasa
Well, OK, I'll pass on what Russ reminded me of, which is the fact that some properties really should not be inherited. An example is the $CommanderHandle. On the other hand, some properties should be inherited --- an example is the $WorkingDirectory. The problem is that we currently have no scheme for telling which is which (note that this might depend on why you are FORKing; then again, maybe it never will, who knows? We have an even worse version of this problem in the DATools). How about making PopUpButtons, and maybe also Buttons and Menus, simply know a standard list of process properties that should be inherited?
I got to wondering just what that list might be. So did the following experiment:
% ← ProcessProps.Get[]
Error: selection failed
% ← ProcessProps.GetProps[]
Error: selection failed
% ← ProcessProps.GetProcessProps[]
Error: selection failed
% OpenR ProcessProps
Opened: ProcessProps
% ← ProcessProps.GetPropList[]
LIST[^[key: $EvalHead, val: 13457742B^], ^[key: $CommanderHandle, val: 13555042B^], ^[key: $WorkingDirectory, val: "///DAWorld/"]]
% GetProcessProperties
process properties:
LIST[^[key: $CommanderHandle, val: ^[in: 12141720B^, out: 12141706B^, err: 7403136B^, commandLine: "\n", command: "///Commands/GetProcessProperties", propertyList: 7772314B^, procData: 10240532B^]], ^[key: $WorkingDirectory, val: "///DAWorld/"]]
%
So I learned about three process properties, one of which ($WorkingDirectory) should be copied, and the other two of which ($CommanderHandle and $EvalHead) should not. I got to wondering about other properties I'd heard of (i.e., $SearchRules and $WorkingDirectoryStack), and discovered they are command tool properties, not process properties. Is there any process property other than $WorkingDirectory that should be copied? Are there any process properties other than $CommanderHandle and $EvalHead that should not?
Mike
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
26 Sep 86 hagmann.pa Re: Buttons & Process Properties
Date: Fri, 26 Sep 86 08:22:51 PDT
From: hagmann.pa
Subject: Re: Buttons & Process Properties
In-reply-to: "Spreitzer's message of Wed, 24 Sep 86 15:10:45 PDT"
To: Spreitzer
Cc: Windex^, CedarImplementors^, Frailong, Jacobi, Nickell.pasa
Reply-to: hagmann.pa
I am fairly certain that $EvalHead is an InterpreterTool property, not a command tool property. It got stuck on your process when you did the "←". Process propeties examined through the interpreter are not always correct since the interpeter adds its own on top of the existing properites (or something like that).
-- Bob