Am 16.08.23 um 16:15 schrieb
[email protected]:
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:
[email protected]
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)