On Sun, Aug 3, 2014 at 10:01 AM, Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote: > Chris Angelico wrote: >> >> It's a little awkward when you have >> an invoicing screen and you put something like "P&O Shipping" as your >> customer name, and suddenly Alt-O takes you someplace different. > > > An app that did that would be seriously broken, wouldn't it? > The & should only be interpreted that way in menu items, etc., > not in user data.
Mnemonics can also be used on text labels, and then they apply to the adjacent field - for instance, you could have "_Name" followed by an entry field for the Name, and hitting Alt-N will take you to that field. The app I'm talking about used a label to show the customer's name, and we had exactly that issue (although more often with couples' names - for instance, if we had an order from John and Mary Smith, but didn't know their full names, we'd identify them as J&M Smith, and voila, Alt-M would take us to... whatever field came after the display of the name (which was the address). To be quite honest, that particular program was a lot more broken than that. But still, it did drive home the value of using ~ instead of & for that job. And of course, _ makes enough sense that we can accept its potential for collisions. (Plus it's usually possible to disable underscore interpretation. Or, more properly, you have to explicitly enable their interpretation; in GTK, I have to call set_use_underline(1) before it'll create a mnemonic.) >> but if the menu comes up >> right near where your eyes are already focused, you need to move >> _them_ less distance > > > But putting the menu bar at the top of the window doesn't > guarantee that it will be near where your eyes are. If > you have a window taking up most of the screen and you're > editing something near the bottom, a menu bar at the top > of the window is nearly as far away as one at the top of > the screen. Putting it at the top of the window cannot possibly make it further away than putting it at the top of the screen. It's potentially going to be a lot closer, but at its worst, it'll be just as bad (modulo the title bar's height). > It would make more sense to pop the menu up near the text > cursor. There's no law that says a menu summoned by > keystroke has to appear in the same place as one summoned > by mouse. Sure. And I know of plenty of applications where that's possible. The standard used to be Shift-F10 to bring up a context menu, identical to right-clicking the mouse except that the menu appears at the object you're working on rather than at the mouse's location. These days, you often get something like that on the Menu key (aka the other Windows key, on some keyboards); same result. But that's a context menu, not the pull-down menu; although it's common to have the same menu items on them. > In any case, when you use a shortcut sequence, do you > really *look* at the menu that comes up, or do you just > memorise the appropriate alt-sequence? If you use it > frequently, I suspect the latter. If you don't use it > very often, having to look away doesn't matter so much. If I'm using "Alt-F, O" as a command keystroke, then sure, it doesn't make any difference where the menu is. But often I'll pull down a menu, then look at it to figure out what I want to hit. Once my eye has found it, I'll press its underlined letter, so I still don't use the mouse; but I do need it to have a mnemonic, and I need the entire menu to be near my eye. >> Okay. So you need to first click on something in the dock - that's the >> thing down the bottom of the screen, right? - and then go all the way >> up to the top of the screen to use its menu bar. > > Because of the "throw the mouse" effect, going *all* the > way to the top takes a tiny fraction of a second and is > almost effortless. Going any lesser distance takes > *much* longer. Right, but it still takes time. Also, if your mouse is set fast enough to go all the way from the bottom to the top of the screen in less than 0.1s, then either your screen is fairly small (may have been true in the past, but is getting pretty rare now), or you seriously penalize any going-less-distance operations. In fact, it becomes self-perpetuating: if you set the mouse fast, it becomes really important to use the edges and avoid the middle, and if applications always use the edges and never the middle, it's really important to set your mouse faster. Conversely, slower mouse settings mean it's easier to be precise with interior movements, while reducing the advantage of the borders. But no matter how fast you set the mouse, it still takes a nonzero time to move it to a specific position. The absolute easiest place to reach is... where you already are. Put the menu there! That's what popup menus are for. >> I think I'd much >> rather have a popup menu - right-click the program's dock icon and get >> the menu right there where the mouse already is. > > Dock icons do have a contextual menu, but it's just a > menu of windows. Fitting all of the app's menus in there > would require hierarchical menus, which are an abomination > you don't want to get me started on. :-) I detest window stacking. Each window stands alone, even if some are from the same application. (Either that, or some of them are to be altogether hidden. But anything that gets shown should be shown at top level.) >> Oh wait, that >> requires people to understand more than a single mouse button, so it's >> contrary to Mac philosophy :) > > > The Mac philosophy on that seems to be widely misunderstood. > Having only one button on my mouse doesn't mean there's > only one thing I can do with it. I can shift-click, option- > click, command-click, and nowadays control-click, plus any > combination of those. That's enough for anyone to keep in > their head, I would have thought. I can do all those, AND I can do those with right-click. And bare right-click has the advantage that it can be done one-handed; that can be quite a difference when you have a son/daughter/brother/sister hanging off your left arm... > There's also one concrete advantage to using modifiers > instead of extra mouse buttons: you can provide feedback > by changing the cursor when a modifier is held down. Sure. But that shouldn't preclude the use of additional mouse buttons too. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
