From ether.joe at gmail.com Sat Jul 25 00:22:35 2015 From: ether.joe at gmail.com (Sean Felipe Wolfe) Date: Fri, 24 Jul 2015 15:22:35 -0700 Subject: [Idle-dev] put idle on github? Message-ID: Hello IDLE-ers, I'm considering putting a copy of the idle code on github, to leverage the excellent tools that platform provides and be able to incorporate various fixes that have been discussed but not implemented in the standard distribution as of yet. The Python GPL license is pretty simple and from my reading, grants the ability to do this as long as I include a copyright notice. A few questions then: a) does anybody think it's illegal to do ? b) would it help make idle improvements easier to access ? c) is there a better platform, ie. launchpad or bitbucket? I have used bitbucket for pygame, and although the toolset isn't as easy to use, maybe it makes sense. I'm curious to hear what you all think about this. -- 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 From guido at python.org Sat Jul 25 21:09:02 2015 From: guido at python.org (Guido van Rossum) Date: Sat, 25 Jul 2015 21:09:02 +0200 Subject: [Idle-dev] put idle on github? In-Reply-To: References: Message-ID: The PSF license indeed allows this. (Note that "Python GPL license" is incorrect usage -- the PSF license is most definitely not the GPL -- that's "Gnu Public License", a totally different license.) GitHub is a fine platform for this. Note that you're effectively forking IDLE this way -- it may not be easy to get the changes that you applied here accepted back into the CPython repo, because of backward compatibility concerns (it's easy to apply a change that breaks on some platform you've never heard of, or for some user whose workflow is different than yours -- see also https://xkcd.com/1172/). Personally, I think it's fine to fork IDLE, and I think eventually it should be removed from the stdlib -- but this is controversial, as educators often are forced to rely on the IDLE that is bundled with the Python installer. But that's a longer discussion. On Sat, Jul 25, 2015 at 12:22 AM, Sean Felipe Wolfe wrote: > Hello IDLE-ers, > > I'm considering putting a copy of the idle code on github, to leverage > the excellent tools that platform provides and be able to incorporate > various fixes that have been discussed but not implemented in the > standard distribution as of yet. > > The Python GPL license is pretty simple and from my reading, grants > the ability to do this as long as I include a copyright notice. > > A few questions then: > a) does anybody think it's illegal to do ? > b) would it help make idle improvements easier to access ? > c) is there a better platform, ie. launchpad or bitbucket? > > I have used bitbucket for pygame, and although the toolset isn't as > easy to use, maybe it makes sense. > > I'm curious to hear what you all think about this. > > -- > 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 > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ether.joe at gmail.com Sat Jul 25 21:34:42 2015 From: ether.joe at gmail.com (Sean Felipe Wolfe) Date: Sat, 25 Jul 2015 12:34:42 -0700 Subject: [Idle-dev] put idle on github? In-Reply-To: References: Message-ID: Awesome thanks for your response Mr. BDFL. I am actually using this in an educational context at a community center here in Oakland. So it's a case where education wants the fork, haha. And I'm hoping that some of our young programmers are future Python core developers :) Cheers !! On Sat, Jul 25, 2015 at 12:09 PM, Guido van Rossum wrote: > The PSF license indeed allows this. (Note that "Python GPL license" is > incorrect usage -- the PSF license is most definitely not the GPL -- that's > "Gnu Public License", a totally different license.) GitHub is a fine > platform for this. > > Note that you're effectively forking IDLE this way -- it may not be easy to > get the changes that you applied here accepted back into the CPython repo, > because of backward compatibility concerns (it's easy to apply a change that > breaks on some platform you've never heard of, or for some user whose > workflow is different than yours -- see also https://xkcd.com/1172/). > Personally, I think it's fine to fork IDLE, and I think eventually it should > be removed from the stdlib -- but this is controversial, as educators often > are forced to rely on the IDLE that is bundled with the Python installer. > But that's a longer discussion. > > On Sat, Jul 25, 2015 at 12:22 AM, Sean Felipe Wolfe > wrote: >> >> Hello IDLE-ers, >> >> I'm considering putting a copy of the idle code on github, to leverage >> the excellent tools that platform provides and be able to incorporate >> various fixes that have been discussed but not implemented in the >> standard distribution as of yet. >> >> The Python GPL license is pretty simple and from my reading, grants >> the ability to do this as long as I include a copyright notice. >> >> A few questions then: >> a) does anybody think it's illegal to do ? >> b) would it help make idle improvements easier to access ? >> c) is there a better platform, ie. launchpad or bitbucket? >> >> I have used bitbucket for pygame, and although the toolset isn't as >> easy to use, maybe it makes sense. >> >> I'm curious to hear what you all think about this. >> >> -- >> 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 >> _______________________________________________ >> IDLE-dev mailing list >> IDLE-dev at python.org >> https://mail.python.org/mailman/listinfo/idle-dev > > > > > -- > --Guido van Rossum (python.org/~guido) -- 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 From guido at python.org Sat Jul 25 21:36:23 2015 From: guido at python.org (Guido van Rossum) Date: Sat, 25 Jul 2015 21:36:23 +0200 Subject: [Idle-dev] put idle on github? In-Reply-To: References: Message-ID: Please post your project link here once you have it up and ready, and let us know how your changes to IDLE help your classes. Enjoy! On Sat, Jul 25, 2015 at 9:34 PM, Sean Felipe Wolfe wrote: > Awesome thanks for your response Mr. BDFL. > > I am actually using this in an educational context at a community > center here in Oakland. So it's a case where education wants the fork, > haha. And I'm hoping that some of our young programmers are future > Python core developers :) > > Cheers !! > > On Sat, Jul 25, 2015 at 12:09 PM, Guido van Rossum > wrote: > > The PSF license indeed allows this. (Note that "Python GPL license" is > > incorrect usage -- the PSF license is most definitely not the GPL -- > that's > > "Gnu Public License", a totally different license.) GitHub is a fine > > platform for this. > > > > Note that you're effectively forking IDLE this way -- it may not be easy > to > > get the changes that you applied here accepted back into the CPython > repo, > > because of backward compatibility concerns (it's easy to apply a change > that > > breaks on some platform you've never heard of, or for some user whose > > workflow is different than yours -- see also https://xkcd.com/1172/). > > Personally, I think it's fine to fork IDLE, and I think eventually it > should > > be removed from the stdlib -- but this is controversial, as educators > often > > are forced to rely on the IDLE that is bundled with the Python installer. > > But that's a longer discussion. > > > > On Sat, Jul 25, 2015 at 12:22 AM, Sean Felipe Wolfe > > > wrote: > >> > >> Hello IDLE-ers, > >> > >> I'm considering putting a copy of the idle code on github, to leverage > >> the excellent tools that platform provides and be able to incorporate > >> various fixes that have been discussed but not implemented in the > >> standard distribution as of yet. > >> > >> The Python GPL license is pretty simple and from my reading, grants > >> the ability to do this as long as I include a copyright notice. > >> > >> A few questions then: > >> a) does anybody think it's illegal to do ? > >> b) would it help make idle improvements easier to access ? > >> c) is there a better platform, ie. launchpad or bitbucket? > >> > >> I have used bitbucket for pygame, and although the toolset isn't as > >> easy to use, maybe it makes sense. > >> > >> I'm curious to hear what you all think about this. > >> > >> -- > >> 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 > >> _______________________________________________ > >> IDLE-dev mailing list > >> IDLE-dev at python.org > >> https://mail.python.org/mailman/listinfo/idle-dev > > > > > > > > > > -- > > --Guido van Rossum (python.org/~guido) > > > > -- > 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 > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Mon Jul 27 02:34:12 2015 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 26 Jul 2015 20:34:12 -0400 Subject: [Idle-dev] put idle on github? In-Reply-To: References: Message-ID: On 7/24/2015 6:22 PM, Sean Felipe Wolfe wrote: > Hello IDLE-ers, > > I'm considering putting a copy of the idle code on github, to leverage > the excellent tools that platform provides and be able to incorporate > various fixes that have been discussed but not implemented in the > standard distribution as of yet. There are two competing proposals to revamp the CPython development process. One, I believe, is to move everything to git (and, I guess) github). The other is to integrate more tools on our own servers. I believe better integration with git(hub) would also be included with the latter. Brett Cannon is in charge of consulting with devs and making a decision, but he has been delayed due to moving. > A few questions then: > b) would it help make idle improvements easier to access ? There is already a mirror on github that can be used to access any current repository files, including Idlelib. > c) is there a better platform, ie. launchpad or bitbucket? I think launchpad is out of the running. Some would prefer bitbucket to stay with hg. -- Terry Jan Reedy From mark at markroseman.com Thu Jul 16 00:24:31 2015 From: mark at markroseman.com (Mark Roseman) Date: Wed, 15 Jul 2015 15:24:31 -0700 Subject: [Idle-dev] IDLE and ttk Message-ID: <1B27006E-9615-4F1C-BBF7-2D7799A4E646@markroseman.com> I just joined this list, and would like to reopen the subject of migrating some of the ?old school? tkinter user interface elements to use ttk. From browsing the list archives, I see this was last substantially discussed in 2010, and several people over time have done some hacking in this direction, though nothing that has ever made it into IDLE. Part of the issue then appeared to be contributer/maintainer time constraints? is this still the case now? I have a good chunk of time to do some work on this, and would be quite interested in taking it on, if there?s enough confidence that changes could be accepted at this point in time. To be a bit more specific, the priorities would be: (1) updating the widgets, (2) reworking layout/spacing (using grid) to be more consistent with platform expectations, (3) replacing homegrown megawidgets like tabbed pages and tree widget with ttk built-ins, and (4) minor adjustments to user interface to improve usability and/or similarity to other modern programs. For the latter, I?m referring to very localized improvements that reflect and respect the background and expectations of the target user base, not big changes in structure or scope. Just as an introduction, I?m the author of the tkdocs.com site, and the accompanying ?Modern Tkinter for Busy Python Programmers? book (and yes, I think a ?case study? chapter describing what it took to migrate from old to new would be a great addition to the book). From mark at markroseman.com Tue Jul 28 20:28:08 2015 From: mark at markroseman.com (Mark Roseman) Date: Tue, 28 Jul 2015 11:28:08 -0700 Subject: [Idle-dev] IDLE and ttk In-Reply-To: <1B27006E-9615-4F1C-BBF7-2D7799A4E646@markroseman.com> References: <1B27006E-9615-4F1C-BBF7-2D7799A4E646@markroseman.com> Message-ID: <6647FA3F-F8FA-40C2-8C60-78488BEA2F1F@markroseman.com> A quick followup to my own post (had problems posting to the mailing list, now fixed)? in the interim have had a brief interchange with Terry on the topic; he reassured me now is probably a good time to try to do this work and get it integrated in. As Terry pointed out to me, the bulk of the core functionality in IDLE is actually modifications to the text widget, which wouldn't change. When it comes to cross-platform apps, there is always a tension between making things consistent with the platform you're running on, vs. making things consistent for those moving between platforms. Given that most advanced Python developers use other tools most of the time, the consensus seems to be that IDLE is most used by (a) people, often non-programmers, being exposed to or learning about Python, and only very secondarily (b) Python developers who might fire up IDLE when moving their existing code to another platform. This does suggest to me that making IDLE as unobtrusive as possible (i.e. emphasizing fitting in with platform expectations) would be more important, so new learners can focus on Python. As long as the overall structure of the user interface doesn't change between platforms, most experienced developers will be able to accomplish what they need on a new box. So the main goal would be making IDLE look and feel, to a far greater extent than currently, like it just fits in. A secondary goal would be to make future improvements and maintenance to IDLE easier (which several of the types of changes I'm proposing would address). Everything would be tested on recent versions of Mac, Windows and Linux, and I anticipate backporting to 2.7 as well. I'll hold off on bringing up any specifics at this time, as I'm sure everyone has their favorite bugaboo (many of which made it into the bug database), but I'm looking for any initial comments to the general idea. From interstar at gmail.com Tue Jul 28 23:07:58 2015 From: interstar at gmail.com (phil jones) Date: Tue, 28 Jul 2015 18:07:58 -0300 Subject: [Idle-dev] IDLE and ttk In-Reply-To: <6647FA3F-F8FA-40C2-8C60-78488BEA2F1F@markroseman.com> References: <1B27006E-9615-4F1C-BBF7-2D7799A4E646@markroseman.com> <6647FA3F-F8FA-40C2-8C60-78488BEA2F1F@markroseman.com> Message-ID: One question would be is the new Tk you talk about on your site the one which is now bundled with the standard Python distro? And is that what Tkinter now talks to by default? Phil On 28 July 2015 at 15:28, Mark Roseman wrote: > A quick followup to my own post (had problems posting to the mailing list, > now fixed)? in the interim have had a brief interchange with Terry on the > topic; he reassured me now is probably a good time to try to do this work > and get it integrated in. > > As Terry pointed out to me, the bulk of the core functionality in IDLE is > actually modifications to the text widget, which wouldn't change. > > When it comes to cross-platform apps, there is always a tension between > making things consistent with the platform you're running on, vs. making > things consistent for those moving between platforms. > > Given that most advanced Python developers use other tools most of the > time, the consensus seems to be that IDLE is most used by (a) people, often > non-programmers, being exposed to or learning about Python, and only very > secondarily (b) Python developers who might fire up IDLE when moving their > existing code to another platform. > > This does suggest to me that making IDLE as unobtrusive as possible (i.e. > emphasizing fitting in with platform expectations) would be more important, > so new learners can focus on Python. As long as the overall structure of > the user interface doesn't change between platforms, most experienced > developers will be able to accomplish what they need on a new box. > > So the main goal would be making IDLE look and feel, to a far greater > extent than currently, like it just fits in. A secondary goal would be to > make future improvements and maintenance to IDLE easier (which several of > the types of changes I'm proposing would address). Everything would be > tested on recent versions of Mac, Windows and Linux, and I anticipate > backporting to 2.7 as well. > > I'll hold off on bringing up any specifics at this time, as I'm sure > everyone has their favorite bugaboo (many of which made it into the bug > database), but I'm looking for any initial comments to the general idea. > > > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at markroseman.com Wed Jul 29 00:03:40 2015 From: mark at markroseman.com (Mark Roseman) Date: Tue, 28 Jul 2015 15:03:40 -0700 Subject: [Idle-dev] IDLE and ttk In-Reply-To: References: <1B27006E-9615-4F1C-BBF7-2D7799A4E646@markroseman.com> <6647FA3F-F8FA-40C2-8C60-78488BEA2F1F@markroseman.com> Message-ID: On Jul 28, 2015, at 2:07 PM, phil jones wrote: > One question would be is the new Tk you talk about on your site the one which is now bundled with the standard Python distro? And is that what Tkinter now talks to by default? It?s not so new (Tk 8.5.0 was released in 2007). The standard Python Windows distribution comes with Tcl/Tk 8.6.1, Mac doesn?t include it (need to install ActiveTcl separately), and the source tarball doesn?t include it. I don?t know of any recent Linux distros that don?t package 8.5.x or 8.6.x with their Python/tkinter packages. Tkinter talks to (I believe) 8.4.x and up. Mark From tjreedy at udel.edu Wed Jul 29 00:12:06 2015 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 28 Jul 2015 18:12:06 -0400 Subject: [Idle-dev] IDLE and ttk In-Reply-To: <1B27006E-9615-4F1C-BBF7-2D7799A4E646@markroseman.com> References: <1B27006E-9615-4F1C-BBF7-2D7799A4E646@markroseman.com> Message-ID: On 7/15/2015 6:24 PM, Mark Roseman wrote: As the date above shows, this somehow got hung up in the mailman machinery until Mark wrote the list owners and someone got it released. In the meanwhile, Mark sent this to me directly, and I already responded. But I will summarize and revise what I wrote back. > I just joined this list, and would like to reopen the subject of > migrating some of the ?old school? tkinter user interface elements to > use ttk. This subject was dormant, waiting the right time for reactivation, which, with your offer, I think is now. > From browsing the list archives, I see this was last substantially > discussed in 2010, and several people over time have done some > hacking in this direction, though nothing that has ever made it into > IDLE. Part of the issue then appeared to be contributer/maintainer > time constraints? is this still the case now? A combination of time, tests, priorities, knowledge, and back-compatibility. Time: Mark is offering that. Tests: a year ago, I and a GSOC student set up a human-test framework as a complement to automated unittests. It makes it much easier to check appearance changes as well as do manual testing of hard-to-automate (or not-yet-automated) behavior checks. Priorities: the worst crash issues, and some other bugs, have been fixed since 2010. While some behavior bugs remain, appearance can also detracts from usability. As noted below, some ttk additions will make behavior changes easier. Knowledge: Mark has that, and I know enough now (but not a year ago) to review work he does. Back-compatibility: We do not know how much the private idlelib APIs are used, and if so which. Refactoring files, upgrading to PEP8 standards (which is best done when a file is worked on and tested for other reasons) and upgrading to ttk widgets could all break compatibility. So for dialogs, I would add new PEP8-compliant, grid and ttk-based files and mark the old ones deprecated (with a warning on import), to be removed in 3.6. > I have a good chunk of time to do some work on this, and would be > quite interested in taking it on, if there?s enough confidence that > changes could be accepted at this point in time. Unless someone has a convincing reason not to, I would like to go ahead with this. > To be a bit more specific, the priorities would be: > (1) updating the widgets, This mostly means replacing the widgets in dialogs. > (2) reworking layout/spacing (using grid) to be more consistent with platform expectations, This is somewhat separate issue but I agree that .grid is easier to work with than the older .pack (which Idle currently uses). > (3) replacing homegrown megawidgets like tabbed pages and tree widget with ttk built-ins, and Until I patched it last Fall, TreeWidget, used for the path and module browsers, did not work right on Windows and it is still a bit flakey. Using the more capable and polished ttk.Treeview should make upgrading the browsers much easier. > (4) minor adjustments to user interface to improve usability and/or > similarity to other modern programs. For the latter, I?m referring to > very localized improvements that reflect and respect the background > and expectations of the target user base, not big changes in > structure or scope. Marks tutorial http://www.tkdocs.com/tutorial/index.html gives parallel ttk widget examples for Mac, Windows, and Linux. I presume these use the default theme for each platform. The Button example is at http://www.tkdocs.com/tutorial/widgets.html#button > Just as an introduction, I?m the author of the tkdocs.com site, and > the accompanying ?Modern Tkinter for Busy Python Programmers? book > (and yes, I think a ?case study? chapter describing what it took to > migrate from old to new would be a great addition to the book). What Mark did not say is that he has used tk for over 2 decades and started the site nearly a decade ago. -- Terry Jan Reedy From tjreedy at udel.edu Wed Jul 29 00:27:57 2015 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 28 Jul 2015 18:27:57 -0400 Subject: [Idle-dev] IDLE and ttk In-Reply-To: References: <1B27006E-9615-4F1C-BBF7-2D7799A4E646@markroseman.com> <6647FA3F-F8FA-40C2-8C60-78488BEA2F1F@markroseman.com> Message-ID: On 7/28/2015 6:03 PM, Mark Roseman wrote: > On Jul 28, 2015, at 2:07 PM, phil jones wrote: >> One question would be is the new Tk you talk about on your site the >> one which is now bundled with the standard Python distro? And is >> that what Tkinter now talks to by default? An appropriate question. It was discussed and decided a few years ago on the pydev list that it would be reasonable for Idle to use ttk and thus require tcl/tk 8.5. > It?s not so new (Tk 8.5.0 was released in 2007). The tile extension was available for 8.4. A revised version was included with 8.5. This was similar to a pypi package being revised and pulled into the stdlib. > The standard Python Windows distribution comes with Tcl/Tk 8.6.1, Upgraded to 8.6.4 for 3.5. > Mac doesn?t include it (need to install ActiveTcl separately), The recommended separate install if one uses the PSF Mac installer is AS 8.5.19 or so. There is another Mac Python distribution compiled to work with 8.6.something. Ned Deily would like to eventually do the same with the PSF Mac distribution. > I don?t know of any recent Linux distros that > don?t package 8.5.x or 8.6.x with their Python/tkinter packages. > Tkinter talks to (I believe) 8.4.x and up. Support for earlier versions was removed a year or so ago. -- Terry Jan Reedy From tjreedy at udel.edu Wed Jul 29 01:00:48 2015 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 28 Jul 2015 19:00:48 -0400 Subject: [Idle-dev] IDLE and ttk In-Reply-To: <6647FA3F-F8FA-40C2-8C60-78488BEA2F1F@markroseman.com> References: <1B27006E-9615-4F1C-BBF7-2D7799A4E646@markroseman.com> <6647FA3F-F8FA-40C2-8C60-78488BEA2F1F@markroseman.com> Message-ID: On 7/28/2015 2:28 PM, Mark Roseman wrote: > As Terry pointed out to me, the bulk of the core functionality in > IDLE is actually modifications to the text widget, which wouldn't > change. There are no ttk (themed tk) versions of Tk, Toplevel, Menu, Text, or Canvas. The only change to Shell/Editor/OutputWindow would be the scrollbars, to make them better match the platform standard. > When it comes to cross-platform apps, there is always a tension > between making things consistent with the platform you're running on, > vs. making things consistent for those moving between platforms. After looking at the side-by-side examples on your site, this is no longer a worry for me. We already, by necessity, customize the menus and keybindings for Mac, and users can further customized keybindings, fonts, and text colors (and other things). I would want styles and themes set up so users can select among those available (mac theme on windows?) and add their own customized versions. > So the main goal would be making IDLE look and feel, to a far greater > extent than currently, like it just fits in. As the default, I think this would be fine. > A secondary goal would > be to make future improvements and maintenance to IDLE easier (which > several of the types of changes I'm proposing would address). > Everything would be tested on recent versions of Mac, Windows and > Linux, and I anticipate backporting to 2.7 as well. This is the important part for me, and it *will* impact others. > I'll hold off on bringing up any specifics at this time, as I'm sure > everyone has their favorite bugaboo (many of which made it into the > bug database), but I'm looking for any initial comments to the > general idea. There will be multiple tracker issues for this project, and if there is interest here, I will announce them here for people who do not follow new issues on the tracker. -- Terry Jan Reedy From al at inventwithpython.com Wed Jul 29 00:35:33 2015 From: al at inventwithpython.com (Al Sweigart) Date: Tue, 28 Jul 2015 15:35:33 -0700 Subject: [Idle-dev] IDLE and ttk In-Reply-To: References: <1B27006E-9615-4F1C-BBF7-2D7799A4E646@markroseman.com> <6647FA3F-F8FA-40C2-8C60-78488BEA2F1F@markroseman.com> Message-ID: I really encourage some updates for IDLE, thanks for your offer. Definitely check out the README in the idle_test folder, and forward any hiccups you encounter to the list so that we can document them for future contributors. On Tue, Jul 28, 2015 at 3:03 PM, Mark Roseman wrote: > On Jul 28, 2015, at 2:07 PM, phil jones wrote: >> One question would be is the new Tk you talk about on your site the one which is now bundled with the standard Python distro? And is that what Tkinter now talks to by default? > > > It?s not so new (Tk 8.5.0 was released in 2007). The standard Python Windows distribution comes with Tcl/Tk 8.6.1, Mac doesn?t include it (need to install ActiveTcl separately), and the source tarball doesn?t include it. I don?t know of any recent Linux distros that don?t package 8.5.x or 8.6.x with their Python/tkinter packages. Tkinter talks to (I believe) 8.4.x and up. > > Mark > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev From tjreedy at udel.edu Thu Jul 30 05:34:25 2015 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 29 Jul 2015 23:34:25 -0400 Subject: [Idle-dev] Last call for tear-off menus Message-ID: Several people would like to eliminate Idle's use of tk tear-off menus. They probably confuse and annoy far more people than they help. If anyone want to speak up for them, do it now. http://bugs.python.org/issue13884 -- Terry Jan Reedy From tjreedy at udel.edu Thu Jul 30 23:08:37 2015 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 30 Jul 2015 17:08:37 -0400 Subject: [Idle-dev] Last call for tear-off menus In-Reply-To: References: Message-ID: On 7/29/2015 11:34 PM, Terry Reedy wrote: > Several people would like to eliminate Idle's use of tk tear-off menus. > They probably confuse and annoy far more people than they help. > If anyone want to speak up for them, do it now. > http://bugs.python.org/issue13884 Now gone. -- Terry Jan Reedy From al at inventwithpython.com Thu Jul 30 23:12:03 2015 From: al at inventwithpython.com (Al Sweigart) Date: Thu, 30 Jul 2015 17:12:03 -0400 Subject: [Idle-dev] Last call for tear-off menus In-Reply-To: References: Message-ID: Woo hoo! This was a weird feature and not-too-useful feature that I wanted to see gone. Thanks! On Thu, Jul 30, 2015 at 5:08 PM, Terry Reedy wrote: > On 7/29/2015 11:34 PM, Terry Reedy wrote: >> >> Several people would like to eliminate Idle's use of tk tear-off menus. >> They probably confuse and annoy far more people than they help. >> If anyone want to speak up for them, do it now. >> http://bugs.python.org/issue13884 > > > Now gone. > > > -- > Terry Jan Reedy > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev