Repository navigation
IDLE: Convert browsers to use ttk.Treeview #75733
Description
| BPO | 31552 |
|---|---|
| Nosy | @terryjreedy, @aroberge |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/terryjreedy'
closed_at = None
created_at = <Date 2017-09-22.15:18:50.957>
labels = ['expert-IDLE', 'type-bug', '3.11']
title = 'IDLE: Convert browsers to use ttk.Treeview'
updated_at = <Date 2022-03-19.08:43:15.746>
user = 'https://github.com/terryjreedy'bugs.python.org fields:
activity = <Date 2022-03-19.08:43:15.746>
actor = 'AlexWaygood'
assignee = 'terry.reedy'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2017-09-22.15:18:50.957>
creator = 'terry.reedy'
dependencies = []
files = []
hgrepos = []
issue_num = 31552
keywords = []
message_count = 8.0
messages = ['302747', '302749', '303189', '303190', '343533', '395060', '415506', '415532']
nosy_count = 2.0
nosy_names = ['terry.reedy', 'aroberge']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue31552'
versions = ['Python 3.11']Linked PRs
Metadata
Metadata
Assignees
Projects
- Status
Activity
terryjreedy commentedon Sep 22, 2017
ttk.Treeview should look as good as idlelib.tree, but will check. It is more flexible. Note that Treeview is low-level, need to add higher level functions or classes. See if can more or less duplicate API of tree Items.
terryjreedy commentedon Sep 22, 2017
From bpo-31461: Browsers currently use idlelib.tree.TreeWidget. Treeview is not a drop-in replacement because TreeWidget has some of the higher-level app-specific functions that users are expected to add to Treeview. But could Treeview replace the low-level parts of TreeWidget that actually display stuff on the screen?
terryjreedy commentedon Sep 28, 2017
Two concrete reasons to make the conversion: two issues are stymied by current tree.TreeNode.
bpo-25090 tree.TreeNode requires an icon for every line. Hence functions and classes get python file and director icons and they are difficult to remove. By default, Treeview items do not get an image beside the text.
bpo-20827 tree.TreeNode hardcodes single click behavior (in multiple places). TreeItems can only override or augment double clicks. So it would be hard to keep hilites synchronized in browser and editor. Treeview generates '<<TreeviewSelect>>' when a line is clicked on; setting the editor line can be done in a select handler.
terryjreedy commentedon Sep 28, 2017
The main issue for conversion is expanding nodes. tree.py does not define a widget class. Rather, is uses a used a canvas and places images and text thereupon. The latter is done with instances of TreeNode. Each instance thereof is initialized with an instance of a subclass of TreeItem. TreeItems can tell their TreeNode whether they can generate children without actually doing so.
Treeview *is* a widget which manages internal column and line structures. Clicking a [+] or [-] icon generates a '<<TreeviwOpen>>' or '<<TreeviewClose>>' event. Double clicking a line generates both a select and flip event. The catch is that there is no [+] unless the node already has at least one child.
One solution would be to initially generate the whole tree of Treeview items from the pyclbr tree. Another is to give items with children a dummy child and replace it on demand. The item could be given its line number (as a string) as its id. A subclass of Treeview (or a Frame containing one) could have a dict mapping ids to child dicts).
Since the browser TreeItem subclasses are used by pathbrowser, I would initially move them to that module rather than delete them. Or I would combine the two modules.
terryjreedy commentedon May 26, 2019
I changed the type to behavior because the hard-coded pixel heights prevent the browsers form being usable on at least one HiDPI monitor. I closed #81222 in favor of this on the presumption that ttk.Treeview will work on such monitors, at least after fix_scaling(root) is called. I posted a quick test there.
terryjreedy commentedon Jun 4, 2021
Concrete reason 3. Treewidget does not work on high-res monitors. The #81222 quick Treeview test worked for Andre Roberge
terryjreedy commentedon Mar 18, 2022
terryjreedy commentedon Mar 19, 2022
ttk.Treeview also has problems, at least on some systems and versions.
https://mail.python.org/pipermail/tkinter-discuss/2022-March/004226.html
HiDPI displays and tkinter [cont]
https://mail.python.org/pipermail/tkinter-discuss/attachments/20220316/843e7076/attachment-0001.png
Apparently on linux.
https://mail.python.org/pipermail/tkinter-discuss/2022-March/004228.html
https://www.tcl.tk/man/tcl/TkCmd/ttk_treeview.html
under "Styling Options'
there is parameter to set the -rowheight
that needs to be defined as
ttk::style configure Treeview \
-rowheight [expr {[font metrics font -linespace] + 2}]
however I could not find how to call this command, and when
If I do the following
it works, but it is not dynamic with the font size/dpi
Response has suggestion.
[-]IDLE: Convert browswers to use ttk.Treeview[/-][+]IDLE: Convert browsers to use ttk.Treeview[/+]serhiy-storchaka commentedon Sep 6, 2026
#157029 converts everything that used
idlelib.tree— the Module and Path browsers, Debug ▸ Stack Viewer, the object browsers and the Debug Control panes — withidlelib/tree.pykeeping its name and wrapping attk.Treeview. That covers all three reasons here: an icon on a row is now optional, the row height comes from the configured font instead of hardcoded pixels, and selection is the widget's own, so a single click is free for the editor/browser sync.