GtkObject is gone (was GTK3 breakage)
- From: Murray Cumming <murrayc murrayc com>
- To: Benjamin Otte <otte gnome org>
- Cc: gtk-devel-list <gtk-devel-list gnome org>, gtkmm-list <gtkmm-list gnome org>
- Subject: GtkObject is gone (was GTK3 breakage)
- Date: Tue, 28 Sep 2010 09:55:40 +0200
On Sun, 2010-09-26 at 16:08 +0200, Benjamin Otte wrote:
> - GtkObject is gone
> With the existance of GObject, GtkObject became unnecessary. The
> functions it provided are now either part of GObject or GtkWidget.
For gtkmm, I welcome this for the little GtkAdjustment, GtkFileFilter
and GtkRecentFilter objects. Now they are simple reference-counted
objects.
But for some other more commonly-used objects (GtkWidgets,
GtkCellRenderer, GtkTreeViewColumn), I'd like to avoid changing our
memory management too much. Is there no way now to force an object to be
destroyed?
Right now, we let our GtkWidgets be destroyed when their C++ wrappers go
out of scope automatically. For instance, when a C++ class's destructor
automatically destroys its member instances, like so:
http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-helloworld.html.en
Our GtkWidget classes should be OK, because we can use
gtk_widget_destroy() instead of gtk_object_destroy. But I wonder what to
do with GtkCellRenderer and GtkTreeViewColumn.
We could just unref the underlying object, but once the wrapping C++
object has been destroyed, the vfuncs (and default signal handlers) will
fall back to default C implementations, if any, and this could even
cause different UI behaviour.
If I must, then I'll force Gtk::CellRenderer and Gtk::TreeViewColumn to
be used only via RefPtr<>, like other reference-counted objects, but
this will probably just annoy C++ programmers. They feel like widgets,
so it seems odd for them to not have similar memory management.
--
murrayc murrayc com
www.murrayc.com
www.openismus.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]