[Idle-dev] Other places to discuss IDLE?
Bruce_Sherwood at ncsu.edu
Sun Jan 25 22:52:49 CET 2009
I'll comment that David Scherer, who in 2000 made a major upgrade to
IDLE in connection with his creation of VPython (vpython.org), has
recently done some work off to the side to make needed improvements to
IDLE, and not just bug fixes. I think he got discouraged by there
seeming to be no real path for making changes that would make it into
the regular Python distribution, so he has gone in the direction of
building (again) an alternative version of IDLE that we would package as
"VIDLE" with distribution of VPython. This initiative is however on hold
at the moment because he has personal business to attend to at this
time. I do expect him to get back to this work within a few months.
Here is an informal list of problems (BAS is me, DS is Scherer):
On Mac, BAS notes sluggishness of the scrollbar slider getting behind
the mouse in a serious way, even hanging up.
There's the issue of DS patch to IDLE to make a VPython go away when you
re-run, which DS proposed to the IDLE-dev list with little support;
without this fix it is annoying and intrusive that the following doesn't
work: Run from IDLE. VPython graphics window appears. Make a source edit
and press and run again. The old VPython graphics window should
disappear and the new one start up, but instead you get two graphics
There's the annoying problem that right-click on a .py file on Windows
to edit with IDLE lets you run a VPython program only once; close the
graphics window and IDLE exits.
On the Mac, nonactive windows don't display their selections. This
makes find and replace utterly unusable in IDLE, since the item to be
replaced isn't highlighted!
There is no options/preferences window on the Mac!
The Mac key combinations need work.
On the Mac, mouse control often gets messed up after switching away and
back to IDLE.
On all platforms, the prompt to save before running is unnecessary;
instead unsaved changes should be committed to a temp file but the
unsaved status should not be changed, so the prompt appears on close or
On all platforms, system library tracebacks should be suppressed by default.
The shell window should scroll to hide previous runs when a program is
executed. (The "Restart" line should be just above the top of the window)
The shell window should possibly come forward or otherwise "signal"
itself (the appropriate behavior may vary by platform) the first time
something is printed to stderr. Care needs to be taken to not let this
become annoying. This is a VERY serious problem for students, who see
their program not run but don't know why because the error message is
If we suppress "system" portions of execution errors, maybe there should
be a configuration option to unsuppress them during development.
Mac users expect to be able to scroll on a trackpad by dragging two
fingers; the current Mac IDLE doesn't deal with this.
Scott David Daniels commented on Mac IDLE problem of misplaced editing
To get evidence of this -- start idle from a terminal window
with a "python25 -m idlelib.idle" where python25 is the path to your
python executable. You get output on stderr each time the mouse drops
a line of mouse positioning.
Jim Mueller reports:
2754 6 days ago Mac version of IDLE doesn't scroll as
expected open alextrob
3549 6 days ago Missing IDLE Preferences on Mac pending
After reading the first one, I can verify that I see this effect too.
The second one states that the Options->Configure menu has
become IDLE->Preferences on the mac, but there was a bug in how they
checked the Tk version. So it should bite you if you have a version of
Tk < 8.4.10. It states that this was fixed on Friday and is in the
trunk and backported to the 2.6 and 3.1 versions of Python. (3.1?)
Anyway below is my previous message, which is probably out of date now.
I have tried out idle from both the current Enthought and the one that
comes with MacPython. The only things I see are:
1) If I open a new window, or open a file, occasionally I get an error
RCNE SendEventToEventTarget (suom Moved ) failed, -50
This does not happen every time, and maybe it could happen selecting
other menu items. I haven't tried everything, and it is intermittent
on those where I do see it. I can't give an impression of whether it
occurs more frequently in one distribution than another, because after
playing for 5 minutes on each, I only have a handful of instances
total. Any comparison would no be statistically significant, but it
does not seem to be a large problem. Of course that might just be my
2) If I click in one window and then back in source window, Focus is
changed to the source window but the cursor position is still where it
was when I was last in that window. Once focus has been shifted to
that window, cursor move properly when I click on text. This is a
"feature" that I see all the time on Macs. When I have two browser
windows open I click on a button in one, it has no effect unless that
window already has the focus. This is sometimes annoying for me in
that I don't want to have to click twice to get something to happen.
Other times I am happy that the button I just happen to click on while
trying to bring a window to the front didn't actually register the
3) I haven't been able to get the scrollbar problem to occur, but
again if it is an intermittent problem, perhaps I just haven't tried
4) The reason that the new Enthought distribution has a "Configure
IDLE" menu option is that they threw out the IDLE.app. Instead they
provide a simple shell script, ".command" which then runs "/Library/
Frameworks/Python.framework/Versions/Current/bin/idle" in a console
window. So the configure problem is in IDLE.app, not idle.
Later, more from Jim Mueller:
The patch works.
In macosxSupport.py, if you change the line
if tkversion >= '8.4.14':
if map(int, tkversion.split('.')) >= (8, 4, 14):
then you get an IDLE->Preferences menu, which contains all the
I haven't checked the 2.5.4 version of MacPython, but since this
change only went into the repository on Friday. It might not be in the
> It does seem a bit quiet in here, so I was wondering if there's
> somewhere better to discuss IDLE? Is it quiet because there aren't
> many developers interested in/working on IDLE, or because they're all
> elsewhere? I'm interested in helping out by fixing bugs, but I'm
> worried that my effort will be wasted.
> IDLE-dev mailing list
> IDLE-dev at python.org
More information about the IDLE-dev