From trevor.robertson55 at gmail.com Mon Jun 4 01:15:28 2018 From: trevor.robertson55 at gmail.com (Trevor Robertson) Date: Mon, 4 Jun 2018 07:15:28 +0200 Subject: [Idle-dev] keyboard shortcuts for search-and-replace dialog Message-ID: Hi, I like the simple useability of IDLE... It would be great though (for somebody like me who is keyboard-focused instead of mouse-focused): If the sub-options inside this dialog (and others) e.g. "replace" / "replace+find"/ "replace all" also had their own keyboard shortcuts (or enabled you to define your own). Find+replace is something you do quite often in a script. Thanks so much (Windows 10; Python 3.6.5) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Tue Jun 5 13:07:38 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 5 Jun 2018 13:07:38 -0400 Subject: [Idle-dev] keyboard shortcuts for search-and-replace dialog In-Reply-To: References: Message-ID: <4376e538-1889-8ec7-bea4-22f366dbef6a@udel.edu> [Trevor, I am sending a copy direct to you since you are not subscribed and I don't know if you know how to read idle-dev via news.gmane.org. Please send any response to the list, not me.] On 6/4/2018 1:15 AM, Trevor Robertson wrote: > Hi, I like the simple useability of IDLE... > It would be great though (for somebody like me who is keyboard-focused > instead of mouse-focused): > If the sub-options inside this dialog (and others) e.g. "replace" / > "replace+find"/ "replace all" also had their own keyboard shortcuts (or > enabled you to define your own). > Find+replace is something you do quite often in a script. > Thanks so much > (Windows 10; Python 3.6.5) IDLE uses the following standard for navigating dialogs, which was discussed at https://bugs.python.org/issue27621 Escape closes the dialog. Enter invokes the default action, which is specially marked with a 'default ring. These two rules cover both actions buttons on the Search dialog. These two rules are not currently implemented for the Settings dialog, and maybe some others. https://bugs.python.org/issue27620 Shift Tab / Tab moves the dialog focus to the previous / next widget in the focus cycle. The widget with focus has a cursor or a dashed focus ring. Space clicks a (check)(radio)button that has focus. For the multitab Settings dialog, the current tab is supposed to be part of the focus cycle. When a tab has focus, one can move to other tabs with left and right arrow. (However, changing the font sample box from read-only label to editable text had the side-effect of intercepting tab key presses, thus trapping focus in the sample box. I will try to fix this.) All of this should be documented in a new subsection of the Editing and Navigation section of the IDLE doc chapter. --- Adding dialog and widget specific shortcuts is trickier. I think the best thing would be something like the menus, where pressing Alt underlines the hotkey letter. I don't believe that I can make letters on labels be underlined, but there are other ways to mark a letter: _A, A_, or ? (\u24b6, etc). The circled letters would not change spacing much. But fixing the standard navigation method is a higher priority to me. -- Terry Jan Reedy From tjreedy at udel.edu Mon Jun 11 17:25:04 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 11 Jun 2018 17:25:04 -0400 Subject: [Idle-dev] Simple IDLE improvement In-Reply-To: <9147c1c4-eb2d-e0ff-3ab5-5d311766c473@udel.edu> References: <9147c1c4-eb2d-e0ff-3ab5-5d311766c473@udel.edu> Message-ID: On 5/26/2018 7:43 PM, Terry Reedy wrote: > On 5/25/2018 11:52 AM, Elisha Paine wrote: >> Hi IDLE team >> >> I love IDLE (so simple and lightweight compared with other IDEs) and >> was just wondering if you could add the following code into pyshell.py >> and pyshell.pyw > > There is, currently, no pyshell.pyw.? pyshell.py is run however IDLE is > started. > (as I have done on mine) because, as you will be able to tell, it sets > DPI awareness (and on my set-up makes the text a lot clearer) > > On my wide-screen monitor attached to a video card, using white on dark. > ?I would not say 'a lot' clearer, but the text is noticeably clearer, > box lines are sharper, white and some colors are brighter, and some > characters are better formed.? After comparing IDLE without and with the > patch to Command Prompt, using the same font and nearly the same size, I > conclude that Command Prompt has dpi awareness turned on. > >> import ctypes >> try: ctypes.windll.shcore.SetProcessDpiAwareness (True) >> except: pass > > Thank you.? I like it.? I opened > https://bugs.python.org/issue33656 Fixed merged in time for 3.6.6rc1 and 3.7.0rc1, so it should be in the final release of both. -- Terry Jan Reedy From ether.joe at gmail.com Mon Jun 11 18:02:12 2018 From: ether.joe at gmail.com (Sean Felipe Wolfe) Date: Mon, 11 Jun 2018 15:02:12 -0700 Subject: [Idle-dev] Simple IDLE improvement In-Reply-To: References: <9147c1c4-eb2d-e0ff-3ab5-5d311766c473@udel.edu> Message-ID: Hello Elisha :) We are also using IDLE at high schools here in Oakland, California. It is lots of fun! Thanks Terry for the fixes ! Happy IDLEing ~~~ On Mon, Jun 11, 2018 at 2:25 PM, Terry Reedy wrote: > On 5/26/2018 7:43 PM, Terry Reedy wrote: > >> On 5/25/2018 11:52 AM, Elisha Paine wrote: >> >>> Hi IDLE team >>> >>> I love IDLE (so simple and lightweight compared with other IDEs) and was >>> just wondering if you could add the following code into pyshell.py and >>> pyshell.pyw >>> >> >> There is, currently, no pyshell.pyw. pyshell.py is run however IDLE is >> started. >> (as I have done on mine) because, as you will be able to tell, it sets >> DPI awareness (and on my set-up makes the text a lot clearer) >> >> On my wide-screen monitor attached to a video card, using white on dark. >> I would not say 'a lot' clearer, but the text is noticeably clearer, box >> lines are sharper, white and some colors are brighter, and some characters >> are better formed. After comparing IDLE without and with the patch to >> Command Prompt, using the same font and nearly the same size, I conclude >> that Command Prompt has dpi awareness turned on. >> >> import ctypes >>> try: ctypes.windll.shcore.SetProcessDpiAwareness (True) >>> except: pass >>> >> >> Thank you. I like it. I opened >> https://bugs.python.org/issue33656 >> > > Fixed merged in time for 3.6.6rc1 and 3.7.0rc1, so it should be in the > final release of both. > > > > -- > Terry Jan Reedy > > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev > -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at markroseman.com Wed Jun 20 15:16:50 2018 From: mark at markroseman.com (Mark Roseman) Date: Wed, 20 Jun 2018 12:16:50 -0700 Subject: [Idle-dev] contributing and versions Message-ID: <2B18E8B1-A91F-43BF-BBB2-466296A23B02@markroseman.com> I was glad to see the change to require Tk 8.5 (i.e. assume ttk). I took a quick peek at head and there are some easily fixable things that look bad on MacOS (e.g. adding ttk widgets directly to a toplevel without an intervening ttk frame). I would be happy to address some of those little things, as well as possibly revive some of the earlier GUI changes I?d started on previously but never had the cycles to push through to completion (on top of compatibility with multiple python and tk versions plus the switchover to git!) Hopefully simple question, what python/idle version(s) are ok with ttk-only code? Are all of those open to feature change/additions, or are some bugfix only? Thanks Mark From tjreedy at udel.edu Thu Jun 21 15:28:17 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 21 Jun 2018 15:28:17 -0400 Subject: [Idle-dev] contributing and versions In-Reply-To: <2B18E8B1-A91F-43BF-BBB2-466296A23B02@markroseman.com> References: <2B18E8B1-A91F-43BF-BBB2-466296A23B02@markroseman.com> Message-ID: On 6/20/2018 3:16 PM, Mark Roseman wrote: Welcome back to IDLE. Our collaboration during Fall, 2015, between 3.5.0 and 3.5.1 was quite productive. Besides me, there are currently two other current IDLE contributors. Cheryl Sabella has been extremely helpful since May 2017. Tal Einat, who start with IDLE over a decade ago, and who also has commit privileges, became active again about month ago. > I was glad to see the change to require Tk 8.5 (i.e. assume ttk). I took a quick peek at head and there are some easily fixable things that look bad on MacOS (e.g. adding ttk widgets directly to a toplevel without an intervening ttk frame). > > I would be happy to address some of those little things, as well as possibly revive some of the earlier GUI changes I?d started on previously but never had the cycles to push through to completion (on top of compatibility with multiple python and tk versions plus the switchover to git!) > > Hopefully simple question, what python/idle version(s) are ok with ttk-only code? Are all of those open to feature change/additions, or are some bugfix only? Here is an overall status report. Python versions: 3.6.6 will be out soon. Two more maintenance releases, 3.6.7 and 3.6.8 are scheduled for September and December. After that, 3.6 will join 3.5 (and 3.4) in only getting security fixes. 2.7 mostly gets security and build fixes and only occasional bug fixes. Backports: Because IDLE is exempt from the normal backport rules (PEP 434), all patches, currently, are backported from master (3.8 alpha) to 3.7.? to 3.6.?. This is easy because the requirement for Tk 8.5, the use of ttk, and the idlelib name changes all began in 3.6 and because, except in a couple of places, idlelib is the same in all 3 versions. Backporting everything keeps them the same, which keeps backporting easy. Backporting to 3.6 will stop with 3.6.8rc1, unless an emergency fix is needed before 3.6.8. Except for possible 'emergency' fixes, I am no longer patching IDLE on 2.7. Tracker, Git, and idle-dev: I hope you have read the appropriate sections of the revised devguide. The migration from Hg to Git has made applying a patch to multiple versions harder. But it has improved collaboration, I think. The strategy for fixing an issue should be discussed on the tracker. Particular patches should be discussed on the PR. Broad IDLE development issue can be discussed here, as we are doing. Tk versions: The Windows installer has included 8.6.x since at least 3.5. 3.7 includes 3.6.8. For MacOS, the 64-/32-bit installer for 3.6 requires 8.5, and users have to download 8.5.18 from ActiveState to avoid the buggy Apple versions. For 3.6.5+, there is a 64-bit-only installer that comes with 8.6.8. For 3.7, both installers come with 8.6.8. For Linux, people have whatever they have, but I presume 8.6 should be available everywhere and be fairly standard. The only 'new in 8.6' note in the tkinter doc is about .png support. I sometimes worry that we might unknowingly make 8.6 a requirement. Is there much of anything new, as opposed to bug fixes, in 8.6? I have read that 8.7, now in alpha, has a rewritten Text widget, and that there might be some minor incompatibilities. When tkinter supports 8.7, IDLE should also. I have also read that tk 9.0 should support full unicode. That would be great for tkinter and IDLE. Beginners, especially, like to play around with astral characters. Testing: I just finished reviewing and revising the test suite. This included adding a minimal test for each implementation module. I am getting increasingly strict about requiring test coverage of modified and new code. Tkinter import style: I have settled on from tkinter import Tk, Text, ... from ttk import Button, ... If all the widget creation calls are covered by tests, missing items are quickly apparent. Ttk conversion: This is partly done and I would like to complete at least a sensible minimum before we are done with 3.6. Patches making the remaining replacements would be welcome. If imports are first made explicit as above, switching mostly amounts to moving an item from one line to the other. Switching to or adding ttk frames elsewhere should also be fine. (I presume tk widgets in a ttk frame do fine.) D We need to separate windows and frames anyway, to make IDLE a tabbed application, and the frames should be a separate subclass. See the revised textview module. We are not yet using custom ttk styles, and I do not consider that part of the minimum. Tabbed windows: Separating Textview into a window and a frame that is now on the window but could later be put on a tab was a first step. I would like to have something for 3.8, after 3.6 is finished. We can consider whether to backport to 3.7 when we need to. In the meanwhile, there are lots of patches to review. GUI changes: As I remember, I was not enthusiastic about some of your proposals, as they seemed overly complicated, predicated on supporting tk-only 8.4, or more appropriate for your website example. These will take more discussion. -- Terry Jan Reedy