Created attachment 8221 [details] [review]
Do GType initialization at construction time.

I don't know if I like this approach.  It could easily have
unpredictable results with multiple levels of subclassing:
  class MyWidget(gtk.Widget):
      ...
  class MyWidget2(MyWidget):
      ...

What happens if you instantiate MyWidget2 first?

The correct way to handle this is probably to define a special
metatype for GtkWidget derivatives (which is luckily a lot easier and
intuitive with 2.2 than previous versions).  By overriding __call__ on
the metatype, we get control over subclassing of GObjects.

Also in future, could you send your patches in unified diff format? 
It is a lot easier to read than -c format.  The easiest way to
remember this is to add the following line to your ~/.cvsrc file
(create it if you don't have one already):
  diff -up

Hmm... Yes, if you create an MyWidget2 object first you probably have
a problem with my approach. I "need" a simple structure to inherit
from GObject for DiaCanvas2. I've been reimplementing the Python
wrapper and it should be possible to create new canvas items by means
of inheritance. I do not like the idea of creating a special class for
every canvas item just to make it possible to create a python
deriviate... Also I have created an interface for grouping canvas
items it would be nice if you can assign the interface only if the
canvas item needs it. (it should be possible to create a TreeModel too
by using 'class MyClass(gobject.GObject, gtk.TreeModel)', that would
be nice IMHO)

What exactly do you mean by "metatype"?

I'll take a look at __call__.

Thanks for the cvs diff hint.

Arjan

(reopenning so I don't lose it.  We have enough information to know
what the enhancement request is).

As for examples of metaclass usage, I actually meant overriding
__init__ rather than __call__.  Here is a simple example of creating a
metatype in pure python code:

  class MyType(type):
      def __init__(self, name, bases, members):
          print "Create type:", (name, bases, members)
          type.__init__(self, name, bases, members)

  class MyBase:
      __metaclass__ = MyType

  class MySubclass(MyBase): pass

If you run this code, it should output the following:

  Create type: ('MyBase', (), {'__metaclass__': <class
'__main__.MyType'>})
  Create type: ('MySubclass', (<class '__main__.MyBase'>,), {})

By using a custom metaclass, we get full control over how people
subclass GObjects.

Indeed this is what I call elegance. This makes it trivial to add
(g)interfaces to a Python class and we can easely check for
inheritance of multiple GObjects. Great!

Do you know how to write such a thing in C? I don't have a clue, but
can give it a try anyway...

Need to work out when we want to create a C level GObject subclass. 
It isn't obvious that you always want to create one.  How would we
decide when to create a subtype?

Is this still being worked on or is it dropped?

/me would also like to get type_register moved away.

I still want it moved away...

Maybe we should add a function ala:

class A:
    def fun():
        pass
    fun = staticmethod(fun)

In pyton2.2 they do the same thing for properties and some other 
stuff.

We then do something like:

def A(gobject.GObject):
    __gsignals__ = { ... }
    __gproperties__ = { ... }
    isGObjectClass()
    
    def __init__(self):
        gobject.GObject.__init__(self)

I know this is basically moving some functionallity around, but we 
can do the __gobject_init__ and type_register() stuff in that one 
function on class level, which makes it look more python-ish.

... just a though...

mass reassign of open pygtk and gnome-python bugs.

*** This bug has been marked as a duplicate of 129843 ***