IDLE development

headers Tal Einat | 1 Sep 2007 10:20

_______________________________________________
IDLE-dev mailing list
IDLE-dev <at> python.org
http://mail.python.org/mailman/listinfo/idle-dev

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

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

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

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

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 

.

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

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

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

5	May 2013
24	April 2013
52	March 2013
20	January 2013
4	November 2012
7	October 2012
1	September 2012
7	August 2012
9	July 2012
23	June 2012
1	April 2012
1	March 2012
1	February 2012
11	January 2012
14	December 2011
6	November 2011
9	October 2011
5	September 2011
3	August 2011
11	July 2011
6	May 2011
27	April 2011
7	March 2011
13	February 2011
2	December 2010
2	November 2010
37	October 2010
3	September 2010
14	August 2010
60	July 2010
4	May 2010
21	April 2010
1	March 2010
1	December 2009
5	October 2009
3	September 2009
22	August 2009
7	July 2009
13	June 2009
8	May 2009
4	April 2009
3	March 2009
9	January 2009
5	December 2008
12	November 2008
4	October 2008
2	September 2008
19	August 2008
7	June 2008
16	May 2008
12	April 2008
1	March 2008
3	February 2008
2	January 2008
14	November 2007
8	September 2007
14	August 2007
14	July 2007
25	May 2007
5	April 2007
4	March 2007
18	February 2007
12	January 2007
22	December 2006
5	November 2006
3	October 2006
12	September 2006
3	August 2006
14	July 2006
17	June 2006
9	May 2006
5	April 2006
3	March 2006
6	February 2006
5	January 2006
4	December 2005
21	November 2005
35	October 2005
19	June 2005
3	May 2005
3	April 2005
8	March 2005
11	February 2005
10	January 2005
13	December 2004
1	October 2004
10	September 2004
9	August 2004
10	July 2004
8	June 2004
8	May 2004
14	April 2004
6	March 2004
31	February 2004
7	January 2004
7	December 2003
30	November 2003
6	October 2003
39	September 2003
31	August 2003
25	July 2003
66	June 2003
120	May 2003
18	April 2003
52	March 2003
35	February 2003
157	January 2003
102	December 2002
47	November 2002
33	October 2002
172	September 2002
27	August 2002
27	July 2002
45	June 2002
62	May 2002
13	April 2002

Re: IDLE getpass?

Re: IDLE getpass?

Re: IDLE getpass?

non-blocking getch() or kbhit() in IDLE

Re: non-blocking getch() or kbhit() in IDLE

SourceForge.net privacy policy change effective 2007-09-04

IDLE3.0a1 problems

Re: IDLE3.0a1 problems