The addition of tabbed windows to web browsers was a great advance that is now standard. For Windows, it eliminated the crowding of the taskbar. I suspect it made switching easier on all systems.

The addition of the same to IDLE would have similar benefits. I often have a shell and two edit windows open.

This would require, I believe, the use of ttk.Notebook, which requires tcl/tk 8.5+ or the Tile extension. Can this be made a requirement for IDLE in 3.2? Windows has 8.5 now. *nix users can add Tile if they have 8.4. I do not know the situation for Mac.

It is possible to create a tabbed window without ttk.Notebook. This is already being done in the configuration dialog. The real issue goes much beyond ttk.Notebook, check the patch "tabs_ttk_and_co.diff" at http://code.google.com/p/python-ttk/downloads/list for an earlier work on this (there is also a screenshot in the wiki over there showing the final result).

Changed title to match new info. Tabs might also be used for any pop-up windows that would benefit from persistence. [JEdit does this, but being non-language-specific, it does not have a shell with error traceback.]

(Note: there has recently been some discussion of this on idle-dev and python-dev.)

This may be nice to have but has complications. I think there are currently more pressing issues regarding IDLE that require our attention.

Also, just adding tabs isn't necessarily enough. Having several separate windows should still be an option. And if you can have several windows, each with several tabs, drag-n-drop moving of tabs between windows is really nice to have, not to mention drag-n-drop reordering of tabs.

Attached is an extension which provides tabbed windows for IDLE. It supports drag-and-drop reordering and separate windows. 

The implementation relies on monkey-patching a few subroutines and duck-typing for the toplevel window. The extension emulates each tab as if it were its own toplevel object. 

There can be flickering when switching tabs due to swapping the toplevel menu bar. This seems to be a limitation of Tk.

Roger's extension is an amazingly cool hack. With some of the decoupling mentioned in #24826, the actual switching should get easier.

Regarding cosmetics, I wanted to make a suggestion. The tabs provided by ttk::notebook aren't ideally suited for this task, both visually on some platforms (hello Mac) and also because they're designed for a fixed (small) number of tabs.

One of the better implementations of tabs I've seen is in the Mac editor TextMate. I've attached a set of annotated screenshots as tmtabs.png. It's nice and clean. Doing this as a widget based on the Tkinter canvas looks very feasible.

