A Sex, 2004-06-25 �s 19:26, John Ehresman escreveu:
> Lorenzo Gil Sanchez wrote:
> > You are right that bug is related with the problem we are discussing
> > here but please note that even if that bug is solved we still can't
> > override GTK+ C methods in Python which is what I understand stop us
> > from having *full* support to subclass Widgets.
>
> You're correct that this bug is related to something a bit different --
> GInterface support. The bug for this is
> http://bugzilla.gnome.org/show_bug.cgi?id=129032 There is some support
> for interface support in CVS, but it still needs work before it can be
> used to override methods defined in a superclass.
Well, it is not exactly the same thing, but almost. The issue is that
of overriding virtual methods defined the object class structure. For
example:
struct _GtkCellRendererClass
{
GtkObjectClass parent_class;
/* vtable - not signals */
void (* get_size) (GtkCellRenderer *cell,
GtkWidget *widget,
GdkRectangle *cell_area,
gint *x_offset,
gint *y_offset,
gint *width,
gint *height);
(...)
Sometimes, these virtual methods are also defined as signals, and
signal emission automatically calls the function pointer. Those methods
can be overriden in python. But the methods that are not dfined as
signals cannot be overriden at the moment.
The similarity with the GInterfaces problem is that both need a
different type of wrappers. Right now, the code generator creates
Python->C methods. GInterfaces and overriding virtual methods need the
reverse wrappers, C->Python. As these cannot be automatically generated
(unless someone skilled makes a new code generator), we would have to
manually program all these methods. Not an easy task... :|
Regards.
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
