As a workaround for now you need to use GdkPixbuf.Pixbuf.new so that the pixbuf gets initialized correctly otherwise you are trying to fill a struct that has a NULL buffer.  You can see the examples here:

 http://git.gnome.org/browse/pygobject/tree/demos/gtk-demo/demos/pixbuf.py

We should provide an override which calls new when constructing a Pixbuf so I'm leaving this open.  However calling it without parameters would be wrong since it needs at least height and width info in order to know how much memory to allocate to the buffer.  We could default to RGB color space since that is currently the only supported option.  Not sure if we should default to alpha or no alpha.  8 bits per sample seems to be a sane default also.

Actually the code that I tried was

p = GdkPixbuf.Pixbuf(colorspace=GdkPixbuf.Colorspace.RGB, has_alpha=False,
      bits_per_sample=8, width=1, height=1)
p.fill(0)

which looked like it should work (and it does, up until the fill() call).

Is using Class.new() the "official" way for calling constructors in PyGObject? If so, I guess this is just a documentation bug. Although, I wonder how it's supposed to work when you want to create a subclass.

The new apis are supposed to be used only as convenience constructors but some older objects incorrectly configure themselves inside the new constructor.  The regular constructor in PyGObject uses g_object_new to construct the object and assign properties which should be the correct way to construct an object.

Reassigning to gdk-pixbuf.  This is a case where a gtk object is not compatible with g_object_new because it does work inside of the convenience constructor instead of simply setting properties and then configuring the object based on the properties in the next instantiation stage.  In order for objects to be 100% compatible with introspection they need to be able to setup a complete instance through g_object_new and the properties that are set.

I'm sorry, but

from gi.repository import GdkPixbuf
p = GdkPixbuf.Pixbuf()
p.fill(0)

is just not a meaningful use of the gdk-pixbuf api.

I don't think it is worth rewriting all gdk-pixbuf constructors, just to make this 'work'.

So is this a binding issue? I don't know how it works in C and other bindings, but currently in PyGObject I can't think of a way to subclass Pixbuf and then correctly create an instance of that subclass using the new() constructor.

from gi.repository import GdkPixbuf
class MyPixbuf(GdkPixbuf.Pixbuf):
  pass
MyPixbuf.new(GdkPixbuf.Colorspace.RGB, False, 8, 100, 100)

TypeError: Pixbuf constructor cannot be used to create instances of a subclass

Why would you create a subclass of GdkPixbuf ?

IIRC (not my code) it was for matrix operations or something similar. It can be moved outside the class so not really a big deal. But if it's really not possible to subclass GdkPixbuf then it should at least be documented.

I've added this to avoid the crash:

commit 049787302b6d6d6c24665b36db290f403c3540bc
Author: Bastien Nocera <hadess@hadess.net>
Date:   Fri Oct 24 11:08:45 2014 +0200

    lib: Make gdk_pixbuf_fill() fail if pixbuf doesn't have storage
    
    This fixes a crash when using Python's "new" keyword instead of the
    constructors exported by GdkPixbuf.
    
    See https://bugzilla.gnome.org/show_bug.cgi?id=658702

But I don't know how I could make Python's new keyword invoke gdk_pixbuf_new() instead of just instantiating an empty GdkPixbuf.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/28.