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.

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?

Two concrete reasons to make the conversion: two issues are stymied by current tree.TreeNode.

1. 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.

2. 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.

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.

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 bpo-37041 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.

Concrete reason 3. Treewidget does not work on high-res monitors. The bpo-37041 quick Treeview test worked for Andre Roberge

3. continued. As noted in bpo-22628, idlelib.tree has line spacing and other stuff hardcoded so it will not work properly on all monitors.

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

style = ttk.Style()
style.configure("Treeview", rowheight="30")

it works, but it is not dynamic with the font size/dpi

Response has suggestion.