Arbitrary number of child windows
- From: Holger Berndt <berndth gmx de>
- To: gtkmm-list gnome org
- Subject: Arbitrary number of child windows
- Date: Fri, 9 May 2008 19:28:49 +0200
I've been giving gtkmm a look lately, and so far, I am impressed by the
nice design of the language bindings.
I have however one pretty basic problem with window creation. I
have a main window, and I want to be able to create an arbitrary number
of non-blocking child windows for it. The child windows should be
destroyed together with the main window, and should also destroy
themselves (and free all memory) when they are closed individually.
As an example: Say I have a long list of items in a tree view in my
main window. Whenever I activate an item, I want a window popping up
with further details. It should be possible to display multiple such
windows at the same time, even multiple detail views on the same data,
so I don't want to reuse the former windows. In order for the child
windows not to leak memory on closing, I don't want them to just hide,
but destroy themselves.
As far as I can see, I can't archieve that with any of the memory
management methods described in the gtkmm-book. I have found an older
mailing list post at
http://osdir.com/ml/gnome.gtkmm/2003-03/msg00067.html
that tries to solve the very same problem. I am however a bit sceptic
on the frequent use of "delete this;" in member functions. As far as I
know, "delete this;" itself is valid, but any other statement, even a
return statement, is undefined behaviour. I might be wrong about that
though.
Another possibility that I can see is to keep track of all open windows
in the main window class in a list, connect the child window's delete
event signal to a member function of the main window to remove the
window and delete all its memory resources, using the window pointer in
the GdkEventAny structure argument. The disadvantage of this
however is that still a higher instance needs to keep track of the
childs, they are not easy-to-use fire-and-forget self-destructing
windows.
Another possibility would be something along Qt's QObject::deleteLater()
function to not actually do a "delete this;" but schedule an object for
deletion in the event loop. That sounds more well-defined than a "delete
this", but I haven't found an equivalent in gtkmm.
How do other people write their self-destructing child windows?
Holger
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]