| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3218
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | method for deleting child from a Fl_Group |
Version: | 1.3-feature |
Created By: | Belgiansteve |
Assigned To: | AlbrechtS |
Fix Version: | 1.4.0 |
Fix Commit: | 9abbff2078e2a092ecc252f6b147c24fe567f616 |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#1 | Belgiansteve 09:47 Apr 14, 2015 |
| Currently, Fl_Group offers Fl_Group::clear() which deletes all child widgets and Fl_Group::remove() which removes the child from the group without deleting it. There does not seem to be a member function that removes a single child and deletes it from memory. Would it be possible to add this? Thanks!
Steve | |
|
#2 | AlbrechtS 14:56 Apr 14, 2015 |
| This is not necessary. If you want to remove a widget from a group and delete it you can just delete it. The widget's destructor removes it from its parent group if it _has_ a parent (and there can be only one parent).
Or did I miss anything? | |
|
#3 | Belgiansteve 16:58 Apr 14, 2015 |
| Thanks for the suggestion. Yes, I agree there are ways to do this. In fact, since I have the index to the child I was doing:
Fl_Widget* pw = child(index); remove(index); delete pw;
which is slightly more efficient for reasons mentioned in the docs. I understand this is not a big issue, but I thought it would be nice to have a convenience function that accomplishes this. | |
|
#4 | greg.ercolano 19:00 Apr 14, 2015 |
| I'd kinda agree.
We kinda have a precedent already; Fl::delete_widget(w).
So I suppose if there was an Fl_Group::delete_widget(w)..? | |
|
#5 | AlbrechtS 06:58 Apr 15, 2015 |
| @Greg: I don't think that this should be used as a precedent. Fl::delete_widget(Fl_Widget *) has different semantics and that is the only reason why it exists. If we had such a similar name, wouldn't it be possible that users would think it works like Fl::delete_widget(), i.e. with delayed deletion? Of course the docs would explain that this is not the case, but..
@Steve: indeed I missed something. You didn't post that you had the index of the child you wanted to delete. This makes more sense.
Let's say we call it Fl_Group::delete_child(int n). Then you could use
(1) group->delete_child(n);
instead of
(2) delete group->child(n);
with exactly the same end result. (2) is more explicit, and personally I'd probably prefer it anyway, but (1) would likely do some range checking whereas child(n) explicitly does not (see the docs).
Another difference would be the order of remove() and delete which could be different, and (1) could use the index to remove the child which could indeed be faster than the lookup that is needed when the child removes itself with Fl_Group::remove(Fl_Widget*).
Finally I agree that Fl_Group::delete_child(int n) would make some sense, so we might want to have it.
Thinking further, we could also overload Fl_Group::delete_child() with
Fl_Group::delete_child(Fl_Widget *w)
but this is problematic. What if the widget is not a child of this group? Would it be deleted anyway? This overloaded method would not have any speed advantages, hence I wouldn't recommend to implement that one.
Comments, anybody? Steve? | |
|
#6 | Belgiansteve 08:08 Apr 15, 2015 |
| I think these are great suggestions. Adding Fl_Group::delete_child(int) would make a lot of sense to me. I agree that Fl_Group::delete_child(Fl_Widget*) would potentially be slower, but could be added for completeness. I also suggest making these functions virtual. Since Fl_Group can be subclassed, the derived class can introduce additional dependencies between widgets (e.g. Fl_Tree where Fl_Tree_Item depends on Fl_Widgets). The derived class can then overload the delete_child() members if necessary to make sure additional dependencies are handled properly. | |
|
#7 | AlbrechtS 02:59 Apr 16, 2015 |
| Making the method virtual is a good idea. In the light of a virtual method that can be overloaded in different ways (Fl_Tree is a good example), I can also see that Fl_Group::delete_child(Fl_Widget *w) would make a little more sense, although it can still be achieved with a simple `delete w;'.
The problem is that we can't add virtual methods to FLTK 1.3.x because this would break the ABI. The next minor version upgrade (1.4.0) will have more virtual methods anyway, particularly many (most of, all?) Fl_Group methods that handle children. Fl_Group::remove() is one method that must be virtual, for instance.
Thanks for your comments. | |
|
#8 | AlbrechtS 08:52 May 25, 2021 |
| I added virtual int Fl_Group::delete_child(int n) but I decided not to add Fl_Group::delete_child(Fl_Widget *w) because it wouldn't add much value.
I also implemented Fl_Scroll::delete_child(int n) which refuses to remove and delet the scrollbar widgets in commit 0f3619ba0e725a6a9d57b9da328f3b1e2a0cd150
More subclasses to follow ...
I'm closing this STR now since the requested method was added. | |
[ Return to Bugs & Features ]
|
| |