Python and IDEs [was Re: Python 3 is killing Python]

[Chris Angelico]

On Sun, Aug 3, 2014 at 10:01 AM, Gregory Ewing
<greg.ewing at 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