[issue42560] Improve Tkinter Documentation
Mark Roseman added the comment: Just a note, that an (updated) version of the auto-generated API reference has been "officially" added to TkDocs ... see https://tkdocs.com/pyref/ Few more things I'd like to do with it in the short term, but it's a decent starting point. Let me know if you have further suggestions. -- ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Mark Roseman added the comment: Would like to throw an idea out for feedback regarding the API reference. I've done some preliminary work auto-generating documentation via widget introspection. It's missing a lot, has many bugs, but is far enough along to give a sense of what this approach could offer. Temporary snapshot is at https://tkdocs.com/tmp-pyref/ (you may need to force-refresh if your browser cached the site's stylesheet). Note that generating .rst files this way shouldn't be much of a stretch so as to fully integrate into the official Python docs. Thoughts? -- ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7057] tkinter doc: more 3.x updates
Mark Roseman added the comment: yes this should be closed.. with latest doc updates, most of these are no longer at all relevant -- nosy: +markroseman ___ Python tracker <https://bugs.python.org/issue7057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Mark Roseman added the comment: Łukasz, thank you very much for your help with getting these changes merged in! I hope others will chime in with suggestions and/or edits to the newer or substantially revised sections. There is most definitely lots of room for improvement. One specific request... does anyone have solid recommendations for other resources (including books, paid video courses, etc.) that extensively cover Tkinter and use current best practices (grid, ttk, etc.)? This would be for the "see also" section. While I think the two free tutorial/reference resources on tkdocs.com make the most sense, I'm a bit queasy about the self-promotion optics of also highlighting Modern Tkinter as prominently as it is now in the books section. That still leaves the "handy reference" section to deal with, which currently consists of a mish-mash of material. When I have a chance, I'll work on a PR with a list of classes and common methods (but not arguments or explanations) as suggested before. While the pieces that were already merged in were probably low on the controversy scale, it's still unclear what the right way forward is with the actual reference part and I expect some more discussion on that. -- ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Change by Mark Roseman : -- pull_requests: +26306 pull_request: https://github.com/python/cpython/pull/27842 ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Change by Mark Roseman : -- pull_requests: +26304 pull_request: https://github.com/python/cpython/pull/27840 ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Change by Mark Roseman : -- pull_requests: +26303 pull_request: https://github.com/python/cpython/pull/27839 ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Change by Mark Roseman : -- pull_requests: +26302 pull_request: https://github.com/python/cpython/pull/27838 ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Change by Mark Roseman : -- pull_requests: +26300 pull_request: https://github.com/python/cpython/pull/27836 ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Change by Mark Roseman : -- pull_requests: +26299 pull_request: https://github.com/python/cpython/pull/27835 ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Mark Roseman added the comment: Łukasz, I've got a bunch of individual branches for each of those sections. What I posted the link to was a merge of all of them just for overview purposes, but the PR's will be created from the individual branches. I can start creating those now or wait a bit, whatever is easiest workflow-wise. -- ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Mark Roseman added the comment: I would most definitely echo the concern about the massive size of such a project as well as future maintainability. I don't know anyone who would be able to do such a thing on a volunteer basis, and I think it would be highly unlikely that anyone would step up to pay someone to do it. I imagine we all agree that we would love to have such a complete reference, but I have a hard time seeing how it's even remotely feasible. As the effort supporting Tcl/Tk core development is fairly small, and most of the people involved are far more interested in the Tcl side of things rather than Tk, the odds of huge changes on the Tk front are small, beyond keeping it working, fixing bugs, and the odd little isolated burst of new stuff once in a while. Based on previous history with that community, I think you can safely assume any licensing issues won't be an impediment to whatever needs to be done on this end, though I'm sure there are details to sort out. -- ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Mark Roseman added the comment: Here's a very rough work-in-progress snapshot: https://github.com/roseman/cpython/blob/tkinter-docs-snapshot-20210815/Doc/library/tkinter.rst This includes: 1. Changes I'd mentioned to the intro, external resources, modules, architecture 2. Rewrite of the 'life preserver' mini-tutorial section using a very different approach. 3. A start on the reference section (replacing the random bits that were there with a categorized, but detail-free list of classes and common methods). Anyone have any big picture thoughts at this point? -- ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Change by Mark Roseman : -- nosy: +lukasz.langa, terry.reedy ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Mark Roseman added the comment: Here are my broad suggestions for improvement (each of these would turn into a separate PR). Thoughts for/against each? 1. 'See also' section: use this to guide people to what they need. update to point out challenge of finding material given age etc., clearer what to use each resource for, update as needed (e.g. later editions of books) 2. Tkinter modules section: add ttk up front (i.e. usually use tkinter and tkinter.ttk), fill in a couple missing ones, move import/Tk() to later section (example or ref) 3. Architecture (was recently added). Merge in (and improve) material from how Tk and Tkinter are related, drop Tix from here 4. Replace life preserver with: 4a. Updated hello world example: use ttk and grid, explain each call 4b. How to introspect (figure out commands, arguments, and options... some of this is e.g. now in the reference section) so when don't have exact docs on something can figure out how to find answers 4c. Bridge from Tcl/Tk documentation: rewrite of 'quick look' and 'mapping' sections, more a list of how key concepts are realized in Tkinter, such as widget hierarchy. Less example based, more factual/reference oriented. 5. 'Handy reference' section: drop most of what's there now, replace with lists of classes (e.g. widgets), general methods available on all widgets (grid, bind, winfo*, etc.), organized into categories. Likely without (most) arguments or options, or descriptions. There have been a few starts on this including the PR that Mason did here. -- ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Mark Roseman added the comment: I was having a peek at the main tkinter doc page again and would like to take a broader crack at it. I think most of what is there now (life preserver/reference) needs to be substantially reworked or trimmed. I think exhaustive description of all methods etc. is unrealistic given the magnitude of the job and variation between versions, but it seems reasonable that the doc page would help identify what tkinter API to use, how to find out what it's parameters and options are (interactively), and if needed how to figure out the corresponding Tcl command so things can be looked up in the Tcl/Tk docs and in general map from Tcl to Python. Ultimately, if the tkinter docs can get people started and point them to the right places to learn more (including things like the TkDocs tutorial or Shipman ref, the Tcl/Tk man pages) I'd call it a win. Right now it's a big muddle, and one that too easily becomes out-of-date. -- nosy: +markroseman ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33479] Document tkinter and threads
Change by Mark Roseman : -- pull_requests: +26200 pull_request: https://github.com/python/cpython/pull/27717 ___ Python tracker <https://bugs.python.org/issue33479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44243] tkinter button colors on Mac
Mark Roseman added the comment: Let it go. Changing the Python docs to a behaviour that isn't guaranteed by the underlying library is a virtual guarantee that a later version of Tk (or even the way the API it uses behaves on another version of macOS) will have some other (unrelated) modifications that change the current behaviour to something else. -- ___ Python tracker <https://bugs.python.org/issue44243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43504] Site linked in docs, effbot.org, down
Mark Roseman added the comment: I'd argue for removing the links altogether, given the material is very outdated and from what I recall anything that was there is better covered now by TkDocs, Shipman, or other resources. -- ___ Python tracker <https://bugs.python.org/issue43504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14111] IDLE Debugger should handle interrupts
Mark Roseman added the comment: Terry, I agree that Ctrl-C should act just as an interrupt when the debugger is active. I also agree that a way to interrupt the debugger through the user interface is needed (in the revised UI, there's an explicit 'stop' button for that). -- ___ Python tracker <https://bugs.python.org/issue14111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33962] IDLE: use ttk.spinbox with configdialog
Mark Roseman added the comment: Just as a side note for Terry and anyone else testing on macOS... the recent updates in Tk have smoothed out many of the appearance issues for the classic widgets. See the attached screen shot tkversions.png comparing 8.6.9 with the current trunk of the Tk repo. Notice things like the background color around the optionmenu aren't as jarring on the newer Tk versions. Having said that, I'll likely stick with the older ones for development purposes, just because the blemishes with the classic widgets and other things are so much more noticeable! Incidentally, if you've got several versions of Tcl/Tk on your system, you can use /usr/bin/install_name_tool to point the Tkinter shared library at the one you want to use. Use like "install_name_tool -change OLD NEW file", e.g.: install_name_tool -change /Library/Frameworks/Tk.framework/Versions/8.6/Tk /Users/roseman/tmp/tcl86core/Library/Frameworks/Tk.framework/Versions/8.6/Tk build/lib.macosx-10.15-x86_64-3.10/_tkinter.cpython-310-darwin.so -- Added file: https://bugs.python.org/file49540/tkversions.png ___ Python tracker <https://bugs.python.org/issue33962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33962] IDLE: use ttk.spinbox with configdialog
Mark Roseman added the comment: Whoops, sorry... there's a "readonly" state flag that disables direct editing of the entry (like with combobox) and just allows manipulation of the arrows. I've updated the PR to set that. I've also changed it so that the contents of the entry part isn't selected whenever the arrows are used (agreed, it looks ugly). Please give it a try and let me know. p.s. I just checked, the entry's width configuration option works. You just have to remove the "fill=X" when the widget is packed. FWIW, I kept the previous layout to keep the patch as minimal as possible, under the assumption that other layout changes (here, on in general) were planned. -- ___ Python tracker <https://bugs.python.org/issue33962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33962] IDLE: use ttk.spinbox with configdialog
Change by Mark Roseman : -- keywords: +patch pull_requests: +21872 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/22954 ___ Python tracker <https://bugs.python.org/issue33962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17942] IDLE Debugger: Improve GUI
Change by Mark Roseman : -- versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue17942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17942] IDLE Debugger: Improve GUI
Mark Roseman added the comment: have updated/cleaned up the previous patch, and there's a new PR. i realize this is unfortunately a somewhat monolithic change which might make reviewing it a bit tough... -- ___ Python tracker <https://bugs.python.org/issue17942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17942] IDLE Debugger: Improve GUI
Change by Mark Roseman : -- pull_requests: +21864 pull_request: https://github.com/python/cpython/pull/22947 ___ Python tracker <https://bugs.python.org/issue17942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33987] IDLE: use ttk.Frame for ttk widgets
Change by Mark Roseman : -- pull_requests: +21861 pull_request: https://github.com/python/cpython/pull/22943 ___ Python tracker <https://bugs.python.org/issue33987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33987] IDLE: use ttk.Frame for ttk widgets
Change by Mark Roseman : -- pull_requests: +21860 pull_request: https://github.com/python/cpython/pull/22942 ___ Python tracker <https://bugs.python.org/issue33987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33987] IDLE: use ttk.Frame for ttk widgets
Change by Mark Roseman : -- pull_requests: +21859 pull_request: https://github.com/python/cpython/pull/22941 ___ Python tracker <https://bugs.python.org/issue33987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41434] IDLE: Option to warn user on "Run Module" if file is not Python source
Mark Roseman added the comment: I like Terry's idea of providing a better error message than just "invalid syntax" when we run something that likely isn't a Python file. There doesn't seem to be any great danger in trying to run any file that would justify a warning beforehand. -- nosy: +markroseman ___ Python tracker <https://bugs.python.org/issue41434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33051] IDLE: Create new tab for editor options in configdialog
Change by Mark Roseman : -- nosy: +markroseman ___ Python tracker <https://bugs.python.org/issue33051> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34976] IDLE: Replace the search dialog with a search bar
Mark Roseman added the comment:
Tal, I gave it a try, I think this is great. For "simple" searches (i.e. what
people do most of the time), a search bar is a lot less klunky than bringing up
a dialog.
Patch seems to work well, would just need a cosmetic update (ttk widgets etc.).
Things may get a bit complex for users if too many things are stuck in there,
and you run out of space real quick when you have a fairly narrow window.
My suggestion would be to keep it to just a simple search without options, and
keep the rest (search with options, replace) in a separate unified dialog that
merges the current "Search Dialog" and "Replace Dialog". A button ("...") in
the search bar to open that dialog would make for a nice transition between the
search bar and the dialog.
--
nosy: +markroseman
___
Python tracker
<https://bugs.python.org/issue34976>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27477] IDLE: Switch search dialogs to ttk widgets, and other refinement
Mark Roseman added the comment: Just noting that the current search dialogs (and others) do not have a ttk.Frame directly inside the toplevel which encloses all other widgets. They therefore still display the mismatched backgrounds on macOS. Given that, should #33987 be reopened? The patches seem to change the existing frames to the ttk equivalent, but don't add the new intervening frame. -- ___ Python tracker <https://bugs.python.org/issue27477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28694] tkinter interface to fontchooser
Mark Roseman added the comment: I've put together the first cut of a wrapper that tries to smooth over some of the non-essential differences in implementation details across platforms, while still respecting essential platform conventions. It also works around a few bugs I discovered along the way. It includes the wrapper class itself, a minimal demo, a more realistic demo, and the notes about current behaviour of the underlying Tk widget on different platforms. Current snapshot is at https://github.com/roseman/tkdocs/blob/fontchooser/fontchooser.py Obviously, this borrows hugely from previous snapshots by Lance and Elisha. Thanks! If you get a chance to try it out, would appreciate feedback if this is on the right track or not. -- ___ Python tracker <https://bugs.python.org/issue28694> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28694] tkinter interface to fontchooser
Mark Roseman added the comment: For future reference, if anyone is wondering why the font chooser is so complicated to use in a way that makes sense across platforms, here is its current behaviour... >From the manual: - configure -font is the font currently shown or font shown when dialog is initially shown (neither guaranteed on all platforms) - implementation-dependent which actions result in callback being called and event being sent Windows - modal; show blocks until dismissed, cannot interact with other windows - ok/cancel - apply button added if a command option is specified - with command (apply button present) - if apply: callback generated with font currently set in dialog, event generated [configure -font is NOT updated] - if ok: callback generated with font in dialog, dialog closed, event generated, configure -font not updated - if no command (no apply button) - on ok, get event, configure -font not updated (correct, since dialog not visible) - fontchange event not generated if option is set in code X11 - not modal; show returns immediately, can interact with other windows - ok/cancel - apply button added if a command option is specified - with command (apply button present): - if apply: callback generated with font currently set in dialog, event generated [configure -font is NOT updated) - if ok: callback generated with font in dialog, dialog closed; no event, configure -font NOT updated - with no command (no apply button): - no event generated, configure -font NOT updated - fontchnaged event generated if option is set in code, configure -font updated - configure -font never updated by user interaction - conclusion: need to set command, hold onto current value returned macOS - no ok/cancel buttons, works like a palette - non-modal; show returns immediately, can interact with other windows - BUG:can appear when tk first loaded (sometimes..) - happens when left open on previous launches and program exited abnormally e.g. ctl-C in terminal - ~/Library/Saved Application State/com.tcltk.wish.savedState/windows.plist still holds font chooser - if so, -visible initially is false, but is true after idle... no intervening <> event - will segfault if set options e.g. font - workaround: hide on startup - fontchange event generated on every change in dialog, configure -font updated to font in dialog - fontchange event generated when option set in code, configure -font updated to font in dialog - command callback (if specified) invoked on every change from user (not in code), configure -font updated -- ___ Python tracker <https://bugs.python.org/issue28694> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28694] tkinter interface to fontchooser
Mark Roseman added the comment: Elaine, I was just having a look at this the other day too! I agree, this is definitely worth some effort to get done. To be honest, I'm not a fan of the vwait solution to force the dialog to be modal. It doesn't actually make it modal (i.e. you can still do stuff in other windows). Moreover, the Mac version (which is native, so couldn't easily be made modal via Tkinter) has a very different design than on other platforms. It doesn't have "ok", "apply", "cancel" buttons or similar. It's designed to just hang around. When the font dialog was originally proposed for Tk (see http://tip.tcl.tk/324) they'd tried a modal API first and found it unworkable. In light of that, my preference for the official wrapper would be to mirror the underlying API, as per what Lance's version first tried, using a callback mechanism to return results. Most importantly, it would eliminate the assumption that there's always a way to make it modal. Documentation would be key. Mind you, there's no official docs for the other dialogs. I can guarantee it would be well-documented with an example on TkDocs anyway! If there aren't any strong objections, I'm able to have a go at modifying Lance's version over the next week or so. I've got Mac, Windows, and Linux environments to test everything out. Question... I assume the official wrapper needs checks to ensure fontchooser is available (i.e. 8.6 or greater). If not, should the wrapper just error out? Would providing an alternative implementation for Tk < 8.6 be something that would be done in an external module, or might that be something that could/should be included in the official library? -- ___ Python tracker <https://bugs.python.org/issue28694> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28694] tkinter interface to fontchooser
Change by Mark Roseman : -- nosy: +markroseman ___ Python tracker <https://bugs.python.org/issue28694> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39107] Upgrade tcl/tk to 8.6.10 (Windows and maxOS)
Change by Mark Roseman : -- nosy: +markroseman ___ Python tracker <https://bugs.python.org/issue39107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37149] link to John Shipman's Tkinter 8.5 documentation fails: website no longer available
Change by Mark Roseman : -- pull_requests: +21249 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/22188 ___ Python tracker <https://bugs.python.org/issue37149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37149] link to John Shipman's Tkinter 8.5 documentation fails: website no longer available
Mark Roseman added the comment: I've posted a copy at https://tkdocs.com/shipman/ I've lightly modified it to add a site header and explanation of where the material comes from and caveats about age to each page, and have removed or crossed out dead links, requests for feedback, etc. I agree with Terry's assessment of the copyright issues. While I don't expect anyone with a valid claim to contact me about the mirrored copy, I'd be happy to address any concerns if they do arise. If this all seems okay, I would very greatly appreciate if someone could update the links in the Python documentation for all the relevant branches and shepherd that through the approval process. -- ___ Python tracker <https://bugs.python.org/issue37149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37149] link to John Shipman's Tkinter 8.5 documentation fails: website no longer available
Mark Roseman added the comment: Hello, also (very) late to this party. If this would be useful, and unless anyone has any objections, I'd be open to hosting a copy of John's material on tkdocs.com. I'd add a header to each page explaining it's an unmaintained archive with all the usual caveats. That would at least provide a stable place to link to. -- ___ Python tracker <https://bugs.python.org/issue37149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33963] IDLE macosx: add tests.
Change by Mark Roseman : -- assignee: -> terry.reedy components: +IDLE nosy: +markroseman ___ Python tracker <https://bugs.python.org/issue33963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33987] need ttk.Frame inside Toplevel(s)
New submission from Mark Roseman : When adding a bunch of ttk widgets into a toplevel window, there needs to be an intervening ttk.Frame to ensure the background of the widgets matches the overall background. The reason is the 'toplevel' is part of the classic tk widgets and not ttk, so it isn't guaranteed to have the same background. In practice, the only platform where the toplevel and ttk.Frame have different backgrounds is macOS. Check out topframe.png for an example, top is without the intervening ttk.Frame, bottom adds it in. (Adding bug mainly so we have a place to store a concrete example of what this looks like) -- assignee: terry.reedy components: IDLE files: topframe.png messages: 320646 nosy: markroseman, terry.reedy priority: normal severity: normal status: open title: need ttk.Frame inside Toplevel(s) type: enhancement versions: Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file47655/topframe.png ___ Python tracker <https://bugs.python.org/issue33987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27755] Retire DynOptionMenu with a ttk Combobox
Change by Mark Roseman : -- pull_requests: +7590 ___ Python tracker <https://bugs.python.org/issue27755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17496] OS X test for Tk availability in runtktests.py doesn't work
Mark Roseman added the comment: Just to note, this remains a PITA. To run gui tests on macOS from a terminal window seems to require commenting out the SetFrontProcess() call. A better replacement is needed as noted in the previous discussion, as well this call was deprecated in OS X 10.9 (though has not yet been removed as of this writing). In the interim, is there a precedent for adding another command line option to the 'test' module, e.g. '--forcemacgui' so that people who want to can run those tests from a clean checkout? -- nosy: +markroseman versions: +Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue17496> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33962] IDLE: use ttk.spinbox
Mark Roseman added the comment: For now, using a (likely very minimal) subset of commands/options common to both classic and ttk spinbox versions in IDLE sounds good. I was originally thinking stick with "-textvariable" for setting (which works on both) but I like your idea of adding "set" to a tk.spinbox subclass. -- ___ Python tracker <https://bugs.python.org/issue33962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27755] Retire DynOptionMenu with a ttk Combobox
Mark Roseman added the comment: Given the difference between the old and new (ttk) spinbox, especially on macOS, I'd like to incorporate it into IDLE when available. See screenshot spinbox.png, noting white border around old one. Terry, can we add a spinbox wrapper to IDLE for the time being? If so, would you prefer it done as its own (very little) module? Or is there any value to adding a module to hold various small UI wrappers and convenience procs? -- Added file: https://bugs.python.org/file47652/spinbox.png ___ Python tracker <https://bugs.python.org/issue27755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33924] In IDLE menudefs, change 'windows' to 'window'
Change by Mark Roseman : -- pull_requests: +7526 ___ Python tracker <https://bugs.python.org/issue33924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33479] Document tkinter and threads
Change by Mark Roseman : -- pull_requests: +6913 ___ Python tracker <https://bugs.python.org/issue33479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33479] Document tkinter and threads
Mark Roseman added the comment: I've made some changes to what Ivan started, which you can find here: https://github.com/roseman/cpython/tree/tkinter_docs The first two commits are minor updates/improvements not really related to threading, and I suspect are uncontroversial. The last commit rewrites the thread model section. The main focus is on how things work in practice, and to eliminate what I previously referred to as "fighting" between the two models. It explains how Python and Tcl differ on threads, the mappings between threads and interpreters, etc. It plays down the comparison to other GUI toolkit event models. It still highlights the difference for people familiar with them. It doesn't try to teach both models for those who don't know either (which includes those who may not have done much if any GUI programming) since that is extraneous to their present needs. It talks simply about why event handlers blocking is a bad thing. It avoids what I think are unnecessary details about Tcl in this context. There is then an area for special cases that highlight the various actual trouble spots when it comes to threads, what can cause them, and how to avoid them. I hope this covers the real issues without overly complicating things. Any thoughts? -- ___ Python tracker <https://bugs.python.org/issue33479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33479] Document tkinter and threads
Mark Roseman added the comment: Ivan, thanks for making a good first pass of this. The thread section still feels a lot like 'fighting' with the model. Do you mind if I take a crack at it? Won't get to it for a few days, but in case you have any stuff you're in the middle of. I should clarify too that Tk apps almost universally do use a blocking event loop (i.e. 'vwait forever' at the end of a script). Application-level event handlers are supposed to respond quickly so control goes back to the event loop. It's when control doesn't return there that things like the 'update idletasks' hacks are needed. In practice, I've noticed that's what seems to trip people up when they first start, as they try to emulate the flow of their non-GUI code, which frequently blocks. Far better that the program is restructured so that the event handler completes quickly. It's actually worse than it looks, because you can end up having nested event loops if you start randomly throwing this stuff in. That's conceptually hard for most people and a good source of bugs. -- ___ Python tracker <https://bugs.python.org/issue33479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33479] Document tkinter and threads
Mark Roseman <m...@markroseman.com> added the comment:
Hi Ivan, thanks for your detailed response. The approach you're suggesting
("Since the sole offender is their threading model, the way is to show them how
it's defective and work towards improving it.") is in the end not something I
think is workable.
Some historical context. Ousterhout had some specific ideas about how Tcl/Tk
should be used, and that was well-reflected in his early control of the code
base. He was certainly outspoken against threads. The main argument is that
they're complicated if you don't know what you're doing, which included the
"non-professional programmers" he considered the core audience. Enumerating how
threads were used at the time, most of the uses could be handled (more simply)
in other ways, such as event-driven and non-blocking timers and I/O (so what
people today would refer to as the "node.js event model"). Threads (or separate
communicating processes) were for long-running computations, things he always
envisioned happening in C code (written by more "professional programmers"),
not Tcl. His idea of how Tcl and C development would be split didn't match
reality given faster machines, more memory, etc.
The second thing is that Tcl had multiple interpreters baked in pretty much
from the beginning at the C level and exposed fairly early on (1996?) at the
Tcl level, akin to PEP 554. Code isolation and resource management were the key
motivators, but of course others followed. Creating and using Tcl interpreters
was quick, lightweight (fast startup, low memory overhead, etc.) and easy. So
in other words, the notion of multiple interpreters in Tcl vs. Python is
completely different. I had one large application I built around that time that
often ended up with hundreds of interpreters running.
Which brings me to threads and how they were added to the language. Your guess
("My guess for the decision is it was the easiest way to migrate the code
base") is incorrect. The idea of "one thread/one interpreter" was just not seen
as a restriction, and was a very natural extension of what had come before. It
fit the use cases well (AOLserver was another good example) and was still very
understandable from the user level. Contrast with Python's GIL, etc.
With that all said, there would be very little motivation to change the Tcl/Tk
side to allow multiple threads to access one interpreter, because in terms of
the API and programming model that Tcl/Tk advertises, it's simply not a
problem. Keep in mind, the people working on the Tcl/Tk core are very smart
programmers, know threads very well, etc., so it's not an issue of "they should
know better" or "it's old." In other words, "show them how it's defective" is a
non-starter.
The other, more practical matter in pushing for changes in the Tcl/Tk core, is
that there are a fairly small number of people working on it, very part-time.
Almost all of them are most interested in the Tcl side, not Tk. Changes made in
Tk most often amount to bug fixes because someone's running into something in
their own work. Expecting large-scale changes to happen to Tk without some way
to get dedicated new resources put into it is not realistic.
A final matter on the practical side. As you've carefully noted, certain Tcl/Tk
calls now happen to work when called from different threads. Consider those a
side-effect of present implementation, not a guarantee. Future core changes
could change what can be called from different threads, making the situation
better or worse. From the Tcl/Tk perspective, this is not a problem, and would
not be caught by any testing, etc. Even if it were, it likely wouldn't be
fixed. It would be considered an "abuse" of their API (I think correctly).
My suggestion, given the philosophical and practical mismatch, is that Tkinter
move towards operating as if the API Tk provides is inviolate. In other words,
all calls into a Tcl interpreter happen from the same thread that created the
Tcl interpreter. Tkinter acts as a bridge between Python and Tcl/Tk. It should
present an API to Python programs compatible with the Python threading model.
It's Tkinter's responsibility to map that onto Tcl/Tk's single threaded API
through whatever internal mechanism is necessary (i.e. pass everything to main
thread, block caller thread until get response, etc.)
I'd go so far as to suggest that all the Tkapp 'call' code (i.e. every place
that Tkinter calls Tcl_Eval) check what thread it's in, and issue a warning or
error (at least for testing purposes) if it's being called from the "wrong"
thread. Having this available in the near future would help people who are
debugging what are fairly inexplicable problems now.
The approach of making Tkinter responsible also has the advantage of dealing
with far more Tcl/Tk versions an
[issue33479] Document tkinter and threads
Mark Roseman <m...@markroseman.com> added the comment: This seems very complicated. The official line on threads for Tk has always been to make all Tk calls from one thread, which is at least predictable and comprehensible. Is there any reason for Tkinter to suggest anything different? This ignores the compilation issue of course. FYI, the Tcl core group will probably eliminate the possibility of doing non-threaded builds in the future, though with backwards compatibility issues, that's neither here nor there. -- nosy: +markroseman ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27755] Retire DynOptionMenu with a ttk Combobox
Mark Roseman added the comment: Cheryl, regarding the spinbox, as per http://www.tkdocs.com/tutorial/morewidgets.html#spinbox, the ttk version appeared in Tk 8.5.9, which might explain it's absence in tkinter. A wrapper isn't too hard to do of course... e.g. https://stackoverflow.com/questions/30783603/create-new-ttk-widget-from-tkinter -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9262] IDLE: Use tabbed shell and edit windows
Mark Roseman added the comment: The ttk Notebook wouldn't be appropriate as it doesn't scale beyond a small (generally fixed) number of tabs, and is missing UI to easily add/delete tabs. There's some discussion of this in earlier comments here. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17942] IDLE Debugger: Improve GUI
Changes by Mark Roseman <m...@markroseman.com>: -- pull_requests: +2510 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24813] Redesign Help => About IDLE, make it non-modal
Mark Roseman added the comment: FYI, just added a trivial pull request to change the tagline in the about dialog to 'integrated development and learning environment'. It's showing up as from python-dev as I hadn't (yet) added my github name to my bpo prefs. Got to start somewhere! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17942] IDLE Debugger: Improve GUI
Mark Roseman added the comment: Please go ahead with any of the patches I submitted earlier, credit is absolutely not an issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27755] Retire DynOptionMenu with a ttk Combobox
Mark Roseman added the comment: Justin, as you say, I think your patch is entirely reasonable as an interim step, as eventually doing a broader improvement on the preferences dialog as suggested in #24781 makes sense. My reworked version used Combobox in similar ways; I think we can safely do away with the wrapper class and just use the ttk widget directly in the dialog (as the widget already handles the dynamic changes to the list, which the old tk_optionMenu didn't) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27621] Finish IDLE Query dialog appearance and behavior.
Mark Roseman added the comment: Looks great Terry - thanks. Only nit is that test_click_help_source fails on Mac, courtesy a leading 'file://' added in the last few lines of path_ok -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15786] IDLE code completion window can hang or misbehave with mouse
Mark Roseman added the comment: I've done some playing around... not quite there yet, but I think much closer. First, I assume the 'freeze' on Mac is not a hard freeze, but where the text window is not responding to events, but if you switch to another app and back, it works again? Second, right now (assuming I've got the latest), if you click on the listbox it goes away immediately, due to it being included in HIDE_SEQUENCES (meaning ButtonPress generates <> which calls the routine to hide the autocomplete window. Which obscures any double click event etc. Third, and I think this is the key to this, is that all of the event_add, event_delete, bind, and unbind are not calling Tkinter routines directly, but are going through the multicall module (which allows an event to fire more than one binding). When we call hide_window, we're doing several event_delete and unbind calls in multicall to undo the bindings we had set up before. Which should leave us back where we started, with the text widget bindings still firing when events come in. So then is it an issue of the events not coming in (indicating a bug in Tkinter or how we're calling it), or multicall not correctly dispatching to the text widget? Stick a print() call in multicall.py:_ComplexBinder:__create_handler:handler and you'll see the events are being generated by Tk, but multicall isn't dispatching them. When I get a chance again, I can see about digging into multicall to verify if it is doing something wrong. I'll also raise a meta-issue, and that is that using a multicall-like wrapper approach may not necessarily be the best approach to doing the multiple dispatch. Adding a new (Tk widget) class to the text widget (via the 'bindtags' command) and then attaching bindings to that class would I suspect be simpler. And finally, one simplification for the autocomplete window class... the listbox generates a <> virtual event every time its selection changes, so you don't need to bind against all the clicks, arrow keys, etc. -- nosy: +markroseman ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27621] Finish IDLE Query dialog appearance and behavior.
Mark Roseman added the comment: Thanks Terry! I'd be good if you want to put a width back on the buttons, but I'd suggest "width=6" rather than using 8 as it was before. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27477] IDLE: Switch search dialogs to ttk widgets, and other refinement
Mark Roseman added the comment: Have attached search.diff, which does an initial bit of cosmetics: adds inner frame with spacing, tweaks a couple labels, and for Mac and X11, puts the command buttons at the bottom of the dialog rather than on the right (where they remain on Windows). -- Added file: http://bugs.python.org/file43968/search.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27621] Finish IDLE Query dialog appearance and behavior.
Mark Roseman added the comment: I've attached query.patch, which does the cosmetic and layout changes, and adds a couple Mac-specific things. I've added the inline error message widget but don't use it yet (as this will involve changes to the subclasses and the tests, given errors will show up when the dialog is running, not after). Given I'm a bit rusty at this, would appreciate if someone could check this out and make sure I did things correctly. :-) -- Added file: http://bugs.python.org/file43966/query.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27621] Finish IDLE Query dialog appearance and behavior.
Mark Roseman added the comment: Just to follow up, both Windows and Linux the 'correct' behaviour seems to be that space or return activates the button with the current focus. Mac behaves differently in that return key always activates default button even if focus is on another button (and normally on Mac, buttons don't get focus). I'll put together a patch that cleans up the layout and does the error label in dialog thing. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27621] Finish IDLE Query dialog appearance and behavior.
Mark Roseman added the comment: Serhiy, the tk_dialog has been superseded by tk_messageBox, and does not reflect current platform standards. I just tried tk_messageBox on the Mac, which always activates the default button if you press 'return', even if another button has the focus. I expect Windows and X11 are different, and will check that out when I get a chance. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27477] IDLE: Switch dialogs to ttk widgets.
Mark Roseman added the comment: Great start. Needs to have a ttk.Frame directly inside the toplevel window to avoid whitespace showing around grey widgets (like in query dialog shot). I'd also like to see the spacing adjusted (all platforms) and button positions changed on Mac to go at the bottom, as per http://www.tkdocs.com/tutorial/idle.html#idledialogs Open to a patch that does that? -- nosy: +markroseman ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27621] Finish IDLE Query dialog appearance and behavior.
Mark Roseman added the comment: Terry, thanks for the TkDocs correction. As you'll note from the attached dlgonmac.png, there's a bit of tweaking needed with regard to geometry management etc. to get the background right. Now that ttk is ok (so to speak), would you be open to some patches that fix this up, a bit more akin to what you see in the 'query dialog' subsection if you scroll down a bit in http://www.tkdocs.com/tutorial/idle.html#idledialogs Separately, would you be open to a patch changing things to use the "inline" error handling illustrated on the goto line dialog on that page (i.e. showing error message in query dialog in red vs. popping up an alert)? Older code for that can be found here btw: https://github.com/roseman/idle/blob/master/querydialog.py -- Added file: http://bugs.python.org/file43940/dlgonmac.png ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27621] incorrectly works in IDLE Query dialogs
Mark Roseman added the comment: Side note that on Mac OS X, buttons normally don't get the focus, so that this isn't an issue. Well except that buttons are getting the focus here. :-) Also since we're reinventing the wheel, please note that alternative keyboard shortcuts (e.g. command-period) don't work, and there isn't a default button set for the dialog which there should be. Interestingly, you can change things in System Preferences -> Keyboard -> Shortcuts so that buttons can get the focus via tabbing through the interface. If this is enabled and you tab to the Cancel button and his Return, it should still be treated as if you hit the Okay button on Mac. Hitting space while focus is on the Cancel button does treat it as if you clicked on Cancel. -- nosy: +markroseman ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27024] IDLE shutdown glitch when started by import
Mark Roseman added the comment: tried this patch on 3.6 as per terry's previous msg; still getting same error in idle test suite on os x -- nosy: +markroseman ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail
Mark Roseman added the comment: This (restructuring/refactoring to minimize the subprocess imports) does definitely sound like the right approach. There will be other benefits to breaking up PyShell a bit too.. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25507> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8231] Unable to run IDLE without write-access to home directory
Mark Roseman added the comment: Better, but alas still not quite. On further investigation, the issue is that a new instance of idleConf is instantiated in the subprocess, which then calls mkdtemp() returning a different name. You can see this by doing 'restart shell' and noting that it will hit the warning you added in GetUserCfgDir. There are multiple places that the subprocess does access preferences, so just eliminating them is probably not the right way to go. I'd probably recommend that the user prefs dir be communicated to the subprocess somehow. Two suggestions are via adding a command line parameter where we launch the subprocess (build_subprocess_arglist), or have the subprocess get it via 'remotecall' when it starts up (perhaps in MyHandler.handle). Either way this would then need to be communicated to idleConf so it uses that directory. Would there be a preference and/or any other alternatives? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25514] better startup error messages in IDLE when stdlib modules shadowed
New submission from Mark Roseman:
When we create e.g. string.py that shadows a stdlib module needed by IDLE, it
would be nice if a better error message could be shown, pointing to that cause.
Original message:
lac at smartwheels:~/junk$ echo "print ('hello there')" >string.py
lac at smartwheels:~/junk$ idle-python3.5
hello there
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/idlelib/run.py", line 10, in
from idlelib import CallTips
File "/usr/lib/python3.5/idlelib/CallTips.py", line 16, in
from idlelib.HyperParser import HyperParser
File "/usr/lib/python3.5/idlelib/HyperParser.py", line 14, in
_ASCII_ID_CHARS = frozenset(string.ascii_letters + string.digits + "_")
AttributeError: module 'string' has no attribute 'ascii_letters'
IDLE then produces a popup that says:
IDLE's subprocess didn't make connection. Either IDLE can't stat a subprocess
por personal firewall software is blocking the connection.
I think that life would be a whole lot easier for people if instead we got
a message:
Warning: local file /u/lac/junk/string.py shadows module named string in the
Standard Library
I think that it is python exec that would have to do this -- though of
course the popup could also warn about shadowing in general, instead of
sending people on wild goose chases over their firewalls.
--
Laura, I think what you want should actually be more-or-less doable in IDLE.
The main routine that starts IDLE should be able to detect if it starts
correctly (something unlikely to happen if a significant stdlib module is
shadowed), watch for an attribute error of that form and try to determine if
shadowing is the cause, and if so, reissue a saner error message.
The subprocess/firewall error is occurring because the ‘string’ problem in your
example isn’t being hit right away so a few startup things already are
happening. The point where we’re showing that error (as a result of a timeout)
should be able to check as per the above that IDLE was able to start alright,
and if not, change or ignore the timeout error.
There’ll probably be some cases (depending on exactly what gets shadowed) that
may be difficult to get to work, but it should be able to handle most things.
See full thread starting at
https://mail.python.org/pipermail/python-dev/2015-October/142061.html
--
components: IDLE
messages: 253693
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: better startup error messages in IDLE when stdlib modules shadowed
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25514>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8231] Unable to run IDLE without write-access to home directory
Mark Roseman added the comment: Checked on Linux and Mac - doesn't work correctly. mkdtemp() returns a different name every time it's called, and GetUserCfgDir() is called in three places, meaning we end up with three different tmp directories (which on quick examination didn't all get cleaned up at end). I'd suggest changing it so that GetUserCfgDir() caches its result and returns the cached version on subsequent calls. Running out the door so don't have time to try this myself right now... -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24765] Move .idlerc to %APPDATA%\IDLE on Windows
Mark Roseman added the comment: Further to Terry's backwards compatibility issues (also discussed in #8231). Storing things in the "correct" location (%APPDATA% on Windows, and Application Support on OS X) would presumably be the "right" thing to do if backwards compatibility weren't an issue. If "APPDATA" is the "correct" place, and "HOME" is what we've been using now, consider a solution like this: - check if prefs exist in APPDATA; if so, use that - check if prefs exist in HOME; if so, use that - if neither, create prefs in APPDATA This handles the common cases of existing user upgrading to new scheme (things stay stored in old location), new user upgrading to newer versions in future (things go in new place), but fails on the case of user starts with new version and then later uses an older version (results in two separate preferences, one used by newer versions, one used by older). I think it's a legitimate question as to whether that latter case is common enough or problematic enough to worry about it (given "fails" doesn't break anything). -- nosy: +markroseman ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24765> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8231] Unable to run IDLE without write-access to home directory
Mark Roseman added the comment: Just a note that the 'store things in APPDATA' is issue #24765 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8231] Unable to run IDLE without write-access to home directory
Mark Roseman added the comment: Can I suggest that this issue continues to be about IDLE not being able to write its preferences directory/files due to permissions, and we create a new issue for the fact that IDLE is storing it in the wrong place under Windows? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25244] Idle: refine right-click behavior
Changes by Mark Roseman <m...@markroseman.com>: -- nosy: +markroseman ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24782] Merge 'configure extensions' into main IDLE config dialog
Mark Roseman added the comment: The extra width appears to be coming from the canvas inside VerticalScrolledFrame; the canvas gets the default size and the frame adjusts to fit its contents (the canvas and the scrollbar). If you really want to reduce the size, add a "-width" option where that canvas is being created. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25254] Idle: debugger source line highlighting fails again
Mark Roseman added the comment: FYI, the new debugger UI has an option to only show highlights in already open files (i.e. don't open new ones) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24782] Merge 'configure extensions' into main IDLE config dialog
Mark Roseman added the comment: No, I don't, sorry. If it will be quick for you to do, no problem, otherwise I'd be happy to put it together. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24782] Merge 'configure extensions' into main IDLE config dialog
Mark Roseman added the comment: Patch against head to change extensions dialog to a pane of main config dialog. -- Added file: http://bugs.python.org/file40761/mergeext.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24782] Merge 'configure extensions' into main IDLE config dialog
Mark Roseman added the comment: Same patch against 2.7 -- Added file: http://bugs.python.org/file40762/mergeext27.cfg ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present
Mark Roseman added the comment: Okay, that's reasonable enough for me. :-) I'd still be for nuking the warning so that nothing gets displayed unless you go looking in online help. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14576] IDLE: inconsistent use of HOMEDRIVE, HOMEPATH, and USERPROFILE on Windows
Changes by Mark Roseman <m...@markroseman.com>: -- nosy: +markroseman ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22726] Idle: add help to config dialogs
Mark Roseman added the comment: I'm not against online help, but I feel that what's there wouldn't be helpful to someone using IDLE. Once this would be extended to per-tab, what are the problem areas that people really need help with? Also keeping in mind we're going to be replacing this dialog (at least for people with tk > 8.4) in the not too distant future. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present
Mark Roseman added the comment: I see the 3.4.4 is not an immediate concern, so that's good. FYI, I get the (multiple) error messages on console consistently on Mac, but it probably depends how it was launched. Agree the code for future versions should do a better job to detect the theme isn't present and switch back to a default theme rather than just puking out error messages as it tries to get each element of the non-existent theme. :-) I still think the approach I took may be viable. It doesn't require changes to old versions, and relies on the fact that a user theme with the same name as a default theme is effectively hidden by the default theme. If a 'new' theme is selected, it's always written out to config-highlight, so it will be present for older versions (not errors and the internal default colors). Given that, I need help understanding what the 'name' vs. 'name2' etc. solution gives us? (Not being able to write .idlerc wouldn't be an issue, because then you wouldn't be able to write out the change to say that is the theme to use anyway). The only drawback I see is that a user running a previous version can customize IDLE Dark and those changes would not appear when using a newer versions of IDLE that had IDLE Dark as a default. This would negatively affect only those users who change to IDLE Dark, actually modify the theme, and switch back and forth between versions of IDLE. The consequences of this occurring are only that the changes don't show up. In other words, I feel this affects a very tiny number of people, in a relatively minor way. The existing warning on choosing themes will be encountered by anyone who might switch themes in the new version, and particularly for the non-hardcore, would be at the least surprising if not confusing or alarming. I think it's safe to assume that far more people try existing themes vs. create custom themes and use multiple versions of IDLE. Given the very minor consequences and how few people it would affect, vs. how many people would encounter that warning and the impression it would leave, this seems a case of I'd rather be unobtrusive and 98+% correct then obtrusive and 100% correct. If it were my product, there's no question I'd drop the warning under those circumstances, and if it were a choice between including the warning or not including a new theme, I'd personally choose to not include the new theme. Anyway, it seems we have time to think more about this... -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present
New submission from Mark Roseman: As a follow-on to #24820, when a particular theme is selected in the configuration files, but that theme is not available, IDLE will print out a bunch of warning messages on console. That can occur for example when using a newer built-in theme in an older version before that theme was added, or if the user highlight config file was modified or removed. IDLE should be smart enough to recognize that and switch to a default theme, without dumping out console error messages. May alert user to that case with an appropriate error message, e.g. theme xyz not found, using default. The current workaround in #24820 (when a newer theme is chosen in a new version, explain it may not work in older version but explain how it could be made to) is unfortunately necessary unless a more clever solution for this backwards compatibility issue can be found. Would apply to keysets, etc. in the same was as themes. -- components: IDLE messages: 252278 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE: gracefully handle themes (or keysets, or ...) not present type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present
Mark Roseman added the comment: Actually, I think we may be able to get away without the warning message when you select a 'new' theme, and still maintain backwards compatibility. For 'new' themes (i.e. IDLE Dark and any more builtins we add in the future), we write the theme out to the user configuration file, keeping the same name, and perhaps adding an extra field, i.e. 'builtin=1', so that we can recognize it in newer versions, along with a comment if possible. The existing code looks up theme names by checking if its in the default list, and if not, looks in the user list. For older versions without IDLE Dark, it will then find it in the user list. Besides writing out the theme to user config file, the only other change that would be needed in the code is to modify GetSectionList so that when it's looking in a user config file, it doesn't include sections that either have the builtin=1 from above, or just have the same name as things in the default file. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24820] IDLE themes for light on dark
Mark Roseman added the comment: FYI, the change multiple backgrounds thing is in my working version for the new dialog. Added new issue #25313 to remind us that the warning message is something we'd love to get rid of in the future and as quickly as possible make it unnecessary if we add more new themes and/or new features in themes. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present
Mark Roseman added the comment: Patch write-new-defaults.patch attached so that we write 'newer' default themes to config-highlight.cfg if selected, and ignore them if we already have a default by that name. -- keywords: +patch Added file: http://bugs.python.org/file40674/write-new-defaults.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24820] IDLE themes for light on dark
Mark Roseman added the comment: Hi Marc, you're correct that is an error in the theme. To correct it, change the setting for 'break-background' to be something like #22. Thanks! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24820] IDLE themes for light on dark
Mark Roseman added the comment: Attached a patch to the current config dialog to add breakpoint to the window, and have updated the same thing in my newer dialog. -- keywords: +patch Added file: http://bugs.python.org/file40635/breakpoint-prefs.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25254] Idle: debugger source line highlighting fails again
Mark Roseman added the comment: Was the 'source' checkbox in the debugger checked? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25224] Replace Idle's README.txt with annotated file list
Mark Roseman added the comment: Good start... would have been very helpful for me a couple of months back! Have attached a patch to your patch, breaking the main implementation into a few categories, and fixing a few typos. -- Added file: http://bugs.python.org/file40629/README2.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15663] Investigate providing Tcl/Tk 8.6 with OS X installers
Mark Roseman added the comment: Thanks Ned. A couple of things. First, you probably know about this, but for future reference in case it might be useful, the install_name_tool lets you point a shared library at a different dependent shared library than the one it was originally compiled to link against (see end of http://www.tkdocs.com/tutorial/fonts.html). This can be sometimes helpful in resolving compatibility issues. Secondly, we may want to consider adding something post-install (in IDLE?) where it would detect at least simpler cases of greatly out-of-date Tcl/Tk and offer to download and install a new one. If it were in IDLE, this would have the advantage of not affecting everyone who installs Python, but only (a subset of) those who would benefit. Plus, not being a "you must decide now" like an installer, it could be deferred if people weren't sure. And it would offer to provide a bit more active assistance rather than only "go read a web page". -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15663] Investigate providing Tcl/Tk 8.5 with OS X installers
Mark Roseman added the comment: Ned, is there anything that I might be able to help with here? While I'm not a Mac installer guru, it doesn't look like we'd need anything too fancy here. Installing an 8.6 variant (via the frameworks approach I mentioned in my previous message) would seem to have a less likely chance of stomping on things than previously, and hopefully shorten the time we have to live with 8.4 and buggy 8.5 releases. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16023] IDLE freezes on ^5 or ^6 (Un-)Tabify Region with OS X Cocoa Tk 8.5
Mark Roseman added the comment: Just tried and it seemed to work ok for me. I'm guessing it'll be a particular Tk version. Noting the timeline on the original bug report and subsequent comments, that was right when Tk 8.5 switched from Carbon to Cocoa, so it was probably something that got shaken out in later versions. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25198] Idle: improve idle.html help viewer.
Mark Roseman added the comment: Good catch about yview for text widgets! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24820] IDLE themes for light on dark
Mark Roseman added the comment: Sounds good. I agree picking a few and tweaking them would be a good way forward (and incidentally, the 'Cobalt' theme is the one I use in my regular editor!) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
