I like very much what Csaba Nemethi did for enahnacing the notebook widget.
In particular the close-tab-button ...
but there's one thing I think is missing from this API , which brings us to the "lost tabs problem.."

Just a premise:
As long you remove a notebook tab "by-program" ( $nb forget $tabid ) you also have complete control about what to do with the no-more-visible (unmapped) slave widget .
You can choose to destroy the widget (and all the involved resources like channels, images, ...)
or simply
put it in a list for a next add/insert ...
You have the full control ...

On the contrary, when you press the small close-tab button, you simply 'forget' (i.e. unmap) the slave widget,
but then ... the slave widget becomes a sort of lost widget ....

What I feel is that we need a generic and simple mechanism for telling the slave widget ".. hey ,you've been removed from the notebook" ,
so that this umapped widget can choose what to do (destroy itself, free the allocated resources, and so on ..)
My first rough ideas:
* generate a virtual event <<NotebookTabClosed>>
or
* add an option for a new callback like -afterforgetcommand

But then, I see a second, and more difficult, problem:
What happens when the whole notebook is destroyed ?
What happens to its contents (i.e. its slave widgets) ?

Let's consider this example;
+------------------
toplevel .z
frame .z.f
pack [ttk::notebook .z.f.nb -expand true -fill both] ;# .z.nb could also be a scrollutil::notebook
..
.z.nb add [frame .z.f.nb.f1 -bg red] -title "f1" ;# --
.z.nb add [frame .z.f.nb.f2 -bg green] -title "f2"
.z.nb add [frame .z.f3 -bg blue] -title "f3" ;# note: this slave is not a descendent of .z.f.nb !!
....
destroy .z.f.nb ; # this might be caused by an interactive cleanup of the .z.f frame ...
+---------

Consider that after notebook has been destroyed:
... slave f1 and f2 are automatically destroyed, but "f3" is always there (unmapped)
... moreover, if "f1" or "f2" were complex megawidgets with some allocated resources like sockets, images .., then thse resources won't be deallocated !

In conclusion, I have just shown what in my opinion is the problem of loss of control when these operations are performed interactively (closing a tab, destroying a notebook); I hope there is a simple general solution...
Suggestions ?

Am 16.08.23 um 16:15 schrieb aldo.w....@gmail.com:
> I like very much what Csaba Nemethi did for enahnacing the notebook widget.
> In particular the close-tab-button ...
> but there's one thing I think is missing from this API , which brings us to the "lost tabs problem.."
>
> Just a premise:
> As long you remove a notebook tab "by-program" ( $nb forget $tabid ) you also have complete control about what to do with the no-more-visible (unmapped) slave widget .
> You can choose to destroy the widget (and all the involved resources like channels, images, ...)
> or simply
> put it in a list for a next add/insert ...
> You have the full control ...
>
> On the contrary, when you press the small close-tab button, you simply 'forget' (i.e. unmap) the slave widget,
> but then ... the slave widget becomes a sort of lost widget ....
>
> What I feel is that we need a generic and simple mechanism for telling the slave widget ".. hey ,you've been removed from the notebook" ,
> so that this umapped widget can choose what to do (destroy itself, free the allocated resources, and so on ..)
> My first rough ideas:
> * generate a virtual event <<NotebookTabClosed>>
> or
> * add an option for a new callback like -afterforgetcommand
>

From the "FURTHER BINDINGS" section of the Scrollednotebook reference
manual:

4. Closing a tab of a scrollednotebook widget with the aid of the
closetab element: ... after closing the tab, the widget generates a
<<NotebookTabClosed>> virtual event, by invoking event generate with
the -data option set to the path name of the widget contained in that
tab's pane.

5. Closing a tab of a ttk::notebook widget with the aid of the closetab
element: ... the tab is not (yet) closed. Instead, the widget generates
a <<CloseTabRequested>> virtual event, by invoking event generate with
the -data option set to the numerical index of the tab in question. It
is the responsibility of the application to create a binding for this
virtual event and to close the tab from within the binding script by
invoking the widget's forget subcommand if appropriate, ...

According to the above, the programmer has in both cases full control
over the widget that has been removed from the notebook.

Note that the <<NotebookTabClosed>> virtual event is defined for the
plainnotebook widget, too, whose tabs ca be closed interactively with
the aid of the closebtn element.

> But then, I see a second, and more difficult, problem:
> What happens when the whole notebook is destroyed ?
> What happens to its contents (i.e. its slave widgets) ?
>
> Let's consider this example;
> +------------------
> toplevel .z
> frame .z.f
> pack [ttk::notebook .z.f.nb -expand true -fill both] ;# .z.nb could also be a scrollutil::notebook
> ..
> .z.nb add [frame .z.f.nb.f1 -bg red] -title "f1" ;# --
> .z.nb add [frame .z.f.nb.f2 -bg green] -title "f2"
> .z.nb add [frame .z.f3 -bg blue] -title "f3" ;# note: this slave is not a descendent of .z.f.nb !!
> ...
> destroy .z.f.nb ; # this might be caused by an interactive cleanup of the .z.f frame ...
> +---------
>
> Consider that after notebook has been destroyed:
> ... slave f1 and f2 are automatically destroyed, but "f3" is always there (unmapped)
> ... moreover, if "f1" or "f2" were complex megawidgets with some allocated resources like sockets, images .., then thse resources won't be deallocated !
>
>
> In conclusion, I have just shown what in my opinion is the problem of loss of control when these operations are performed interactively (closing a tab, destroying a notebook); I hope there is a simple general solution...
> Suggestions ?

This second problem is independent of the closetab and closebtn elements.

--
Csaba Nemethi https://www.nemethi.de mailto:csaba.nemethi@t-online.de

Thank you for your answer, Csaba.
Your reference manual is complete and clear, as usual. It's only my confusion.
I'd just kindly suggest to remove support for Tk <= 8.5 - I wonder who is still using Tk 8.5 for a modern app ! Both code and reference pages will be simplified. - Anyway, this is just my opinion ;-)

About the second question (..what happens when a notebook is deleted..) I understand it's not a problem regarding the closetab, but it's still a problem I solved just for very specific cases, and I'd like to find a more general solution.

To be more clear, what I'm trying to do is to use an "extended" ttk::notebook for building a multi-tab PDF-viewer (using mupdfWidget), much like AcrobatReader. Tabs can be moved, closed, and also 'detached' .
Here the problem is to 'gracefully close' all the enclosed PDF-viewers when the enclosing Notebook is destroyed.
In this specific case, it was easy, because all the enclosed megawidgets have a destructor that is triggered when the notebook is destroyed (and consequently it destroys all its children widgets.. ).
I hope to publish a proof of concept on wiki.tcl.tk, the next days.

Aldo