After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 102405 - create_row_drag_icon and custom cell renderer problem
create_row_drag_icon and custom cell renderer problem
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: TreeView
2.4
Other Linux
: Normal normal
: 3
Assigned To: gtkmm-forge
gtkmm-forge
Depends on: 102678
Blocks:
 
 
Reported: 2003-01-03 08:55 UTC by pprooi
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test program which exercises problem, with embedded make file (3.20 KB, text/plain)
2003-01-03 08:57 UTC, pprooi
Details
code which wraps a drawable in a gtk::window (642 bytes, text/plain)
2003-01-05 21:43 UTC, pprooi
Details

Description pprooi 2003-01-03 08:55:37 UTC
(I'm not 100% sure if this is a gtkmm problem or a gtk+ API issue)
 
I'm experimenting with a custom cell renderer derived from
CellRendererText which has its own render_vfunc() method, which works
fine when drawing normal rows.
 
I'm also using drag & drop with a custom cursor using the
create_row_drag_icon() method. The problem is that render_vfunc() has a
refptr to a Window as its first argument, where as the
create_row_drag_icon() method invokes the cell renderer vfunc with a
Drawable.

Because the drawable is wrapped in a RefPtr<GtkWindowObject>, the
creation of this ref pointer fails (it tries to do a <dynamic_cast> from
the drawable to a window object, so we get a null pointer) and an
invalid window reference results.

Is this a problem in the gtk+ definition (which also has a Window as its
argument, not a Drawable, but of course doesn't have the dynamic cast
problem) or in the gtkmm wrapper of the cellrender API, or is there
something else I'm missing ?

I will upload a test program which tickles this problem. It's a bit long
due to all the view setup code.
Comment 1 pprooi 2003-01-03 08:57:55 UTC
Created attachment 13327 [details]
Test program which exercises problem, with embedded make file
Comment 2 Murray Cumming 2003-01-04 11:33:10 UTC
If the problem is just that you can't dynamic_cast<> a
RefPtr<Gdk::Window> to a RefPtr<Gdk::Drawable> then please show us an
example that shows that directly.
Comment 3 pprooi 2003-01-05 21:42:08 UTC
No, the problem is that  gtk_tree_view_create_row_drag_icon() does an
upcast from a GdkPixmap to a GdkDrawable, which the gtkmm code then
tries to wrap into a Gdk::Window (because the Gtk API of render() also
has a GdkWindow argument, not GdkDrawable).

This wrapping gives a null reference because of the dynamic cast from
a Gdk::Drawable to a Gdk::Window that happens in Gdk::Window::wrap().
(this is correct, because window is a subclass of drawable).

The question is either:
- should the wrapping code allow GdkDrawables to be wrapped in
Gdk::Window objects (a comment in the code says the dynamic cast is
there to support multiple inheritance). I don't know if this mixing of
windows and drawables happens in other parts of the GTK.
- or should the gtkmm vfunc wrapper for render() really have a
drawable as its first argument (it would then deviate from the GTK API).
- or should the Gtk API of the render() function be changed to a
GdkDrawable ?

  
I've uploaded a small program which shows the wrapping failure

Comment 4 pprooi 2003-01-05 21:43:59 UTC
Created attachment 13367 [details]
code which wraps a drawable in a gtk::window
Comment 5 Murray Cumming 2003-01-06 18:15:55 UTC
I added the GTK+ bug #102678. It doesn't look like we can fix this
without breaking API/ABI. That's a pain.
Comment 6 Murray Cumming 2003-09-30 17:40:46 UTC
Fixed in gtkmm 2.4 in CVS. Thanks and sorry for the delay.