A tabbed widget, however implemented, should be a component that can either be in a Toplevel with menu by itself, or added to an application window (#24826).

I've put together a standalone tabs widget (mostly done) based on Tk canvas widget, that emulates the behaviour of TextMate's tabs. I was able to modify Roger's extension to use this widget. See attached screenshot newtabs.png (tabs area is fully functioning, bottom debug area is just UI).

Have attached uitabs.py.  From the header comments:

Standalone 'tabs' widget to switch between multiple different views.

Unlike the Tkinter ttk.Notebook widget, this widget is suitable for
displaying a potentially large number of tabs, as might be found in a
tabbed editor. If there are too many tabs to show based on the available
width, the remainder can be viewed via a popup menu on the last tab.

Tabs can be rearranged by dragging, closed, or new tabs added. Each tab
can have a title which is displayed in the tab, a tooltip for when the
mouse hovers over the tab, and a 'dirty' indicator that can be used to
indicate files needing to be saved.

The appearance and behaviour of the tabs is strongly influenced by the
TextMate editor on Mac OS X.

Implementation is via a single Tkinter canvas.

Unlike many other tabbed widgets, this widget does not take care of
actually switching content being displayed; this is left to the caller.

A UITabsObserver (see below) must be provided to the widget, and is
used to notify the caller when changes are made that must be reflected
in other parts of the user interface.

Have attached newTabExtension.py, which is Roger's tab extension, hacked to use uitabs.py instead of the UI previously built into that extension.

I modified Mark Rosen's newTabExtension to work with more recent versions of IDLE, as it wasn't working when I tried it on mine. It's not clear if it ever could when it was originally working, but I can't get it to move tabs between multiple window instances.

OMG no! Please reconsider.

First, analogy with web browsers is bogus. The modes of usage is very different. We don't look at multiple tabs simultaneously very often, but we do look at multiple files at once using IDLE (at least I do).

And I'm not the only one. Please see how Raymond masterfully uses IDLE in https://www.youtube.com/watch?v=nO78ECRighw. Will this be as easy (or possible at all) with the tabbed interface?

Crowding of the taskbar is eliminated by various other techniques: Windows 10 has virtual desktops, Linux has had them for a long time already. Please don't introduce real problems while solving a nonproblem.

Hi Cedric, I have been 'considering' for at least 7 years, since the core devs who then cared about IDLE agreed that tabbed windows would be a good idea.  The direst analogy with programming editors with tabs.   Notepad++ is the one I have used.  My impression is that this is pretty standard.

One thing I would not copy from Notepad++ is allowing only one process at a time, and apparently only one tabbed window in the one process.  In intend that IDLE continue to allow multiple processes with multiple windows.  I expect that 'New file' will be replaced with 'New tab' and 'New window', as with FireFox.

I intend that a single window to able to have at least 2 panes.  Look at turtledemo to see what this means. ('python -m turtledemo' or Help => Turtledemo in IDLE.)  Mentally replace the text and canvas with sets of tabbed pages, side by side. In fact, for my large widescreen monitor, I want 3 panes so I can have Shell, file, and test_file visible at once.

I have not yet really considered whether we should use an improved version of IDLE's tabbedpageset, used for configdialog, Mark's replacement, or ttk Notebook.

Also see the discussion on #24826.

Vedran, thank you for the link.  The way IDLE looks on Mac is what we want on all systems.  I added a note to #24826.

Do you regularly work on Mac?  It would be help if someone were to test PRs on OSX, especially patches intended to change what users see.  Even a weekly test of a fresh download from the repository would be helpful.

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.

I changed the title again to reflect the actual discussion.  #25036 (and #30784) are about extracting an editor component that can be put on a tab.  #25032 is about making a top-level with menu that is not tied to a single editor.  This issue should stick to tabbed pages.  

It seems that Notebook would be more suited to the config dialog with a fixed small number of tabs (now 5, possibly 6).  I will look at Notebook to see if it is worth using it for the dialog, so as to match ttk widgets on the tabs. For editor windows, this is not a concern.  I will see, though, if there is anything worth copying for the main tabbed pages. 

To identify specific issues for designing a custom tabs set, I looked at Marks pngs, Firefox, Thunderbird, Notepad++, and TortoiseHg Workbench.

* Tab shape: I seem to remember top rounded corners imitating standard American paper file folder tabs.  This appears to have gone out of style. Rectangles are in.

* Active versus Dormant: there should be a visually obvious difference. Bonus points is one can tell which is which when there are only two tabs.  Typical choices are white versus gray or white verson color (such as blue).  The two grays in the pngs are too close for me.  Firefox themes can also make the difference too small.

* Close button: Usually always present as X.  Background can match tab background or not.  Shape of background can be circle or square (possible rounded). On Windows, standard is right end of tab.  Is it opposite on Mac? Notepad++ omits, I presume to avoid space wastage.  Adding on mouseover is an interesting idea; I want to see how it feels in actual use.

* Mouse over tab: Full tab name appears in tool tip.  For editor, this is full path for file.  Dormant tabs should change appearance.  The result for the 'in-between state should look 'in-between' and not somehow look less like active.

* Mouse over close: Background changes color, exposing shape if hidden.

* Over-crowding: tabs may start same size or adjust for file name.  Tabs may shrink horizontally to a minimum or not.  When tabs collectively do not fit, a tab or tabs with < and > appearing seems normal.  Firefox puts them at opposite ends of the tab bar.  Notepad++ together to the right.  This is better for scanning back and forth.  A dropdown list is an interesting idea, again to be tried out.

* Tab context menu: always different from that of the page.  Contents of each vary.

* New tab button: Open empty editor file.

Possible enhancement after basic work is done: use the current ttk style to style the future tabbedpages widget.

> The way IDLE looks on Mac is what we want on all systems.  I added a note to #24826.

I'm not sure I understand you. This is what I have on Windows today. Of course, the menu is replicated on each window, but that's an irrelevant detail - it doesn't take that much space, and I use keyboard to access it anyway.

What I emphasized is something else: separate windows that can be independently opened, closed, moved and resized. When Raymond needs a few characters more in a line, he just temporarily resizes the window - everything else stays at the same place, ready for return to the previous state.

I think it's essential, and I must say I have never seen it in a tabbed interface application.

> Do you regularly work on Mac?  It would be help if someone were to test PRs on OSX, especially patches intended to change what users see.  Even a weekly test of a fresh download from the repository would be helpful.

No, sorry. I use Windows at home and Linux at work, I have never worked on a Mac. As I said above, my point was not the position of the main menu, but the ability to position windows where I want them on the screen.

Vedran, reread "continue ... with multiple windows".  What you describe as 'I have never seen' seems standard for tabbed windows applications.  I just verified that FireFox and Edge allow "separate windows that can be independently opened, closed, moved and resized."  (To repeat, I will NOT copy Notepad++ in restricting to one windows, which I regard as exceptional.)

Firefox also has both features Tal requested in msg110906 "And if you can have several windows, each with several tabs, drag-n-drop moving of tabs between windows is really nice to have, not to mention drag-n-drop reordering of tabs."  (Edge does not allow dropping on an existing window).  I would like both for IDLE if tk drag-and-drop allows.

Hm, interesting. Yes, I admit I didn't even know Firefox behaved in such a way, and I have used Firefox for quite a long time. But I'd say it only proves my point. How will users know about it?

Also: you probably want, when a user clicks on some file to say "Open with IDLE", for it to open in a new tab. There are experienced users (me included) that want it to open in a new window. Can we get a configuration option? Or at least a command line switch? (Like chrome --new-window.)

I suspect that Edit with IDLE would open a new window as it does now, but I don't really know.  I don't think that IDLE would have any control.  I seldom start IDLE that way.