FLTK logo

STR #3218

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:

No files


Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.