On 25 Nov 2013, at 21:22, Ian Martin wrote: > Hi John, > Hope you don't mind me jumping in. I'm curious why you want to do your own > memory management: Gtk::manage takes all the work out of your hands safely, > and stops you deleting widgets in an inappropriate order >
Hi Ian, No, I don't mind you contributing at all and I'm very pleased to hear your suggestion about Gtk::Manage. The problem in this case is that it's not in any technical sense "my" program. This is a complex and very well established Linux program which has been around for a very long time. When the program was at Version 2, I adapted it to be buildable with MSVC while someone else was adapting it for OS-X. At the risk of boasting, the MSVC version is by far the easiest to debug and for that (and other) reasons, it seems to be the most stable of the three options (by a very big margin). I'd estimate that only 3% of user complaints are about the Windows version, So as an exercise, it was well worth doing. However, the program has moved on and is now at Version 3, which I'm trying again to adapt. But Version 3 seems to be riddled with strange problems (all of them, so far, down to gtkmm). For stack based objects in particular, simply changing the order of creation can be enough to crash the program - or stop it from crashing if it was previously crashing. A couple of weeks ago, gtkmm would crash if I derived a class from Gtk::Window or Gtk::Dialog - whereas both classes worked fine if I used them directly, instead of deriving from them. These are extremely serious issues for a modern C++ library. No library should crash simply because I change the creation order of two objects. Nor should it crash if I derive an object from some other object that was previously well behaved. So whilst I appreciate your suggestion about Gtk::Manage (and for all I know, it might even help with the problems) ultimately, it would only be helping to mask some very serious and dangerous bugs. Gtk::Manage might well be helpful as a workaround - but whether it's helpful or not, the underlying problems do need to get fixed. John _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
