From jquinn at cs.oberlin.edu Tue Aug 7 20:52:55 2007 From: jquinn at cs.oberlin.edu (Jameson "Chema" Quinn) Date: Tue, 7 Aug 2007 12:52:55 -0600 Subject: [Idle-dev] An idea and a bug Message-ID: I'm hacking at my own version of IDLE to try to implement language support in Python. I found a bug. 1. The bug. I'm using IDLE to work on a copy of IDLE in my home directory. I copy the idlelib directory to ~/jqidlelib , add "jq" to lines 2 and 22 of idle.py, open it in IDLE, and start hacking on the other files. If a hacked version of some other module is not open in IDLE and I press F5 to run idle.py, I get the desired behaviour (the modules are loaded from my hacked copies) but the error display is wacky. Errors refer to the line numbers of my hacked versions, but they give the path and code snippets from the actual IDLE directory. 2. My idea I have started a discussion on the OLPC wiki and over email with some interested parties within OLPC about the way to do i18n (internat...ion) on Python. My idea is to have code on-disk in "real", english-based python, but to allow displaying and editing of that code in the user's native language. This means that there are systems for invisible, real-time, two-way translation of keywords, identifiers, and docstrings/comments. This is primarily aimed at a young demographic; I realize that there are plenty of "real programmers" who learn the keywords of a programming language in their abstract meaning, without knowing the everyday English meaning of those terms. (after all, "string", "hash", and "for" have meanings in programming quite distinct from their everyday meanings anyway). Keywords: dynamic two-way translation is easy. Identifiers: supports initially creating identifiers in a native (unicode) language. When a translation is created later (using easy context menus and dictionary-based guessing support), the .py file is changed to include the English version, and the translation is stored in a parallel .p4n file. Translations of included modules are imported from their .p4n files. All clashes and character set issues are dealt with (using prefixes to escape, for instance) in order to keep the translation reversible at all times. This requires some minor modifications to python itself for the case when an imported module has added a translation but the calling code has not been edited since then so it still uses the non-english version of the identifier. This case would be treated with extreme care to prevent security hazards. Docstrings and comments: These are either escaped as "code" (using simple ascii markup) and translated using the same system as above, or translated on a by-line basis. Support would exist to do initial translation using some on-line babelfish-like tool. I think the best way to explain all this is to implement it, so I'm doing so. Ideally, this implementation will be clean, simple, and unobtrusive enough that it will become a standard feature of IDLE, and even inspire inclusion in other IDEs - becoming standard within Python, and available for other languages and human-editable data formats. Cheers, Jameson Quinn ps. Here's how Mike Fletcher put his proposed solution, my emphasis added, the visual stuff he mentions is a separate issue: My idea for internationalization is as follows: * assume a progression from graphical, to local language, to subset-of-English for those who want to become proficient programmers o provide tools that let the children put blocks together in a reasonably constrained environment o show the children what putting the blocks together does in their native language o let the children edit the source-code in their own language to start with o allow the children to flip back and forth between native-language keywords and English keywords o support the children in translating to/from English for code they want to publish * for each component in the programming language (e.g. for loops, while loops, variable assignment, etceteras) o provide a visual form which implies the operation and allows for drag-and-drop operation o provide a canonical translation (which is also reserved words/symbols/punctuation in the native language) o provide a localized description of the operation (preferably with some simple lessons on usage, maybe some demos with sample code for each one, hook these up in the UI so that the child can explore the idea behind the operation) o when used, show the (standard) Python code generated by the usage * for the special case of identifiers in the user's (non-ascii-compatible) language o store all identifiers as transcoded[1] ascii identifiers in the source code on initial writing (before translation) o display all identifiers as their non-transcoded versions in the UI o store the translation matrix in a separate file (to allow for multiple translations) * allow for a localization option that also translates keywords and builtins o uses the canonical translation o allow the user to input any Unicode identifier as an identifier which is not in the canonical translation o typing in the localized version of "for" or "class" would insert "for" and "class" into the stored code * identifiers/keywords which have no translations are presented in ascii (i.e. all current Python code would show up in English, potentially with keywords in Arabic or Thai) * have a tool that allows for querying e.g. BabelFish to get translations from/to a given language for given identifiers o allow for exporting any pure-ascii translation (e.g. English) to the base file (updating the translation tables as we do so) o should provide both localization and internationalization support (i.e. the same tool would allow the country to load a common Python module and produce a translation for it) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20070807/23b6a331/attachment.htm From taleinat at gmail.com Tue Aug 7 21:19:46 2007 From: taleinat at gmail.com (Tal Einat) Date: Tue, 7 Aug 2007 22:19:46 +0300 Subject: [Idle-dev] An idea and a bug In-Reply-To: References: Message-ID: <7afdee2f0708071219h5d6986a0x4aee6121bf1b8cea@mail.gmail.com> On 8/7/07, Jameson Chema Quinn wrote: > I'm hacking at my own version of IDLE to try to implement language support > in Python. I found a bug. > > 1. The bug. > I'm using IDLE to work on a copy of IDLE in my home directory. I copy the > idlelib directory to ~/jqidlelib , add "jq" to lines 2 and 22 of idle.py, > open it in IDLE, and start hacking on the other files. If a hacked version > of some other module is not open in IDLE and I press F5 to run idle.py, I > get the desired behaviour (the modules are loaded from my hacked copies) but > the error display is wacky. Errors refer to the line numbers of my hacked > versions, but they give the path and code snippets from the actual IDLE > directory. If you do a directory-wide search for 'idlelib' you'll find that it is mentioned in PyShell.py as well. I haven't tried this myself, so please inform us whether or not this works :) > 2. My idea > [snip] Awesome! I'll be glad to answer any questions you might have regarding IDLE's internals. An early pointer: IDLE doesn't currently allow unicode input, so you'll have to rework that bit if you want unicode input support. Good luck, and please keep us posted on developments, - Tal From jquinn at cs.oberlin.edu Tue Aug 7 21:48:37 2007 From: jquinn at cs.oberlin.edu (Jameson "Chema" Quinn) Date: Tue, 7 Aug 2007 13:48:37 -0600 Subject: [Idle-dev] An idea and a bug In-Reply-To: <7afdee2f0708071219h5d6986a0x4aee6121bf1b8cea@mail.gmail.com> References: <7afdee2f0708071219h5d6986a0x4aee6121bf1b8cea@mail.gmail.com> Message-ID: On 8/7/07, Tal Einat wrote: > > On 8/7/07, Jameson Chema Quinn wrote: > > I'm hacking at my own version of IDLE to try to implement language > support > > in Python. I found a bug. > > > > 1. The bug. > > I'm using IDLE to work on a copy of IDLE in my home directory. I copy > the > > idlelib directory to ~/jqidlelib , add "jq" to lines 2 and 22 of idle.py > , > > open it in IDLE, and start hacking on the other files. If a hacked > version > > of some other module is not open in IDLE and I press F5 to run idle.py, > I > > get the desired behaviour (the modules are loaded from my hacked copies) > but > > the error display is wacky. Errors refer to the line numbers of my > hacked > > versions, but they give the path and code snippets from the actual IDLE > > directory. > > If you do a directory-wide search for 'idlelib' you'll find that it is > mentioned in PyShell.py as well. I haven't tried this myself, so > please inform us whether or not this works :) Changing it there has no effect. In the intervening time, I'm getting even weirder behavior: with my hacked EditorWindow open, I fix the bug in my code and save it. Then I press F5 in the idle.py window again. I get: Traceback (most recent call last): File "/home/compaq/jqidlelib/idle.py", line 22, in jqidlelib.PyShell.main() File "/usr/lib/python2.5/idlelib/PyShell.py", line 1406, in main return # couldn't open shell File "/usr/lib/python2.5/idlelib/PyShell.py", line 275, in open_shell self.pyshell = PyShell(self) File "/usr/lib/python2.5/idlelib/PyShell.py", line 813, in __init__ OutputWindow.__init__(self, flist, None, None) File "idlelib/OutputWindow.py", line 16, in __init__ EditorWindow.__init__(self, *args) File "/home/compaq/jqidlelib/EditorWindow.py", line 56, in __init__ if EditorWindow.help_url is None: NameError: global name 'trns' is not defined The "trns" is from the previous version of EditorWindow which NO LONGER EXISTS on the disk, which is why the code snippet doesn't mention it. Also, note that the paths for the call stack show a mix between idlelib and jqidlelib, depending on which files I have open. This is just FALSE - all modules are actually being loaded from jqidlelib, as I can easily tell if I introduce a syntax error and then close the file. Meanwhile, I can work around by just closing and reopening idle. Annoying, though. > 2. My idea > > [snip] > > Awesome! I'll be glad to answer any questions you might have regarding > IDLE's internals. > > An early pointer: IDLE doesn't currently allow unicode input, so > you'll have to rework that bit if you want unicode input support. I can afford to wait on that, as my first test case is Spanish, and Idle only has minor complaints about accents. Thanks for the heads up, though - this will need to be fixed for py3k anyway, what's the status on that? Good luck, and please keep us posted on developments, > - Tal > Thanks, Jameson ps. here's my idle version stuff: Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 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.2.1 ==== No Subprocess ==== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20070807/4cad692b/attachment.htm From taleinat at gmail.com Wed Aug 8 18:54:54 2007 From: taleinat at gmail.com (Tal Einat) Date: Wed, 8 Aug 2007 19:54:54 +0300 Subject: [Idle-dev] An idea and a bug In-Reply-To: References: <7afdee2f0708071219h5d6986a0x4aee6121bf1b8cea@mail.gmail.com> <7afdee2f0708071346y24eeafd1of4df397c7f896c85@mail.gmail.com> Message-ID: <7afdee2f0708080954w1da4a43ax17a3566c8461840e@mail.gmail.com> On 8/8/07, Jameson Chema Quinn wrote: > > > > > > This is all very strange behavior. > > > > Please try the following: > > 1. Replace all instances of 'idlelib' into 'jqidlelib', including > > appearances inside strings. There should be two of these in PyShell.py > > and two in idle.py. Also, make sure it doesn't appear in run.py either > > (if it does, change it there too.) > > 2. Rename/move the normal idlelib directory (temporarily) > > 3. Close all existing instances of IDLE (and make sure no zombie > > Python processes are still running in the background) > > 4. Try running your version of IDLE again > > > > If IDLE still crashes, please send the tracebacks. > > > > - Tal > > > > I think you misunderstand. The problem occurs, not when I run my script from > the shell or from some other IDE, but when I run it from within IDLE. This > makes it more understandable - but it is still a bug. Perhaps it's OK if you > can't edit IDLE from within IDLE, but you should not get funny behaviour > every time you load a module that happens to share a name with an IDLE > module. > > Jameson > I think I understand the problem now - you're editing your version of IDLE with the existing version, and you're having module importing issues. The problem is that when you run a Python script, the interpreter adds the script's directory to the beginning of sys.path. This means the when you do "import ", Python will go through the directories in sys.path searching for a file by that name, and so it will find first and use anything in the directory from where the script was run. This is true for IDLE as well, and I can see now how this can cause problems. What you should do is run IDLE without adding its directory to sys.path. Here's a quick way to do so from the command line: python.exe -c "import idlelib.PyShell; idlelib.PyShell.main()" Just run this from a directory which has nothing Python-related in it, and you'll have no such importing issues. To completely ignore the directory from which Python was run, use: python.exe -c "import sys; del sys.path[0]; import idlelib.PyShell; idlelib.PyShell.main()" Another way would be to remove the directory from sys.path after IDLE has started, inside IDLE's shell. However, it may not be the first item in the sys.path list, because IDLE sometimes adds more directories to sys.path. Anyways, sorry for taking a while to understand the issue and hoping the above helps, - Tal From taleinat at gmail.com Sat Aug 11 14:40:31 2007 From: taleinat at gmail.com (Tal Einat) Date: Sat, 11 Aug 2007 15:40:31 +0300 Subject: [Idle-dev] Cleaner Percolator.py implementation Message-ID: <7afdee2f0708110540y52c1e3c5k77dd6bcc38699ece@mail.gmail.com> I took the time to clean up the implementation of Percolator and add some comments and doc-strings. I plan to do the same for Delegator soon. I have found these to be very confusing and hard to understand, although they could be a good piece of code to learn from. I hope I've made the code more Pythonic :) This version of Percolator inherits from Delegator (since a Percolator "is a" Delegator, after all). I've also refactored the Tk-Text-widget-specific stuff into a subclass, TkTextPercolator, which is functionally equivalent to the original Percolator. To use this in IDLE, use this file instead of Percolator.py (either replace it or import this file instead of the original), and use the TkTextPercolator class instead of Percolator (in EditorWindow.py). I'm willing to post this as a patch on SF if there is any interest. Comments are most welcome :) - Tal -------------- next part -------------- A non-text attachment was scrubbed... Name: MyPercolator.py Type: text/x-python Size: 4256 bytes Desc: not available Url : http://mail.python.org/pipermail/idle-dev/attachments/20070811/e394f2b4/attachment.py From dblank at brynmawr.edu Thu Aug 16 18:07:50 2007 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu, 16 Aug 2007 12:07:50 -0400 Subject: [Idle-dev] IDLE getpass? In-Reply-To: <7afdee2f0707291416u3495ede0v566167e03b11b6b9@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> Message-ID: <46C47656.10003@brynmawr.edu> Tal Einat wrote: >> 3) If I have to open a Tk window, how can I get it to appear on top of >> the IDLE window? > > IIRC this depends on your window manager. Tk's 'raise' command > ('tkraise' in Python's Tkinter, because 'raise' is a Python keyword) > just doesn't work on windows - this is a well known bug. I seem to > recall that the TopLevel widgets' 'wm_deiconify' method has something > to do with it... Try a Google Groups search on this issue + Tk, and > you should find an answer. 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. >> Thanks for any additional hints, >> >> -Doug > > Sorry for the unusually delayed reply! > - Tal > From dblank at brynmawr.edu Thu Aug 16 22:31:26 2007 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu, 16 Aug 2007 16:31:26 -0400 Subject: [Idle-dev] Extension to handle Cancel Message-ID: <46C4B41E.7040301@brynmawr.edu> I'm working on a plugin extension for IDLE that can run a test when Control+C is pressed. Unfortunately, Control+C (or in Tkinter bindings) is not handled as other key bindings are. Instead there is a cancel_callback in the pyshell instance that is called. So, I've tried to replace the cancel_callback method from inside the extension (I have a working version from an external main---but it is really hacky). However, it looks like editwin.flist.pyshell doesn't exist yet when the constructor of the extension is called. Is there any way for my extension module to have some code that gets called after the pyshell has been created? -Doug Sample code: class ExtensionTest: def __init__(self, editwin): # works for other windows, after the shell is made, but: print editwin.flist.pyshell.cancel_callback, "does not exist yet" # when constructed for the shell From dblank at brynmawr.edu Thu Aug 16 23:10:18 2007 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Thu, 16 Aug 2007 17:10:18 -0400 Subject: [Idle-dev] Running with subprocesses? Message-ID: <46C4BD3A.7090100@brynmawr.edu> [Sorry for the barrage of questions... a new semester starting soon... :(] It would be nice if an extension, or even a general running program, could look somewhere to see if IDLE is running with subprocesses. Something like PyShell.using_subprocess = 0. Is there a hack that would currently work to tell? -Doug From taleinat at gmail.com Fri Aug 17 00:31:32 2007 From: taleinat at gmail.com (Tal Einat) Date: Fri, 17 Aug 2007 01:31:32 +0300 Subject: [Idle-dev] Running with subprocesses? In-Reply-To: <46C4BD3A.7090100@brynmawr.edu> References: <46C4BD3A.7090100@brynmawr.edu> Message-ID: <7afdee2f0708161531v595b5ceby1222e584f858e5e5@mail.gmail.com> On 8/17/07, Douglas S. Blank wrote: > [Sorry for the barrage of questions... a new semester starting soon... :(] > > It would be nice if an extension, or even a general running program, > could look somewhere to see if IDLE is running with subprocesses. > Something like PyShell.using_subprocess = 0. Is there a hack that would > currently work to tell? > You can check flist.pyshell.interp.rpcclt. The debugging code in PyShell.py checks that it is not None. The extra-safe version (used in AutoComplete.py) is: try: rpcclt = self.editwin.flist.pyshell.interp.rpcclt except: rpcclt = None if rpcclt: else: This would be a nice addition to PyShell (or perhaps flist?). I'll add this to my to-do list. - Tal From taleinat at gmail.com Fri Aug 17 00:42:43 2007 From: taleinat at gmail.com (Tal Einat) Date: Fri, 17 Aug 2007 01:42:43 +0300 Subject: [Idle-dev] Extension to handle Cancel In-Reply-To: <46C4B41E.7040301@brynmawr.edu> References: <46C4B41E.7040301@brynmawr.edu> Message-ID: <7afdee2f0708161542g26946f90rffe8169e1d2d07a1@mail.gmail.com> On 8/16/07, Douglas S. Blank wrote: > I'm working on a plugin extension for IDLE that can run a test when > Control+C is pressed. Unfortunately, Control+C (or in Tkinter > bindings) is not handled as other key bindings are. Instead there is a > cancel_callback in the pyshell instance that is called. > > So, I've tried to replace the cancel_callback method from inside the > extension (I have a working version from an external main---but it is > really hacky). However, it looks like editwin.flist.pyshell doesn't > exist yet when the constructor of the extension is called. > > Is there any way for my extension module to have some code that gets > called after the pyshell has been created? > > -Doug > > Sample code: > > class ExtensionTest: > def __init__(self, editwin): > # works for other windows, after the shell is made, but: > print editwin.flist.pyshell.cancel_callback, "does not exist yet" > # when constructed for the shell Hi Doug, First off - Why Ctrl+C? It seems the simplest solution would be to bind to a different hotkey, unless you deliberately want to override the ability to use Ctrl+C to raise KeyboardInterrupt exceptions. The answer is to just use editwin, and not flist.pyshell. When PyShell is initialized, it will load the extension (the extensions are loaded once per EditorWindow instance). You can set the 'enable_editor' config option to False (or zero) for the extension to cause it to be loaded only for the PyShell window and not for file editing windows. If you want to be 100% sure, you can do 'isinstance(PyShell.PyShell, editwin)' to ensure that the window is a shell window (so that things don't go wrong if a user changes the 'enable_editor' config option). - Tal From taleinat at gmail.com Fri Aug 17 04:18:10 2007 From: taleinat at gmail.com (Tal Einat) Date: Fri, 17 Aug 2007 05:18:10 +0300 Subject: [Idle-dev] IDLE getpass? In-Reply-To: <46C47656.10003@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> Message-ID: <7afdee2f0708161918o78c05f0fu5272fd896f3dc4b2@mail.gmail.com> On 8/16/07, Douglas S. Blank 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 From dblank at brynmawr.edu Fri Aug 17 06:39:13 2007 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Fri, 17 Aug 2007 00:39:13 -0400 (EDT) Subject: [Idle-dev] Running with subprocesses? Message-ID: <11410.71.59.123.159.1187325553.squirrel@webmail.brynmawr.edu> Tal said: >On 8/16/07, Douglas S. Blank wrote: >> I'm working on a plugin extension for IDLE that can run a test when >> Control+C is pressed. Unfortunately, Control+C (or in Tkinter >> bindings) is not handled as other key bindings are. Instead there is a >> cancel_callback in the pyshell instance that is called. >> >> So, I've tried to replace the cancel_callback method from inside the >> extension (I have a working version from an external main---but it is >> really hacky). However, it looks like editwin.flist.pyshell doesn't >> exist yet when the constructor of the extension is called. >> >> Is there any way for my extension module to have some code that gets >> called after the pyshell has been created? >> >> -Doug >> >> Sample code: >> >> class ExtensionTest: >> def __init__(self, editwin): >> # works for other windows, after the shell is made, but: >> print editwin.flist.pyshell.cancel_callback, "does not exist yet" >> # when constructed for the shell > >Hi Doug, > >First off - Why Ctrl+C? It seems the simplest solution would be to >bind to a different hotkey, unless you deliberately want to override >the ability to use Ctrl+C to raise KeyboardInterrupt exceptions. Tal, Yeah, I know---it is really a nonstandard goal. But, I do have this working, albeit in a hackish manner: when the user types Control+C, not only will the code stop if running, but the robot that we are controlling (which might be moving) will stop as well. >The answer is to just use editwin, and not flist.pyshell. When PyShell >is initialized, it will load the extension (the extensions are loaded >once per EditorWindow instance). You can set the 'enable_editor' >config option to False (or zero) for the extension to cause it to be >loaded only for the PyShell window and not for file editing windows. Ok, that worked. But now I can't figure out how the extension can get access to the shell's environment. Remember that I'm running IDLE with processes, too. Thanks for any ideas (but I'm thinking my original hacks will just have to do). -Doug >If you want to be 100% sure, you can do 'isinstance(PyShell.PyShell, >editwin)' to ensure that the window is a shell window (so that things >don't go wrong if a user changes the 'enable_editor' config option). > >- Tal > >-- >Douglas S. Blank >Associate Professor, Bryn Mawr College >http://cs.brynmawr.edu/~dblank/ >Office: 610 526 6501 From dblank at brynmawr.edu Fri Aug 17 06:14:41 2007 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Fri, 17 Aug 2007 00:14:41 -0400 (EDT) Subject: [Idle-dev] IDLE getpass? In-Reply-To: <7afdee2f0708161918o78c05f0fu5272fd896f3dc4b2@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> Message-ID: <11379.71.59.123.159.1187324081.squirrel@webmail.brynmawr.edu> 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 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 From noreply at sourceforge.net Mon Aug 27 19:48:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Aug 2007 10:48:17 -0700 Subject: [Idle-dev] [ idlefork-Bugs-763524 ] Colorizing/Beeps/Focus/Crashes RFE/Bugs Message-ID: Bugs item #763524, was opened at 2003-06-30 18:20 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=763524&group_id=9579 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Kurt B. Kaiser (kbk) Summary: Colorizing/Beeps/Focus/Crashes RFE/Bugs Initial Comment: I've been using the latest version from Python CVS on Win9: quite intensively over the last week. Some observations: - When reusing a blank untitled window to edit a Text file, it keeps using Python coloring. - When saving a Python with a non-Python extension (e.g. .txt), it keeps the coloring. - When switching off coloring by saving an untitle buffer as a non-Python extension (e.g. .txt), it keeps existing coloring. - When opening a file reuses a blank untitled window, it doesn't set the focus on the window. - I take back my earlier request to do something when the stack viewer window can't find a traceback. It beeps, but I had my sound off. - When right click -> Go to file/line can't find something, perhaps it should just beep rather than pop up a dialog. - Maybe anything that can't do something that's pretty obvious should just beep? Or maybe errors should be displayed somehow but not require clicking OK? - Selecting a window from the Windows menu doesn't set the focus on the selected window! - Keyboard shortcut for Redo (Ctl-Shift-Z) doesn't actually work! - Is there any way to set a breakpoint programmatically? (the IDLE debugger equivalent of pdb.set_trace()) - I think I crashed it by using the stack viewer after closing the PyShell. - It also crashed occasionally when using the debugger (after many successful debug sessions). - stack browser window needs title (currently says "idle") - debugger doesn't always pop up when started - source window doesn't always pop up when double clicking in debugger - want a "save all" in file menu. - suspending win98 has high probability of crashing idle when a subprocess exists (?) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-06-12 00:18 Message: Logged In: YES user_id=149084 Python Patch 1196895 fixed the colorizing issues. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-22 01:40 Message: Logged In: YES user_id=149084 Addressed the two focus issues: reuse of blank window and Windows menu now grab focus. Addressed the two window raising issues in debugger. Fixed in Python IDLE 1.1a3. WindowList.py Rev 1.6 and associated changes. Redo shortcut was fixed in Python IDLE 1.1a1. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-01 07:40 Message: Logged In: YES user_id=6380 2. There's a special feature that if you have a blank, unchanged, untitled window (e.g. created by ^N) and then from within that window open a file, the opened file reuses the blank window rather than creating a new window like it normally does. Apparently a few settings aren't correctly set/reset in this case. 3. Agreed. 4. So true. It's fine to ignore it. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-01 02:30 Message: Logged In: YES user_id=149084 1. Rather than aggravate the list with endless copies of this tracker every time one gets fixed, I'm going to add the items to the TODO with a final disposition here when all fixed (or not :) 2. I can't reproduce the first item. What does "reusing a blank, untitled..." mean? Exactly what did you do to get to that point? 3. Generally, I like a quiet interface. I don't like dialogs popping up when I'm just being stupid or trying something to see if it's possible. Beeps are ok, I just turn the sound down. Of course some people like to listen to music, so I suppose we'll need a config option at some point. 4. In my experience, suspending W98 has a high probability of crashing, period. I'm not sure how I'd attack that one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=763524&group_id=9579 From noreply at sourceforge.net Mon Aug 27 19:48:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Aug 2007 10:48:57 -0700 Subject: [Idle-dev] [ idlefork-Feature Requests-758698 ] Couple of feature requests Message-ID: Feature Requests item #758698, was opened at 2003-06-22 04:18 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=359579&aid=758698&group_id=9579 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Kurt B. Kaiser (kbk) Summary: Couple of feature requests Initial Comment: - F5 should offer to save *all* files rather than just the one. It's hard to track down all files you've touched in a larger project. - When the stackviewer can't open its window because sys.last_traceback etc. aren't defined, it should pop up a warning rather than just doing nothing. - I like a way to re-run the last file on which I used F5 regardless of which window I am currently in (even the shell). Use case: editing a large multi-module program, the main program is a separate file that runs unit tests. Suggestion: Ctl-F5. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-27 13:48 Message: Logged In: YES user_id=6380 Originator: YES I don't want this on my dashboard any more. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-06-22 22:08 Message: Logged In: YES user_id=149084 These are excellent requests, especially the first and last ones. I was planning on doing them before you asked. I'm making good use of the Autosave feature, and haven't been bitten by it yet. It really makes for speedy turn-around. I find I'm using IDLE about half the time now, with my emacs usage going down. Now, if we had incremental search....and smart tab.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=359579&aid=758698&group_id=9579