Re: signals versus vfuncs

[Christof Petig <christof petig-baender de>]

muppet schrieb:
> The CellRenderer is a major PITA because there are no signals for the
>  four vfuncs you need to be able to override.

You have to learn how to master vfuncs on top of mastering signals.
Since both methods peacefully coexist in c++ (virtual functions vs.
SigC++) for some time there has to be a reason for both of them.

> and it's not just for gtk2-perl.  pygtk solved the CellRenderer 
> problem by creating a new subclass from which to derive cell 
> renderers, but you lose the ability to derive from existing C 
> renderers (a real pain if you want to have a text renderer, for 
> example).

Gtkmm provides C++ classes for every CellRenderer shipped with gtk to
derive from. Once you use a custom gtk+ renderer, you loose that
convenience of course.

> i'd like to understand the rationale behind not having signals for 
> every vfunc before i start complaining about it; perhaps there's a 
> really good reason i hadn't thought of, or perhaps the C developers 
> don't know what the scripting language developers go through. 
> <managerspeak> i wanted to start a dialogue. </managerspeak>  gtk+ is
>  the most binding-friendly widget set i know of, i'd like it to stay 
> that way.

If I sum you up correctly for perl derivation (which is what vfuncs
need) is much more inconvenient than signal connection (which not
involves any derivation (or custom classes) at all).

I feel that because of the overhead [in calling signal handlers (much
more than just an indirect jump) and creating signal handlers (enum,
register, provide a default implementation and an activate function for
it)] the gtk+ developers tend to avoid signals wherever possible.

Adding a vfunc is simply a struct member, an initialization, and a
default implementation (about half of the work for a signal?).

Rule of thumb seems to be:
- if the implementation (callback) is likely to be changed by an
ordinary user of the widget it gets a signal.
- if more than one callback at a time is sensible it _has_ to be a signal
- if the implementation is only likely to be changed by a different sort
of widget (like with the cellrenderers) derivation is sensible and a
vfunc is enough
- if more than one callback at a time (e.g. rendering) is nonsense it is
likely to get a vfunc

Perhaps widget derivation on the fly (take a base widget and override
just some vfuncs without adding member variables (extending the instance
struct)) should deserve an API ???

e.g.
  GType modify_type(GType base, const char *new_type_s_name, <list of
vfuncs and implementations>);
  void gobject_change_type(GObject *, GType new_type);

This way overriding vfuncs would be _much_ easier (one to two function
calls instead of all the usual derivation dance).

In C++ you get it medium-easily :-/ by deriving from the gtkmm widget
and doing some Glib::ObjectBase magic *) in your ctor.

> we can't just call a method named "do_something" because we'd get an 
> infinite loop.

If I understand correctly that's just the problem that explicit
namespace decoration

void Derived::some_vfunc()
{  ...
   Gtk::Base::some_vfunc();
}

solves in C++.

   Christof (who hardly knows anything but gtkmm)

*) there might be some documentation besides
examples/cellrenderercustom/cellrendererpopup.cc for it but I never
found one.
And implementing interfaces from scratch is even more awkward
(see custom treemodel problems and
Glib::Object(Glib::ConstructParams(myclass.init(), (char*) 0))) - I
think this is due to the need for
Gtk::TreeModel::add_interface(get_type());].