Addition to Fl_Group docs

10 views
Skip to first unread message

Greg Ercolano

unread,
Sep 19, 2022, 2:02:34 PM9/19/22
to fltkc...@googlegroups.com

Would like the Fl_Group docs to cover how to properly remove a widget. Would
the following patch suggestion be accurate?

+++ b/FL/Fl_Group.H

@@ -38,6 +38,10 @@ class Fl_Rect;
   this group, and to other groups. The only modifier grabbed is shift
   (for shift-tab), so that ctrl-tab, alt-up, and such are free
   for the app to use as shortcuts.
+
+  To remove a widget from the group and destroy it, as of 1.3.x you can
+  simply use <tt>delete some_widget</tt> and this will trigger the proper
+  scheduling of the widget's removal from the parent group.
 */

Albrecht Schlosser

unread,
Sep 20, 2022, 3:45:04 AM9/20/22
to fltkc...@googlegroups.com
The code as suggested is correct but the comment is inaccurate. This code destroys the widget immediately and widget deletion triggers the (immediate) removal from its parent group (if any) inside the destructor of the widget. This is now the recommended method.

FYI: on the contrary, Fl::delete_widget() which *schedules* the deletion of the widget after return from the event loop is no longer necessary and has its own issues. Since 1.3.x it is fine to delete widgets directly as it would be documented above. Fl::delete_widget() was only *necessary* in 1.1.5 and later and should never be required since 1.3.x.

Thanks for updating the docs.

Greg Ercolano

unread,
Sep 23, 2022, 7:48:55 AM9/23/22
to fltkc...@googlegroups.com


On 9/20/22 00:45, Albrecht Schlosser wrote:
On 9/19/22 20:02 Greg Ercolano wrote:

Would like the Fl_Group docs to cover how to properly remove a widget. Would
the following patch suggestion be accurate?

+++ b/FL/Fl_Group.H

@@ -38,6 +38,10 @@ class Fl_Rect;
   this group, and to other groups. The only modifier grabbed is shift
   (for shift-tab), so that ctrl-tab, alt-up, and such are free
   for the app to use as shortcuts.
+
+  To remove a widget from the group and destroy it, as of 1.3.x you can
+  simply use <tt>delete some_widget</tt> and this will trigger the proper
+  scheduling of the widget's removal from the parent group.
 */

The code as suggested is correct but the comment is inaccurate. This code destroys the widget immediately and widget deletion triggers the (immediate) removal from its parent group (if any) inside the destructor of the widget. This is now the recommended method.

    OK, so sounds like the proposed doc change should read instead:

+
+  To remove a widget from the group and destroy it, as of 1.3.x you can
+  simply use <tt>delete some_widget;</tt> and its destructor triggers
+  the immediate removal from the parent group.


    If so, I'll make that change and commit.


FYI: on the contrary, Fl::delete_widget() which *schedules* the deletion of the widget after return from the event loop is no longer necessary and has its own issues. Since 1.3.x it is fine to delete widgets directly as it would be documented above. Fl::delete_widget() was only *necessary* in 1.1.5 and later and should never be required since 1.3.x.

    I figure our docs for Fl::delete_widget() covers this history well enough.




Albrecht Schlosser

unread,
Sep 25, 2022, 4:57:43 AM9/25/22
to fltkc...@googlegroups.com
On 9/23/22 13:48 Greg Ercolano wrote:
    OK, so sounds like the proposed doc change should read instead:

+
+  To remove a widget from the group and destroy it, as of 1.3.x you can
+  simply use <tt>delete some_widget;</tt> and its destructor triggers
+  the immediate removal from the parent group.


    If so, I'll make that change and commit.

Yep, looks good, +1.


FYI: on the contrary, Fl::delete_widget() which *schedules* the deletion of the widget after return from the event loop is no longer necessary and has its own issues. Since 1.3.x it is fine to delete widgets directly as it would be documented above. Fl::delete_widget() was only *necessary* in 1.1.5 and later and should never be required since 1.3.x.

    I figure our docs for Fl::delete_widget() covers this history well enough.

OK, I didn't want to suggest to change it.

Reply all
Reply to author
Forward
0 new messages