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

[Chris Angelico]

On Sat, Aug 2, 2014 at 9:33 PM, Gregory Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>> The "easier target for the mouse" argument is valuable ONLY
>> when you use the mouse to access the menu bar. If you use the keyboard
>> (and take advantage of mnemonic letters), it's much more useful to
>> have the menu bar attached to its window.
>
>
> Seems to me that if you use the keyboard for everything,
> it doesn't matter where the menu bar is. Unless you're
> talking about the way you can use the keyboard to make
> menus drop down in Windows... but that's not the way
> Mac menu shortcuts work. The menu doesn't visually drop
> down when you invoke a Mac menu command with the keyboard.

There are two forms of shortcut key. One is a direct-action keystroke
that immediately does the same thing that you can do using the menus
(say, Ctrl-O is the same as File... Open). With those, the menu is
completely unnecessary, except as a list of available keystrokes; it
could just as easily be a help screen that says "Press Ctrl-O to open
a file", so the menu's actual location is quite arbitrary. Downside:
There's only so many keystrokes available, and not all of them have
memorable meanings. It's usually best to keep this to the few most
common functions (opening a file, yes, but not "reinterpret this file
as ISO-8859-3", unless you make that configurable per user).

But the other form, usually described as menu mnemonics, is where you
press Alt-F to bring up the _File menu, and then O to activate _Open.
(In OS/2, those would be ~File and ~Open; in GTK, the mnemonic is
preceded by an underscore. Windows 3.1 used an ampersand, and I
believe Win32 does the same thing. 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. The
tilde has the advantage that it doesn't often come up accidentally;
the underscore makes sense because the mnemonic is underlined; I have
no idea why an ampersand should be used. But I digress.) When you work
this way, you aren't grabbing the mouse, so the advantage of not
needing to aim so carefully doesn't exist; but if the menu comes up
right near where your eyes are already focused, you need to move
_them_ less distance - and that means you can focus on the menu more
quickly, plus it emphasizes that the visual change (opening the menu)
occurred in your current program, not in something else.

In Xfce, I can press Alt-F1 to open up the main Applications Menu.
That's at the top of the screen (in fact, top left corner), so it gets
the "throw the mouse" benefit; I think I use the mouse with that a lot
more often than I use the mouse with a program's own menu, because
there's more likely to be something unusual in there. If I install a
new piece of software, I have to figure out where it's landed in the
menu; but Gypsum's four menus aren't changing unexpectedly, so I'm
happy using Alt-O, V to open up Advanced Options.

>> In the rare case of an app
>> that runs without any windows, incidentally, how do you tell the
>> system that you want that app's menu bar instead of (say) Finder,
>> which comes up when you click on the desktop?
>
> In classic MacOS, there was a menu of running applications
> in the top right corner. In MacOSX, you click on the app's
> icon in the dock.

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. 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. Oh wait, that
requires people to understand more than a single mouse button, so it's
contrary to Mac philosophy :)

> Also, while completely windowless applications might be
> rare, it's not rare for an app to have some commands that
> pertain to the app itself, and not to any particular
> window, e.g. "New". It's more logical for those to appear
> in a user interface element that's not tied to a window.

Sure, but those elements are usually rare enough that they can be
stuck on the window anyway. Audacity has a "New" that opens up a new
window, and it's slightly surprising the first couple of times, but
after that you get used to it. It's not a big enough issue to warrant
a change of UI. It is an issue, yes, but I wouldn't warp anything
around it any more than I'd warp my UI around the possibility of a
user having no screen or keyboard and is using the mouse blind. Sure
it happens (I've done it, and I know what I could code to make it
easier!), but not often.

ChrisA