From taleinat at gmail.com  Sat Sep  1 10:20:45 2007
From: taleinat at gmail.com (Tal Einat)
Date: Sat, 1 Sep 2007 11:20:45 +0300
Subject: [Idle-dev] IDLE getpass?
In-Reply-To: <11379.71.59.123.159.1187324081.squirrel@webmail.brynmawr.edu>
References: <1628.71.59.123.159.1185417021.squirrel@webmail.brynmawr.edu>
	<7afdee2f0707252336m14e27b5ep3bc933802f010cc6@mail.gmail.com>
	<46A8E118.8030101@brynmawr.edu>
	<7afdee2f0707291416u3495ede0v566167e03b11b6b9@mail.gmail.com>
	<46C47656.10003@brynmawr.edu>
	<7afdee2f0708161918o78c05f0fu5272fd896f3dc4b2@mail.gmail.com>
	<11379.71.59.123.159.1187324081.squirrel@webmail.brynmawr.edu>
Message-ID: <7afdee2f0709010120m41c7aad3ifb2c4ba802ab01e1@mail.gmail.com>

I have two ideas, but not the time to try them out:

One is to embed an entry in the text widget - just like the Squeezer
extension embeds a button. I think this would be the cleanest approach.

The other is to try making the getpass window transient to the main window,
and/or to give its entry widget focus before calling deiconify and tkraise.

- Tal

