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 147768 - Arguments of virtual CellRenderer member functions don't correspond correctly to their C counterparts
Arguments of virtual CellRenderer member functions don't correspond correctly...
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: TreeView
2.4
Other All
: Normal normal
: 3
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2004-07-17 13:52 UTC by ÉRDI Gergõ
Modified: 2011-02-22 12:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description ÉRDI Gergõ 2004-07-17 13:52:23 UTC
Gtk::CellRenderer has a number of virtual member functions that don't have
correct signatures.

A common problem is using 'const' references for in/out arguments, like in
start_editing's cell_area argument, which is const in GTKmm, yet it can
theoretically be used to move the editing widget. Unfortunately, I don't know of
a way to extract which arguments are in and which are in/out from the C sources.

There's also the problem of Gtk::CellRenderer::render_vfunc using a
Gdk::Drawable (correctly), but Gtk::Cellrenderer::render uses Gdk::Window, thus
requiring a reinterpret_cast if you want to implement cellrenderers by using
existing ones.
Comment 1 Murray Cumming 2004-07-27 07:39:11 UTC
A patch would show the specific problems, and could be applied at the next (not
yet planned) ABI break.

Also, a documentation patch would be very welcome for now. It would tell people
about these problems and how to work around them.

> but Gtk::Cellrenderer::render uses Gdk::Window

Yes. this seems to be a problem in the GTK+ API - the documentation says
"@window: a #GdkDrawable to draw to". I seem to remember filing a GTK+ bug/patch
about something similar once. Maybe we can/should fix that in GTK+ (it would not
break ABI/API).

In gtkmm 2.6, maybe we can add an overload for this method, if it does not make
it ambiguous. I don't think we can remove/change the method without breaking
API/ABI.

The Gtk::Widget vfuncs have some similar const problems.

Comment 2 Murray Cumming 2004-10-07 09:00:55 UTC
We still need to hear about the specific problems, ideally via a patch.
Comment 3 Murray Cumming 2005-11-24 08:47:52 UTC
This would still be nice to have.
Comment 4 Murray Cumming 2006-09-11 17:32:06 UTC
Oh go on.
Comment 5 Murray Cumming 2011-02-22 12:00:21 UTC
(In reply to comment #0)
> like in
> start_editing's cell_area argument, which is const in GTKmm, yet it can
> theoretically be used to move the editing widget.\

It's const in the C API now too, though I don't know when they fixed that:
http://library.gnome.org/devel/gtk/unstable/GtkCellRenderer.html#GtkCellRenderer-struct

GtkCellEditable *  (* start_editing)                   (GtkCellRenderer      *cell,
                                                          GdkEvent             *event,
                                                          GtkWidget            *widget,
                                                          const gchar          *path,
                                                          const GdkRectangle   *background_area,
                                                          const GdkRectangle   *cell_area,
                                                          GtkCellRendererState  flags);


> There's also the problem of Gtk::CellRenderer::render_vfunc using a
> Gdk::Drawable (correctly), but Gtk::Cellrenderer::render uses Gdk::Window, thus
> requiring a reinterpret_cast if you want to implement cellrenderers by using
> existing ones.

They both take a Gtk::Widget now, in gtkmm 3.

So I think I can close this finally, unless someone has some specific problem to mention.