[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
[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
[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
[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
[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
[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
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'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
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: Ł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
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
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: +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: +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: +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: +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
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
[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: 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
[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
[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
[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
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
[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
[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
[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
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: 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
[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
[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
[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
[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
[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
[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: +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
[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
[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 : -- 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
[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
[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
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
[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 <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
Changes by Mark Roseman : -- pull_requests: +2510 ___ Python tracker <http://bugs.python.org/issue17942> ___ ___ 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 <http://bugs.python.org/issue9262> ___ ___ 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 <http://bugs.python.org/issue27755> ___ ___ 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 <http://bugs.python.org/issue17942> ___ ___ 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: 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 <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:
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
[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 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
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
[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
[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
[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
[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
[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
[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
[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
[issue6549] ttk.Style not translating some Tcl options
New submission from Mark Roseman :
Just a couple of minor things which this terminal session points out
s = ttk.Style()
s.element_options('Button.label')
('-compound', '-space', '-text', '-font', '-foreground', '-underline',
'-width', '-anchor', '-justify', '-wraplength', '-embossed', '-image',
'-stipple', '-background')
s.configure('TButton', font='helvetica 24')
{}
b = ttk.Button(root)
b.configure(text='blah')
The 'element_options' call presumably shouldn't include the dashes, i.e.
'compound' rather than '-compound'
The configure call shouldn't be returning anything, akin to how configuring
a button works.
Again, just little things..
--
components: Tkinter
messages: 90827
nosy: gpolo, markroseman
severity: normal
status: open
title: ttk.Style not translating some Tcl options
type: behavior
versions: Python 3.1
___
Python tracker
<http://bugs.python.org/issue6549>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://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 <http://bugs.python.org/issue27024> ___ ___ 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 <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: 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 <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 <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: 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 <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 <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: 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 <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 <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: 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 <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 <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: 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 <http://bugs.python.org/issue27621> ___ ___ 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 <http://bugs.python.org/issue27755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24745] Better default font for editor
New submission from Mark Roseman:
By default, IDLE chooses courier for the text editor font.
As you'll see from the attached screenshot, while this looks ok on Windows,
it's inconsistent with the standard fixed width fonts on Linux and OS X, and
borders on unreadable particularly on the latter.
While this can be changed via the configuration dialog (the 'fixed' versions in
the screenshots do just that), this is one of the things that really jumps out
at you the first time you run IDLE, and not in a good way.
Tk defines a font named 'TkFixedFont', which we should take advantage of
instead of hardcoding courier; details of the font can be retrieved via
tkinter.font.nametofont('TkFixedFont').actual()
Note there's a bit of an overlap here with #<20580>, but suggests that there
may be some cases where determining defaults programmatically rather than
hardcoding multiple defaults may be appropriate.
--
components: IDLE
files: defaultfont.png
messages: 247549
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: Better default font for editor
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file40048/defaultfont.png
___
Python tracker
<http://bugs.python.org/issue24745>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13884] IDLE: Remove tear-off menu feature
Mark Roseman added the comment: As indicated in prior comments, the tearoff menus are strictly a holdover from ancient Motif, and are no longer found in current user interfaces on any platform. Because of that, I would strongly support deleting them altogether, rather than making available a configuration option. I've updated Roger's patch for current 3.x tip (and also extended it to remove the reference to tearoff menus from the help file). -- nosy: +markroseman Added file: http://bugs.python.org/file40058/tearoff.patch ___ Python tracker <http://bugs.python.org/issue13884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13884] IDLE: Remove tear-off menu feature
Mark Roseman added the comment: Same changes for 2.7 branch -- Added file: http://bugs.python.org/file40059/tearoff27.patch ___ Python tracker <http://bugs.python.org/issue13884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24745] Better default font for editor
Mark Roseman added the comment: Quick question how best to represent this in the config-main.def file. My thought is to leave a "font=" line there so that the GetOption call returns an empty string. The editor code can then detect that and substitute TkFixedFont. Would this break anything and/or would there be a more preferred approach? -- ___ Python tracker <http://bugs.python.org/issue24745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24750] IDLE: Cosmetic improvements for main window
New submission from Mark Roseman: The screen shot shows the current version of the main IDLE window, with the little pics at the bottom indicating what it looks like when the window loses focus. A few entirely cosmetic changes I'd like to make here: 1. Swap scrollbar for ttk scrollbar; this visually will affect the Linux version. Note that even the ttk scrollbar is somewhat out-of-date with current desktops, but it's a step in the right direction! 2. You'll notice the slight border around the text widget when active; barely visible on Windows, a bit more so on Linux, and very much there on Mac (this is the "highlightthickness" attribute). Current conventions on all three platforms do away with this, so it should be removed for IDLE. 3. Regarding the items in the status bar, I'm going to suggest removing the sunken reliefs around the two items. Again, this was all the range long ago, but most apps on all platforms now have more minimal decorations in those contexts. If there were more (different) things on the status bar, I might suggest a light vertical separator between sections, but here there's no need for decoration at all. 4. Color and border on status bar. It's most apparent on the Mac inactive window pic, where the status bar blends in to the editor. I plan on tweaking the status bar so it's always a light grey color, and has a small darker separator above it. I may see about tweaking the font, as status bars tend to use a slightly smaller font nowadays. 5. Spacing for icon size grip on Mac should be removed for recent versions of OS X. This hasn't been necessary since before OS X Lion (released 2011). I can have the code include it when running on earlier versions of OS X. These are all tiny changes, but combined with a decent font make a big difference visually when IDLE first starts up. -- components: IDLE files: idle_main.png messages: 247627 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE: Cosmetic improvements for main window type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file40060/idle_main.png ___ Python tracker <http://bugs.python.org/issue24750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13884] IDLE: Remove tear-off menu feature
Mark Roseman added the comment: Doing it via the option database vs. on each menu would be my preferred approach. The option database is global, not per toplevel, so would cover everything. Only 'downside' is the whole its-not-an-application-its-a-library thing, though in the highly unlikely case someone was actually using idlelib this way, I'd consider setting that option a public service. There's no harm doing it the other way (and I was being polite since the previous patch was done that way), but it does very marginally increase maintainability difficulties (remembering to keep the option and add it to any future menus). Either way - please let's just make this change! :-) -- ___ Python tracker <http://bugs.python.org/issue13884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24745] Better default font for editor
Mark Roseman added the comment: I'm ok with putting TkFixedFont in the config file. Only potential downside I see is that the code will look for this specific value, but people may read the config file and assume it could be changed to any Tk*Font. I'd strongly argue against putting in a default button and/or including TkFixedFont in the list for the following reasons: 1. The config dialog should really be using the platform-specific font chooser for this anyway. (Tk 8.6 does include this dialog btw). The default dialogs don't allow anything like that, and I can't off the top of my head think of any common applications that allow you to revert back to a default. 2. I see no real advantage to being able to switch 'back' to a default. In fact, from the user perspective, there isn't conceptually a default font separate than whatever the 'actual' version of TkFixedFont is (courier, monaco, whatever). What they know is it starts with a certain font, and if they go into the dialog, it shows that font. If they change to a different font (or even back to the original font), that's what shows up next time they start the app. Is there actually a downside to writing out the per-user config file even if there isn't a "real" change in the font? -- ___ Python tracker <http://bugs.python.org/issue24745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24750] IDLE: Cosmetic improvements for main window
Mark Roseman added the comment: Sounds good. To clarify, (2) refers to not the overall window, but just around the text widget. Both regarding this and the comments regarding status bar (4), things look really good now on Windows. The changes I've made are barely perceptible there, but improve things a bit more on Linux, and way more on Mac. -- ___ Python tracker <http://bugs.python.org/issue24750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24759] Idle: require 8.5 / ttk
Mark Roseman added the comment: Sounds good. Only suggestion, given it's user facing, is to have the error message point them towards a solution. Off the top of my head, maybe something like "IDLE requires Python be configured to use Tk 8.5 or newer (you have Tk x.x)" with a title of "IDLE Cannot be Started" -- ___ Python tracker <http://bugs.python.org/issue24759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24750] IDLE: Cosmetic improvements for main window
Mark Roseman added the comment: The attached mainwin.patch implements these few small changes (except for removing the Mac grow box space); checked active/inactive on Mac, Windows, Linux. -- keywords: +patch Added file: http://bugs.python.org/file40070/mainwin.patch ___ Python tracker <http://bugs.python.org/issue24750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24750] IDLE: Cosmetic improvements for main window
Mark Roseman added the comment: Great. Sent in the contributor agreement Monday so I assume it should percolate through soon. -- ___ Python tracker <http://bugs.python.org/issue24750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24760] IDLE settings dialog shouldn't be modal
New submission from Mark Roseman: Is there any reason the IDLE settings dialog is modal? (Actually while it is modal on Windows and Linux, on OS X you can actually switch back to the main window while the settings dialog is up, but you can't actually type etc. into it!) While I could probably ask the same question about all the other modal dialogs, let's start here. :-) -- components: IDLE messages: 247707 nosy: markroseman, terry.reedy priority: normal severity: normal status: open title: IDLE settings dialog shouldn't be modal type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue24760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24750] IDLE: Cosmetic improvements for main window
Mark Roseman added the comment: The mainwin2.patch keeps the width of the fields constant. Thanks! -- Added file: http://bugs.python.org/file40071/mainwin2.patch ___ Python tracker <http://bugs.python.org/issue24750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24760] IDLE settings dialog shouldn't be modal
Mark Roseman added the comment: Ok, I'll do some playing around with that one over the next few days, and see if anything comes up. -- ___ Python tracker <http://bugs.python.org/issue24760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24750] IDLE: Cosmetic improvements for main window
Mark Roseman added the comment: I'll raise the practical matter that ActiveState no longer distributes 8.4.x as part of its Community edition ActiveTcl, though I presume it would be available as part of its for-fee Business version. Therefore if someone wants to use Python on 10.5, it would be with 8.4.7 (from 2005), pre-installed by Apple. The real difficulty is not so much a 10.5 vs. 10.6, but support for any PowerPC Macs, since 10.6 was the first version that was Intel only. The last PPC Macs were sold in 2006. FYI, the ActiveTcl 8.5.x Community edition are for 10.5+, but Intel only. Out of curiosity, are there download statistics? At some point, I'm sure it will make sense to stop distributing a pre-built Python that works on PPC/10.5; which doesn't of course preclude people from getting it working, or someone else creating a pre-built package hosted elsewhere. That's a discussion worth having of course, but somewhat larger than the matter here. My personal preference would be just making IDLE not work without ttk, i.e. it breaks if they don't otherwise get a PPC 8.5 Tcl/Tk compiled on their machine. I think Terry's suggestion of a 'frozen' IDLE might work on 2.7.x, but probably less so on 3.x. Not going ahead with the improvements (or keeping code for both 8.4 and 8.5+) doesn't seem like a sensible choice, given the benefits to a large audience. -- ___ Python tracker <http://bugs.python.org/issue24750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24750] IDLE: Cosmetic improvements for main window
Mark Roseman added the comment: Ned, quick question... if there is a tcl/tk 8.5.x on the system, will the 32 bit prebuilt distros link with it, or only with a 8.4.x version? -- ___ Python tracker <http://bugs.python.org/issue24750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24745] Better default font for editor
Mark Roseman added the comment: I've attached defaultfont.patch which will look for the magic value 'TkFixedFont' in the configuration file and do some appropriate magic with it. Most of the font handling smarts are now in a 'GetFont' call in configHandler, which as a bonus reduces some of the complexity and duplication elsewhere. -- keywords: +patch Added file: http://bugs.python.org/file40091/defaultfont.patch ___ Python tracker <http://bugs.python.org/issue24745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24750] IDLE: Cosmetic improvements for main window
Mark Roseman added the comment: Serhiy, I appreciate what you're saying, but special casing to handle both ttk and non-ttk cases seems not feasible given the amount of resources available to enhance/maintain IDLE. Additionally, part of the rationale for making these changes is to simplify the code by leveraging things in ttk that aren't in 'classic' Tkinter. Would you suggest: (a) keep two versions of the IDLE code in the distro (one a snapshot) (b) require 8.5 Tcl/Tk be installed on a system before IDLE can be used (c) leave IDLE with its current (embarrassing) UI (d) drop IDLE from Python altogether -- ___ Python tracker <http://bugs.python.org/issue24750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24759] Idle: require ttk (and tcl/tk 8.5)
Mark Roseman added the comment: Got it re: 2.7/3.4. So the only stumbling block left to 8.5/ttk in 3.5 would be the current Mac build that is ok with Tcl/Tk 8.4...? -- ___ Python tracker <http://bugs.python.org/issue24759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24776] Improve Fonts/Tabs UX for IDLE
Mark Roseman added the comment: What do you think of the layout in cfg_font_layout.png? (before/after) -- Added file: http://bugs.python.org/file40105/cfg_font_layout.png ___ Python tracker <http://bugs.python.org/issue24776> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs
Mark Roseman added the comment: For illustration, attached idle_find_ttk.png, which is a minor layout tweak of the existing one (works on all the various find dialogs, though not shown in screen shot). I agree with Al's other suggestions here. -- nosy: +markroseman Added file: http://bugs.python.org/file40107/idle_find_ttk.png ___ Python tracker <http://bugs.python.org/issue23218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24781] Improve UX of IDLE Highlighting configuration tab
New submission from Mark Roseman: Placeholder for improvements to the syntax highlighting tab in IDLE config dialog. I've attached cfg_highlight.png which shows a before and after I'm suggesting as a starting point. It would have the same functionality but uses a lot less pieces to implement it. Thoughts? -- components: IDLE files: cfg_highlight.png messages: 247897 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: Improve UX of IDLE Highlighting configuration tab type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40109/cfg_highlight.png ___ Python tracker <http://bugs.python.org/issue24781> ___ ___ 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
New submission from Mark Roseman: I'm wondering about moving the functionality of the 'configure extensions' dialog into the main configuration dialog. As I don't know the history here, I'm wondering why it was made separate. My proposal would be to add an 'Extensions' tab in the main config dialog. Along the left would be a listbox holding the names of each extension. Along the right would be options for the extension selected in the listbox (done pretty much the same as now). Selecting a different extension from the list would swap in the appropriate set of options. This would have the additional advantage of doing away with the stacked tabs. -- components: IDLE messages: 247898 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: Merge 'configure extensions' into main IDLE config dialog type: enhancement versions: Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue24782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24760] IDLE settings dialog shouldn't be modal
Mark Roseman added the comment: Incidentally (and this I would say is a definite bug) because the modal doesn't fully work on the Mac, you can actually create multiple copies of the config dialog! -- ___ Python tracker <http://bugs.python.org/issue24760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24750] IDLE: Cosmetic improvements for main window
Mark Roseman added the comment: While I think this approach would largely be a bad idea for an IDLE-sized application, where I think it definitely would be useful is in something very restricted like the tkSimpleDialog code. To improve the various little 'askstring', 'askinteger' etc. sprinkled throughout IDLE I had to do a copy/paste to change that code to use ttk widgets. Because that is an example of something very simple and self-contained, it could easily provide an option to do ttk or non-ttk widgets. Apologies if this is too off-topic. -- ___ Python tracker <http://bugs.python.org/issue24750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24781] Improve UX of IDLE Highlighting configuration tab
Mark Roseman added the comment: One of the other options I was playing with previously was a listbox for choosing the theme (what I'd suspect is the main user activity here). -- Added file: http://bugs.python.org/file40110/cfg_highlight_alt.png ___ Python tracker <http://bugs.python.org/issue24781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24781] Improve UX of IDLE Highlighting configuration tab
Mark Roseman added the comment: cfg_highlight_alt.png shows with the listbox for choosing a theme Also added highlight3.png... same kind of thing, but by renaming the tab as 'Themes' you no longer even need the row of labels at the top. And it parallels the fonts/tabs design suggestion somewhat too. -- Added file: http://bugs.python.org/file40111/highlight3.png ___ Python tracker <http://bugs.python.org/issue24781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24781] Improve UX of IDLE Highlighting configuration tab
Mark Roseman added the comment: The squares next to foreground/background are placeholders for those controls I can't remember what they're called (colour wells?) where it shows the current colour, and clicking it brings up a colour picker allowing you to change. So separate ones for foreground/background rather than a radio button to say what you'll set and then a button to set it. Sorry for the confusion. Any reason that you'd want to actually include a choice of ttk themes? Not sure that would really add anything positive to the overall UX (especially on Mac and Windows). Worth discussing more about the name 'theme' (which seems to be common in other code editors) vs. 'text highlighting' vs. other alternatives. Btw, is there a way to change the background colour and/or has that topic come up before? -- ___ Python tracker <http://bugs.python.org/issue24781> ___ ___ 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: I've attached extdlg.patch, which changes the UI for the configure extensions dialog. In particular, it replaces the stacked tabs with a listbox on the left, with the details of each extension appearing in a labelframe on the right. The inside of the labelframe gets swapped in with pretty much the same thing that was in the dialog before. This should be compatible with Tk 8.4, as ttk was not used. -- keywords: +patch Added file: http://bugs.python.org/file40118/extdlg.patch ___ Python tracker <http://bugs.python.org/issue24782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