On 8/17/07, Douglas S. Blank <dblank at brynmawr.edu> wrote:
>
> Tal,
>
> Thanks for looking at this and giving feedback.
>
> Unfortunately, this doesn't seem to work for me when running with
> subprocesses.
>
> Maybe it has to have to do with Tkinter running in the background thread,
> and tkraise not knowing about the IDLE window in the other thread (which
> is on top).
>
> If there were a global ontop function, that would do it. I'm starting to
> think that it isn't even possible in WindowsXP with IDLE with processes...
>
> -Doug
>
> On Thu, August 16, 2007 10:18 pm, Tal Einat said:
> > On 8/16/07, Douglas S. Blank <dblank at brynmawr.edu> wrote:
> >> Ok, I can't find anything to fix this. I've tried combinations of
> lower,
> >> lift, deiconify, iconify, update, overridedirect, ... but nothing I do
> >> can get a new Tk window to appear on top of IDLE.
> >>
> >> This is very confusing for new students (and experts). I'll do whatever
> >> is necessary even it requires plugin or whatever. Can I lower IDLE?
> >>
> >> Any ideas?
> >>
> >> -Doug
> >>
> >> Here's some code to help anyone see the problem:
> >>
> >> # in IDLE on Windows XP:
> >> import Tkinter
> >> tl = Tkinter.Toplevel()
> >> tl.update()
> >> tl.raise()
> >> ...
> >>
> >> I can't get the tl window to appear on top of IDLE.
> >>
> >
> > Well, I ran into trouble at first too when trying to do this. In the
> > end I realized that deiconify(), tkraise() and focus() need to be
> > called once the Tk object's mainloop is already running. And that they
> > must be called from the same thread that the mainloop is running in,
> > so threads must be avoided.
> >
> > This seems to do the trick:
> >
> > def raised():
> >        top = Tk()
> >        text = Text(top)
> >        text.pack(expand=True)
> >        top.after(50, top.deiconify)
> >        top.after(50, top.tkraise)
> >        top.after(50, text.focus)
> >        top.mainloop()
> >
> >
> > Of course, using 'after' like this is an ugly hack. If the call to
> > mainloop is delayed somehow, then the window will not be raised
> > (that's why I used a 50 millisecond delay). I played around with
> > cleaner possibilities but ran into some difficulties... It's too late
> > at night, I'll give it another look tomorrow.
> >
> > - Tal
> >
>
>
> --
> Douglas S. Blank
> Associate Professor, Bryn Mawr College
> http://cs.brynmawr.edu/~dblank/
> Office: 610 526 6501
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20070901/94a5055f/attachment.htm 

From dblank at brynmawr.edu  Sat Sep  1 14:18:17 2007
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Sat, 1 Sep 2007 08:18:17 -0400 (EDT)
Subject: [Idle-dev] IDLE getpass?
In-Reply-To: <7afdee2f0709010120m41c7aad3ifb2c4ba802ab01e1@mail.gmail.com>
References: <1628.71.59.123.159.1185417021.squirrel@webmail.brynmawr.edu> 
	<7afdee2f0707252336m14e27b5ep3bc933802f010cc6@mail.gmail.com> 
	<46A8E118.8030101@brynmawr.edu> 
	<7afdee2f0707291416u3495ede0v566167e03b11b6b9@mail.gmail.com> 
	<46C47656.10003@brynmawr.edu> 
	<7afdee2f0708161918o78c05f0fu5272fd896f3dc4b2@mail.gmail.com> 
	<11379.71.59.123.159.1187324081.squirrel@webmail.brynmawr.edu>
	<7afdee2f0709010120m41c7aad3ifb2c4ba802ab01e1@mail.gmail.com>
Message-ID: <2330.71.59.123.159.1188649097.squirrel@webmail.brynmawr.edu>

On Sat, September 1, 2007 4:20 am, Tal Einat said:
> I have two ideas, but not the time to try them out:
>
> One is to embed an entry in the text widget - just like the Squeezer
> extension embeds a button. I think this would be the cleanest approach.

That would work for the specific getpass functionality, but in general the
problem of windows coming up behind IDLE is a real issue for newbies and
experts alike: it is just confusing.

> The other is to try making the getpass window transient to the main
> window,
> and/or to give its entry widget focus before calling deiconify and
> tkraise.

I have tried many dozens of combinations of things, including going down
to the Windows handle and using Windows system calls to try to force it
up, but nothing works. How would I make a "transient" window?

Thanks for keeping this in the back of your mind, Tal, but I think this
may be a lower-level Windows bug. I'm just telling students to put IDLE in
the right hand side of the screen so they'll see new windows. I've also
made new windows flash the docked window title (by a couple of
raises/lowers). So, I've learned to live with it...

Thanks again,

-Doug

> - Tal
>
> On 8/17/07, Douglas S. Blank <dblank at brynmawr.edu> wrote:
>>
>> Tal,
>>
>> Thanks for looking at this and giving feedback.
>>
>> Unfortunately, this doesn't seem to work for me when running with
>> subprocesses.
>>
>> Maybe it has to have to do with Tkinter running in the background
>> thread,
>> and tkraise not knowing about the IDLE window in the other thread (which
>> is on top).
>>
>> If there were a global ontop function, that would do it. I'm starting to
>> think that it isn't even possible in WindowsXP with IDLE with
>> processes...
>>
>> -Doug
>>
>> On Thu, August 16, 2007 10:18 pm, Tal Einat said:
>> > On 8/16/07, Douglas S. Blank <dblank at brynmawr.edu> wrote:
>> >> Ok, I can't find anything to fix this. I've tried combinations of
>> lower,
>> >> lift, deiconify, iconify, update, overridedirect, ... but nothing I
>> do
>> >> can get a new Tk window to appear on top of IDLE.
>> >>
>> >> This is very confusing for new students (and experts). I'll do
>> whatever
>> >> is necessary even it requires plugin or whatever. Can I lower IDLE?
>> >>
>> >> Any ideas?
>> >>
>> >> -Doug
>> >>
>> >> Here's some code to help anyone see the problem:
>> >>
>> >> # in IDLE on Windows XP:
>> >> import Tkinter
>> >> tl = Tkinter.Toplevel()
>> >> tl.update()
>> >> tl.raise()
>> >> ...
>> >>
>> >> I can't get the tl window to appear on top of IDLE.
>> >>
>> >
>> > Well, I ran into trouble at first too when trying to do this. In the
>> > end I realized that deiconify(), tkraise() and focus() need to be
>> > called once the Tk object's mainloop is already running. And that they
>> > must be called from the same thread that the mainloop is running in,
>> > so threads must be avoided.
>> >
>> > This seems to do the trick:
>> >
>> > def raised():
>> >        top = Tk()
>> >        text = Text(top)
>> >        text.pack(expand=True)
>> >        top.after(50, top.deiconify)
>> >        top.after(50, top.tkraise)
>> >        top.after(50, text.focus)
>> >        top.mainloop()
>> >
>> >
>> > Of course, using 'after' like this is an ugly hack. If the call to
>> > mainloop is delayed somehow, then the window will not be raised
>> > (that's why I used a 50 millisecond delay). I played around with
>> > cleaner possibilities but ran into some difficulties... It's too late
>> > at night, I'll give it another look tomorrow.
>> >
>> > - Tal
>> >
>>
>>
>> --
>> Douglas S. Blank
>> Associate Professor, Bryn Mawr College
>> http://cs.brynmawr.edu/~dblank/
>> Office: 610 526 6501
>>
>>
>


-- 
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 6501


From taleinat at gmail.com  Sat Sep  1 15:14:24 2007
From: taleinat at gmail.com (Tal Einat)
Date: Sat, 1 Sep 2007 16:14:24 +0300
Subject: [Idle-dev] IDLE getpass?
In-Reply-To: <7afdee2f0709010613r4a63d6b7n14ed9f9f89c8f92c@mail.gmail.com>
References: <1628.71.59.123.159.1185417021.squirrel@webmail.brynmawr.edu>
	<7afdee2f0707252336m14e27b5ep3bc933802f010cc6@mail.gmail.com>
	<46A8E118.8030101@brynmawr.edu>
	<7afdee2f0707291416u3495ede0v566167e03b11b6b9@mail.gmail.com>
	<46C47656.10003@brynmawr.edu>
	<7afdee2f0708161918o78c05f0fu5272fd896f3dc4b2@mail.gmail.com>
	<11379.71.59.123.159.1187324081.squirrel@webmail.brynmawr.edu>
	<7afdee2f0709010120m41c7aad3ifb2c4ba802ab01e1@mail.gmail.com>
	<2330.71.59.123.159.1188649097.squirrel@webmail.brynmawr.edu>
	<7afdee2f0709010613r4a63d6b7n14ed9f9f89c8f92c@mail.gmail.com>
Message-ID: <7afdee2f0709010614v6e1b5697q5e5df117592ad8c4@mail.gmail.com>

On 9/1/07, Douglas S. Blank <dblank at brynmawr.edu> wrote:
> On Sat, September 1, 2007 4:20 am, Tal Einat said:
> > I have two ideas, but not the time to try them out:
> >
> > One is to embed an entry in the text widget - just like the Squeezer
> > extension embeds a button. I think this would be the cleanest approach.
>
> That would work for the specific getpass functionality, but in general the
> problem of windows coming up behind IDLE is a real issue for newbies and
> experts alike: it is just confusing.
>
Well, at least we can solve the original issue :)

> > The other is to try making the getpass window transient to the main
> > window,
> > and/or to give its entry widget focus before calling deiconify and
> > tkraise.
>
> I have tried many dozens of combinations of things, including going down
> to the Windows handle and using Windows system calls to try to force it
> up, but nothing works. How would I make a "transient" window?
>
If you have a dialog class, use code such as the following:

if parent.winfo_viewable():
    self.transient(parent)

The condition ensures that the dialog is visible even if the parent is
withdrawn.

> Thanks for keeping this in the back of your mind, Tal, but I think this
> may be a lower-level Windows bug. I'm just telling students to put IDLE in
> the right hand side of the screen so they'll see new windows. I've also
> made new windows flash the docked window title (by a couple of
> raises/lowers). So, I've learned to live with it...
>
You're right that this is because of certain limitations of the
Windows window manager. But that doesn't mean we can't work around
these issues, or figure out how the window manager "wants" us to do
this. I'm certain there's a more or less generic solution to be found,
the question is if anybody has the time to loko for it...


By the way, another thing to try is to withdraw IDLE when you pop up
another window (without it being transient), and show it again when
the other window is done.

- Tal

From dblank at brynmawr.edu  Tue Sep  4 23:11:32 2007
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Tue, 04 Sep 2007 17:11:32 -0400
Subject: [Idle-dev] non-blocking getch() or kbhit() in IDLE
Message-ID: <46DDCA04.3050801@brynmawr.edu>

Is there a way in IDLE to check to see if a key has been pressed without 
blocking? Either cross-platform or otherwise? I'd like to have students 
write code like:

while not keyPress():
     robot.forward(1)
     wait(.1)

I was exploring the idlelib.rpc.RPCProxy object at sys.stdin, but didn't 
see anything obvious.

Any ideas appreciated,

-Doug

From taleinat at gmail.com  Wed Sep  5 09:37:46 2007
From: taleinat at gmail.com (Tal Einat)
Date: Wed, 5 Sep 2007 10:37:46 +0300
Subject: [Idle-dev] non-blocking getch() or kbhit() in IDLE
In-Reply-To: <46DDCA04.3050801@brynmawr.edu>
References: <46DDCA04.3050801@brynmawr.edu>
Message-ID: <7afdee2f0709050037s5ab9bc5ex54c904bdcb052beb@mail.gmail.com>

On 9/5/07, Douglas S. Blank <dblank at brynmawr.edu> wrote:
> Is there a way in IDLE to check to see if a key has been pressed without
> blocking? Either cross-platform or otherwise? I'd like to have students
> write code like:
>
> while not keyPress():
>      robot.forward(1)
>      wait(.1)
>
> I was exploring the idlelib.rpc.RPCProxy object at sys.stdin, but didn't
> see anything obvious.
>
> Any ideas appreciated,
>
> -Doug

In the IDLE shell you don't have access to any of the Tk events, since
it is run in a separate process. So you can't directly check for
keyboard events. And IDLE doesn't send input to the subprocess until a
code block is finished, so you can't check for single characters in
the input stream.

If you want to use IDLE's event loop, you'll have to write an
extension for this. You can also write something else which binds to
keyboard events, but then you'll have to make sure it gets notified of
the events ( i.e. IDLE doesn't "swallow" them first).

If you run IDLE without a subprocess then you can use its event loop
directly, but that would be ugly.

- Tal

From noreply at sourceforge.net  Sat Sep  1 22:05:21 2007
From: noreply at sourceforge.net (SourceForge.net Team)
Date: Sat, 01 Sep 2007 13:05:21 -0700
Subject: [Idle-dev] SourceForge.net privacy policy change effective
	2007-09-04
Message-ID: <20070906093104.68A361E4015@bag.python.org>

Hello, SourceForge.net User,

In connection with the ongoing SourceForge.net Marketplace open beta,
and our recent TRUSTe certification, on 2007-08-21 we published an
updated Privacy Statement for the SourceForge.net site.

Until 2007-09-04, when the the updated Privacy Statement will become
effective, it will be available at the following link:
https://sourceforge.net/docs/H11/

Thereafter, it will take the place of our existing Privacy Statement and
will be available at the following link: https://sourceforge.net/docs/H02/

Thank you,

SourceForge.net staff 

.

From michael at d2m.at  Tue Sep 11 08:20:28 2007
From: michael at d2m.at (Michael Haubenwallner)
Date: Tue, 11 Sep 2007 08:20:28 +0200
Subject: [Idle-dev] IDLE3.0a1 problems
Message-ID: <fc5c3l$rct$1@sea.gmane.org>

A few problems with IDLE 3.0a1 on WindowsXP:

- saving any file ends the program, without writing to that file at all
- using the build-in 'help' (which calls pydoc itself): the stdout is 
not always displayed inside the IDLE window but pops-up a 'cmd' window 
which lets you page through the descriptions.

Could you confirm this for other systems too ?

Michael

-- 
http://www.zope.org/Members/d2m
http:/planetzope.org


From taleinat at gmail.com  Wed Sep 12 14:32:02 2007
From: taleinat at gmail.com (Tal Einat)
Date: Wed, 12 Sep 2007 15:32:02 +0300
Subject: [Idle-dev] IDLE3.0a1 problems
In-Reply-To: <fc5c3l$rct$1@sea.gmane.org>
References: <fc5c3l$rct$1@sea.gmane.org>
Message-ID: <7afdee2f0709120532h542fe7cbia85cba144f5b181a@mail.gmail.com>

On 9/11/07, Michael Haubenwallner wrote:
> A few problems with IDLE 3.0a1 on WindowsXP:
>
> - saving any file ends the program, without writing to that file at all
> - using the build-in 'help' (which calls pydoc itself): the stdout is
> not always displayed inside the IDLE window but pops-up a 'cmd' window
> which lets you page through the descriptions.
>
> Could you confirm this for other systems too ?
>
> Michael
>

Both confirmed: WinXP SP2, Python 3.0a1, IDLE 3.0a1

The saving bug is a string/bytes issue, simply fixed by replaced line
366 in IOBinding.py with:
chars = chars.replace(b"\n", self.eol_convention.encode('ASCII'))

I'll send a patch for this ASAP.


I haven't had time to look into the help issue yet.

- Tal