GtkObject is gone (was GTK3 breakage)
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. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: gtkmm 2.22.0
*** gtkmm 2.22: gtkmm 2.22 wraps new API in GTK+ 2.22. It is is API/ABI-compatible with gtkmm >=2.4. It is a version of the gtkmm-2.4 API. gtkmm stays in-sync with GTK+ by following the official GNOME release schedule: http://www.gnome.org/start/unstable/ Bindings for the rest of the GNOME Platform are also available, and are also API-stable. http://www.gtkmm.org *** Changes Build changes in gtkmm 2.22: * Remove support for these glibmm build options via ifdefs: --enable-api-exceptions --enable-api-properties --enable-api-default-signal-handlers (All this gtkmm API is now always present.) * atkmm is now a separate tarball module. New API in gtkmm 2.22: Gtk: * AlignmentEnum: Add ALIGN_START and ALIGN_END to match gtkmm 3, to help future porting. * Assistant: Added commit(). * Button: Added get_event_window(). * Entry: Added im_context_filter_keypress() and reset_im_context(). * Expander: Added get/set_label_fill() and property. * IconView: - Added tooltip-column and reorderable and item-padding properties. - Added get/set_item_orientation(). * MenuItem: Added unset_submenu(). * MessageDialog: - Added get_message_area() and message-area property. * TextBuffer: Added get_copy_target_list() and get_paste_target_list(). * MenuBar: Added set/get_pack_direction() and set/get_child_pack_direction. * Notebook: - Deprecated pages(). - Added get_tab_hborder() and get_tab_vborder(). * PaperSize: Added get_paper_sizes(). * PrintOperation: - Added run_page_setup_dialog() overloads. * PrintUnixDialog: Added get_manual_capabilities(). * SeparatorToolItem: Added get/set_draw(). * StatusBar: Added remove_all_messages(). * Style: Added copy(). * Table: - Deprecated children(). - Added get_size(). * TextView: Added get_hadjustment(), get_vadjustment(), im_context_filter_keypress(), reset_im_context(). * Viewport: Added get_view_window(). * Widget: - Added send_focus_change(). - Added const version of get_accessible(). * Added many properties. Gdk: * Color: Deprecate rgb_find_color(). * Cursor: Added get_cursor_type(). * Device: Added get_key(), get_axis_use(), get_n_axes(). * RgbCMap: Deprecated. * Visual: Added get_visual_type(), get_depth(), get_byte_order(), get_colormap_size(), get_bits_per_rgb(), get_red_pixel_details(), get_green_pixel_details(), get_blue_pixel_details(). * Window: Added get_composited(), is_input_only(), is_shaped(), has_native(), get_modal_hint(), get_background_pattern(), coords_to_parent(), coords_from_parent(), get_effective_parent(), get_effective_toplevel(), create_similar_surface(), get_accept_focus(), get_focus_on_map(). * Added many properties. *** Development There is active discussion on the mailing list: http://www.gtkmm.org/mailinglist.shtml and in the #c++ channel on irc.gnome.org -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: GtkObject is gone (was GTK3 breakage)
On Tue, 2010-09-28 at 09:55 +0200, Murray Cumming wrote: > 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. g_object_run_dispose() is very similar to gtk_widget_destroy() in terms of memory management semantics. The main difference is that there's no ::destroy signal emitted. - Owen ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: GtkObject is gone (was GTK3 breakage)
On Tue, 2010-09-28 at 10:11 -0400, Owen Taylor wrote: > On Tue, 2010-09-28 at 09:55 +0200, Murray Cumming wrote: > > > 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. > > g_object_run_dispose() is very similar to gtk_widget_destroy() in terms > of memory management semantics. Yes, after talking on irc we came to the same conclusion. > The main difference is that there's no ::destroy signal emitted. For some reason we use a qdata destroy callback to detect GObject destruction anyway, instead of the "destroy" signal. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
