Am 08.08.21 um 12:55 schrieb Will Godfrey:
I based the overall structure on the way Paul originally set up part kits,
and the mixer window - hence the fixed size array. I then took on Rainer's
suggestion about making it a vector, which eventually worked.
This is fine-ish if the original premise is correct, but from further 'net
trawling I'm beginning to think Paul's original setup might have been wrong!
It's very difficult to find any *really* clear info about FLTK, but the
scroll class is described as a container, and if that means what I think it
does, do we need the array/vector at all? Can we just dump the FilerLine
objects into the scroll?
I was asking that myself too. Yesterday on the train, I also spent some time
but could not find much conclusive Info on the net. As said, up to now mostly
I rather ignored the UI code of yoshimi. But on my review yesterday I got the
impression that the yoshimi UI code is written such as to basically ignore the
whole topic of memory management of UI elements altogether. Maybe this was
an initial decision along the lines "it does not hurt much" (which might be
even valid; it is likely that all the memory allocations of the UI are dwarfed
by the buffer allocations and wavetables).
However, the filer is maybe a bit special, since we repeatedly load a directory
and then throw away all the FilerLine objects with all attached UI elements.
As it stands, each FilerLine thus leaks the following stuff hold by pointer:
Fl_Group *fileIcon;
Fl_Box *outer_box;
Fl_Box *inner_box;
Fl_Box *line1;
Fl_Box *line2;
Fl_Box *type;
Fl_Group *dirIcon;
Fl_Button *name;
Only one other element, the Fl_Group *filerlist
is disposed in the dtor, which might give us a hint how to properly do that:
FilerLine::~FilerLine() {
filerlist->hide();
delete (filerlist);
}
While we are at that topic, I also fully agree with Rainer and Kristian:
it can be very problematic to handle UI elements just by pointer, and it can
be even more problematic to delete (=deallocate) UI elements, which were added
to some container previously. I am more familiar with GTK, and GTK defines some
policies, which you have to follow in such a case. And Gtkmm, the C++ wrapper
on top of GTK even provides a smart-pointer like handle to simplify that task.
So yes, this is a huge nasty topic for every GUI written in C. And this might
be the reason why "just leak the memory and be happy" can be an attractive
solution, as long as the GUI is basically created at start and shut down
together with the application as a whole.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
