When started from a Cygwin window 
(duane@USD22C821 /cygdrive/d/my_python/Cygwin_test
$ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has 
no menus.

If started as:
duane@USD22C821 /cygdrive/d/my_python/Cygwin_test
$ /usr/lib/python2.3/idlelib/idle.py -n

(no subprocess) the menus are present.

Starting Python:
duane@USD22C821 /cygdrive/d/my_python/Cygwin_test
$ python
Python 2.3 (#1, Aug  1 2003, 15:01:23)
[GCC 3.2 20020927 (prerelease)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>>

Win2k SP2

Duane Kaufman
duane.kaufman@med.ge.com

Logged In: YES 
user_id=33168

Jason, if you can't help can you assign to Kurt (kbk)?  Thanks.

Logged In: YES 
user_id=86216

I would like to assign this (at least temporarily) to Kurt
for the following reasons:

1. I will be off-net for a while
2. I am not very familiar with Tkinter
3. I am not very familiar with IDLE
4. IDLE works fine under Python 2.2.3 with the identical
underlying software (e.g, Cygwin, Tcl/Tk, etc.)

However, IDLE under Python 2.3 could be tickling YA
Cygwin bug...

I will check in when I'm back...

Thanks.

Logged In: YES 
user_id=149084

It appears that IDLE can't start its subprocess.  I have
a patch in process that will give proper error messages
and timeouts under that condition, at least giving the
user a notice about the failure.  

Then there is the question why the subprocess doesn't
start under Cygwin.  There are no error messages in the
shell window?

I'm going to be away for a few days myself.

Logged In: YES 
user_id=86216

kbk> There are no error messages in the
kbk> shell window?

No, the shell window just looks like the following:

Python 2.3 (#1, Aug  5 2003, 09:49:11) 
[GCC 3.2 20020927 (prerelease)] on cygwin
Type "copyright", "credits" or "license()" for more information.

    
**********************************************
******************
    Personal firewall software may warn about the connection 
IDLE
    makes to its subprocess using this computer's internal 
loopback
    interface.  This connection is not visible on any external
    interface and no data is sent to or received from the 
Internet.
    
**********************************************
******************
    
IDLE 1.0      
>>>

And appears to work, until one types "^D", then it hangs.

Logged In: YES 
user_id=149084

Well, that's peculiar.  So the subprocess is starting up
ok but the menus aren't posted.  Now I'm thinking a 
TK problem -- what bug are you thinking of?

Logged In: YES 
user_id=86216

> what bug are you thinking of?

Nothing in particular. However, experience has taught me
to consider Cygwin bugs when porting to Cygwin...

Anyway, I just found a difference between Python 2.2.3
and 2.3 after starting IDLE.

Under 2.2.3:

$ ps | fgrep python
     3308    1400    3308       3092    0 19695 
11:57:56 /home/jt/src/python-2.2.3-2/python

Under 2.3:

$ ps | fgrep python
     2244    1400    2244       2864    0 19695 
12:02:57 /usr/bin/python2.3
      700    2244    2244       3592    0 19695 
12:02:58 /usr/bin/python2.3

Note one python process under 2.2.3 and two under 2.3.
This may explain why IDLE works under 2.2.3 and not.

Were there major IDLE changes between 2.2.3 and 2.3?
If so, what?

Logged In: YES 
user_id=149084

Oh, big differences: Without the -n switch, which makes
IDLE act like the 2.2 version, IDLE starts up an execution
server subprocess which then connects to the user's
GUI.  This subprocess is restarted every time the user
does a Run/F5 or a Shell/Restart Shell.

There are other major differences.  The IDLE in 2.3 is the
version developed on the IDLEfork project at Sourceforge.

It sounds like you are getting farther than Duane Kaufman.
I wonder if he was seeing the initial message in the shell
window like you are.  Do you see the menus?

Well, gotta go  :-)

Logged In: YES 
user_id=86216

> It sounds like you are getting farther than Duane
> Kaufman.

I don't think so. AFAICT, we are observing the same
behavior.

> I wonder if he was seeing the initial message in the
> shell window like you are.

My WAG is yes.

Duane, please confirm.

> Do you see the menus?

No.

Logged In: YES 
user_id=574999

I am seeing the same behavior, and do _not_ see menus 
when started with a sub-process.

Duane

Logged In: YES 
user_id=574999

Hi,

I was wondering if there has been any motion on this item yet?

Thanks,
Duane

Logged In: YES 
user_id=86216

Unfortunately, not. The bug report was created
right before I was going on vacation last summer.
Since I'm still on vacation... :,)

Well...actually the assumed high "head banger"
factor has facilitated my procrastination.
Additionally, since I do not use use IDLE, I'm not
very motivated to build a debuggable Python and
Cygwin and attach to the hung process with gdb and
debug.

FWIW, I haven't forgetton. The bug report
stares me in the face everytime I read my email.
Unfortunately, I haven't taken any action. :,(

Are you a developer type? If so, would you be
willing to try to debug this problem yourself?

Logged In: YES 
user_id=956087

Don't know if this sheds any more light, but on WinXP, Python 
2.3.3: when starting IDLE with a file to edit (e.g. 'idle foo.py') 
the edit window becomes visible first. _And_ it has a visible 
menu bar. But when the shell window becomes visible, it has 
no menu bar, and the menu bar _disappears_ from the edit 
window.

Logged In: YES 
user_id=86216

Sean, thanks for the info.

Kurt, ring any bells?

Logged In: YES 
user_id=1321088

I found the problem!  :D

Around line 394 of PyShell.py roughly, this function:

    def start_subprocess(self):
        # spawning first avoids passing a listening socket
to the subprocess
        self.spawn_subprocess()
        #time.sleep(20) # test to simulate GUI not accepting
connection
        addr = (LOCALHOST, self.port)
        # Idle starts listening for connection on localhost
        for i in range(3):
            time.sleep(i)
            try:
                self.rpcclt = MyRPCClient(addr)
                break
            except socket.error, err:
                pass
        else:
            self.display_port_binding_error()
            return None
        # Accept the connection from the Python execution server
        self.rpcclt.listening_sock.settimeout(10)
        try:
            self.rpcclt.accept()
        except socket.timeout, err:
            self.display_no_subprocess_error()
            return None
        self.rpcclt.register("stdin", self.tkconsole)
        self.rpcclt.register("stdout", self.tkconsole.stdout)
        self.rpcclt.register("stderr", self.tkconsole.stderr)
        self.rpcclt.register("flist", self.tkconsole.flist)
        self.rpcclt.register("linecache", linecache)
        self.rpcclt.register("interp", self)
        self.transfer_path()
        self.poll_subprocess()
        return self.rpcclt

It spawns the subprocess, but never manages to talk to it.
The socket.timeout exception is raised. Communication to the
subprocess fails in here:

            try:
                self.rpcclt = MyRPCClient(addr)
                break
            except socket.error, err:
                pass

Then, it tries to register the functions with tkconsole, and
TkInter seems to die. I haven't dug down into it yet to see
what exactly happens. But, I suspect that rpcclt is null
when self.rpcclt.register() is called.

So, it's not a Tk error. It's an error with trying to
contact the subprocess.

Is the problem described by Daniel, "So, it's not a Tk error. It's an
error with trying to contact the subprocess", still present? 

It's not cleat to me from messages that it'd be restricted to Cygwin, if
confirmed on other build please change title again.

I just tried idle here under cygwin and menus are not shown. This cygwin
includes python 2.5.2, btw.

But I verified what Daniel Joyce said and I see the problem is no longer
there, so it has to be tracked down again.

Is this still an issue with later versions of Python and Cygwin?

ping

AFAICT, this issue is resolved in the latest Cygwin Python package (i.e., 2.6.7-1) that is built against a X11-based Tcl/Tk instead of a Win32 GDI version:

http://cygwin.com/ml/cygwin-announce/2012-02/msg00014.html

I like to close the issue if problem has been solved by cygwin itself.

Please do.

When I tested the Cygwin Python 2.6.7-1 release, IDLE was one of my testcases. In my limited testing (I'm not a regular IDLE user), the menus appeared to function properly.

Closing as the latest cygwin build works fine.