Re: [Re: [Re: [Re: [Re: [Re: [Re: [Re: [[gtkmm] technical question: GTKMM_LIFECYCLE]]]]]]]]
- From: Paul Davis <pbd op net>
- To: MHL Schulze t-online de (Martin Schulze)
- Cc: Carl Nygard <cjnygard fast net>, gtkmm-list <gtkmm-list gnome org>
- Subject: Re: [Re: [Re: [Re: [Re: [Re: [Re: [Re: [[gtkmm] technical question: GTKMM_LIFECYCLE]]]]]]]]
- Date: Thu, 03 Oct 2002 08:56:27 -0400
>Am 03.10.2002 13:27 schrieb(en) Carl Nygard:
>> Then you should just throw up your hands and say "It ain't gonna be
>> consistent." The base libraries are already inconsistent, so quit
>> trying to force it.
>
>I thought it would be a good idea to make the behaviour 100% consistent
>by slightly changing gtkmm to be more consistent in itself without
>breaking any existing code. Neither did I expect that it would be so
>hard to explain nor that I would hit such a sensitive nerve.
i think what you haven't show enough sensitivity to is that it is
GTK+, not gtkmm, that behaves oddly here. because GTK+ containers
force the destruction of their children when they are destroyed, the
glib object reference counting model is already ruined by the time you
get even just to GTK+. trying to fix that in a C++ wrapper makes no
sense to me. you've already pointed out that gstreamer doesn't do
this, and uses the glib object reference counting model more
"thoroughly". given this, it seems quite unlikely that gtkmm and gstmm
can share the same semantics when the APIs they wrap do not.
if anything, i think you should put as much energy as you have with
this issue into petitioning the GTK+ crowd to use gtk_object_unref()
instead of gtk_widget_destroy() in gtk_container_destroy(). then we'd
end up with a much more consistent and easy to think about toolkit.
--p
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]