I didn't do this because in general its bad design to have two "owners" of an instance, and here Fl_Group really is the owner at all times; it has to be for events and such to operate properly. Also, arguably for consistency it would be necessary to provide begin()/end()/add()/etc etc which takes things off the rails.

If Fl_Tree_Item were itself an Fl_Group/Fl_Widget derived widget, then it would be OK, but Fl_Tree_Item is purposefully designed not to be for efficiency, so there can be hundreds or thousands of items without the overhead of an Fl_Group in each item, esp. when the items are not hosts of Fl_Widgets.

I'd offer to solve the issues you're running into, the docs for Fl_Tree and Fl_Tree_Item::widget() should be fleshed out more about how to manage child widgets assigned to Fl_Tree_Items properly.

I'd also offer Fl_Group's docs should discuss this too, as it's not clear from anything in Fl_Group how to properly remove and destroy a widget. Perhaps Fl_Group should have a virtual delete(w) (that simply calls Fl::delete_widget()) so it's easy to discern from the docs how to do this, and then by extension Fl_Tree could extend this to ensure the widget is not only deleted from the group, but also unassigning it from any tree item it's been associated with.

I'd suggest opening a discussion on fltkcoredev to discuss API/doc improvements (so other devs can weigh in), as such conversations are pretty hidden within issues.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.