On Tue, Sep 19, 2017 at 02:00:41PM -0400 I heard the voice of Steve Litt, and lo! it spake thus: > > Thanks! And thanks for the detailed explanation of both what the > "side effect" is, and the rationale for the way it's coded. I > couldn't exactly understand the side effect when in the workspace > thingy, but I perfectly understood the menu default value feature > and its requirements.
The workspace thing is pretty much the same as default entries, just magic. The TwmWorkspaces menu is a list of workspaces. Each of those entries opens up a sub-menu of the TwmWindows menu for that workspace. And further acts like that sub-menu had a default entry that f.gotoworkspace's that workspace, which the Return/mouse-release on it invokes. So it's just like it were a list of `f.menu "TwmWindowsForThisWorkspace"` entries and each of those menus had a f.gotoworkspace default entry. Except it's actually a magic list of entries that don't have real f.anything actions, and the sub-menus don't have default entries; it's all faked up in magic hardcode. So, unless you're looking too closely at the implementation, you can ignore those details and just treat it like a normal menu/default-entry setup. If you _are_ looking at the implementation... well, you can drink, I guess. A lot. > If somebody pushes rightarrow or Return on a command type > item, run the command. I believe it works this way now. Correct: anything other than a f.menu entry, Right and Return are identical. > If somebody pushes rightarrow on any menu item, show the submenu. It > works this way now. If somebody presses Return on a menu item with a > default, run the default. It works this way now. Correct. > If somebody pushes Return on a menu item with no default, show the > submenu. It does not work this way now. 'k... let's think through the implications. This creates a few new inconsistencies: - The first is that now Return is *not* exactly the same as releasing the mouse button, since it'll sometimes pop out a submenu. I think that's a pretty easy cost to accept. - The second is that now instead of knowing (insofar as anybody "knows" the scantily documented) that it'll always invoke the default entry, it'll now behave different when there is vs. isn't. So if you're existing it to invoke a thing (if one's there), or exit out of menus without invoking a thing (if one's not there), it winds up popping out a submenu instead. That's possibly surprising. OTOH, it's not dangerous (since it doesn't invoke anything), and it's trivial to "recover" from (just back out of the menu). So, I'd say that's an easy cost to accept as well. The flip side, which is slightly tougher, is in getting people used to hitting Return to pop out the submenus, which then suddenly starts invoking a default entry instead when they happen upon a menu that has one. Now, you can argue that a user's menus won't HAVE default entries unless they ADD them, and if they do that they're presumably _intending_ that invocation. That's weakened a little by the existing magic-default stuff on the magic Workspaces menu. Unlike the case above, the surprise _can_ be dangerous since it's invoking something, and is harder to recover from since you ran an unexpected thing and left the menus. I think I'd buy the argument that the convenience is worth the cost in that case too. I'm not sure it's as obviously so as the earlier cases though. Definitely be interested in second thru seventh opinions on that, especially from anybody else doing a lot of keyboarding in menus. -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
