Issue 8427: toplevel jumps to another location on the screen (original) (raw)
Issue8427
Created on 2010-04-16 20:50 by aparasch, last changed 2022-04-11 14:57 by admin. This issue is now closed.
| Files | |||
|---|---|---|---|
| File name | Uploaded | Description | Edit |
| jumpBug.py | aparasch,2012-04-24 00:43 |
| Messages (6) | ||
|---|---|---|
| msg103358 - (view) | Author: Andrei Paraschivescu (aparasch) | Date: 2010-04-16 20:50 |
| The effect is the window just jumps to another location, matching left corners with another window in the same Python application. Its size doesn't change. The effect is somewhat erratic, the best I've been able to create is a situation where it happens 90% of the time. The application contains a number of widget.after calls, and I have not been able to replicate it with a small example. I am running Mac OS X 10.4.11 and Python 2.6; running from my PC with Windows XP the effect doesn't happen, so it might be a OS X/Tk issue. | ||
| msg113042 - (view) | Author: Terry J. Reedy (terry.reedy) *  |
Date: 2010-08-05 20:31 |
| Can you show minimum length code that shows the effect you claim? | ||
| msg156859 - (view) | Author: Andrew Svetlov (asvetlov) * |
Date: 2012-03-26 19:39 |
| Ping | ||
| msg159106 - (view) | Author: Andrei Paraschivescu (aparasch) | Date: 2012-04-24 00:43 |
| "python jumpBug.py" creates two windows, "root" and "other". If the first thing you do is click on "other", then hit , the printed geometry string will show the position of the window "root". By contrast, if you first click on "root", then on "other", followed by , the correct position of "other" is shown. As mentioned before, this happens on OS X Tiger but not on my FreeBSD machine, or new Mac laptop running Snow Leopard. I've isolated that the erratic jumping of windows I mentioned in the initial bug report is caused by calling .geometry with incorrect geometry strings. |
||
| msg159111 - (view) | Author: Ned Deily (ned.deily) * |
Date: 2012-04-24 02:18 |
| Thanks for supplying the test case. I can reproduce the incorrect behavior by using Python 2.7 and the Apple-supplied system Tcl/Tk 8.4 on OS X 10.4. But if a current ActiveState Tcl/Tk 8.4 is used with the same Python and OS X, the correct behavior is seen. The Apple-supplied Tcl/Tk on OS X 10.4 is very old; if you need to use Tkinter-based applications there, you should install an ActiveState Tcl/Tk 8.4 and a current Python that is supported with it, for example, from the current 32-bit-only Python 2.7.3 or 3.2.3 python.org installers. More info here: http://www.python.org/download/mac/tcltk/ | ||
| msg159113 - (view) | Author: Andrei Paraschivescu (aparasch) | Date: 2012-04-24 02:27 |
| Ned, thanks for the quick response. I will give that a go. |
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:57:00 | admin | set | github: 52674 |
| 2012-04-24 02:27:43 | aparasch | set | messages: + |
| 2012-04-24 02🔞47 | ned.deily | set | status: open -> closednosy: + ned.deilymessages: + resolution: out of datestage: resolved |
| 2012-04-24 00:43:46 | aparasch | set | files: + jumpBug.pymessages: + |
| 2012-03-26 19:39:29 | asvetlov | set | nosy: + asvetlovmessages: + |
| 2010-08-05 20:31:38 | terry.reedy | set | nosy: + terry.reedymessages: + |
| 2010-05-03 06:34:27 | aparasch | set | type: behavior |
| 2010-04-16 20:50:05 | aparasch | create |