GNOME Bugzilla – Bug 788513
Gtk::CellRendererPixbuf: unable to set property 'surface'
Last modified: 2018-01-02 08:47:34 UTC
I'm trying to set a "surface" property on Gtk::CellRendererPixbuf and getting a gtk error: "unable to set property 'surface' of type 'CairoSurface' from value of type 'glibmm__CustomBoxed_N5Cairo6RefPtrINS_7SurfaceEEE'" This is the code: ------------------------------------------- class GscMainWindowIconView : public Gtk::IconView { Gtk::CellRendererPixbuf cell_renderer_pixbuf; // ... GscMainWindowIconView() { //... this->pack_start(cell_renderer_pixbuf, false); this->set_cell_data_func(cell_renderer_pixbuf, sigc::mem_fun(this, &GscMainWindowIconView::on_cell_data)); } void on_cell_data(const Gtk::TreeModel::const_iterator& iter) { Gtk::TreeRow row = *iter; Glib::RefPtr<Gdk::Pixbuf> pixbuf = row[col_pixbuf]; // I couldn't find the gtkmm version of gdk_cairo_surface_create_from_pixbuf(), // that's why I create the surface this way. Cairo::Format format = Cairo::FORMAT_ARGB32; if (pixbuf->get_n_channels() == 3) { format = Cairo::FORMAT_RGB24; } Cairo::RefPtr<Cairo::Surface> surface = get_window()->create_similar_image_surface( format, pixbuf->get_width(), pixbuf->get_height(), get_scale_factor()); // THIS IS THE PROBLEM cell_renderer_pixbuf.property_surface().set_value(surface); } } ------------------------------------------- Note that if I change Cairo surface creation and property setting to C-style, everything works: cairo_surface_t* surface = gdk_cairo_surface_create_from_pixbuf( pixbuf->gobj(), get_scale_factor(), get_window()->gobj()); g_object_set(G_OBJECT(cell_renderer_pixbuf.gobj()), "surface", surface, NULL);
The following comment comes from gtkmm/gdk/src/drawingcontext.hg: // A wrapped property_clip() would require a template specialization // Glib::Value<Cairo::RefPtr<T>>. //_WRAP_PROPERTY("clip", ::Cairo::RefPtr< ::Cairo::Region>) Compare with _WRAP_PROPERTY("surface", ::Cairo::RefPtr< ::Cairo::Surface>) from gtkmm/gtk/src/cellrendererpixbuf.hg. Not much chance that CellRendererPixbuf::property_surface() will work. It's not a good idea to add a Glib::Value<Cairo::RefPtr<T>> specialization in glibmm. Glibmm does not depend on cairomm. Add a specialization in gtkmm?
Have you got a small but complete test case that you can attach to this bug, a program that can be compiled and linked, and that uses Gtk::CellRendererPixbuf::property_surface()?
Fixed in the master branch and the gtkmm-3-22 branch. I've tested by just adding Cairo::RefPtr<Cairo::Surface> surface; //.... surface = m_icon_cell.property_surface(); to demos/gtk-demo/example_iconbrowser.cc. Without the fix I get the run-time error (gtkmm-demo:9849): GLib-GObject-WARNING **: g_object_get_property: can't retrieve property 'surface' of type 'CairoSurface' as value of type 'glibmm__CustomBoxed_St10shared_ptrIN5Cairo7SurfaceEE' in the master branch, and (gtkmm-demo:15294): GLib-GObject-WARNING **: g_object_get_property: can't retrieve property 'surface' of type 'CairoSurface' as value of type 'glibmm__CustomBoxed_N5Cairo6RefPtrINS_7SurfaceEEE' in the gtkmm-3-22 branch. No such error messages With the fix.
I guess this shouldn't be in the master branch. Cairo::RefPtr is now just std::shared_ptr, so this specialization affects all uses of std::shared_ptr in, for instance, a TreeView, leading to build problems such as this in Glom: /opt/gnome/include/gdkmm-4.0/gdkmm/value_cairo.h: In instantiation of ‘class Glib::Value<std::shared_ptr<Glom::LayoutItem>, void>’: /opt/gnome/include/gtkmm-4.0/gtkmm/treemodelcolumn.h:134:64: required from ‘Gtk::TreeModelColumn<T>::TreeModelColumn() [with T = std::shared_ptr<Glom::LayoutItem>]’ ./glom/mode_design/layout/treestore_layout.h:44:5: required from here /opt/gnome/include/gdkmm-4.0/gdkmm/value_cairo.h:63:36: error: no type named ‘cobject’ in ‘class Glom::LayoutItem’ using CType = typename T::cobject;
Created attachment 362955 [details] [review] Fix the Glib::Value<> specialization for Cairo objects Does this patch fix the problem with Glom? There must be separate specializations of Glib::Value for Glib::RefPtr and Cairo::RefPtr.
I think so, yes, though I have other build problems at the moment, so I can't be sure. Please go ahead and push this to master. Thanks. It does seem better to mention the actual types rather than just the smartpointer that they are in.
Se bug 755037 comment 43 for a discussion of a possible modification of RefPtr.
I suppose the patch in comment 5 fixed the bug.