Created attachment 264941 [details] [review]
Add a way to register GParamSpec constructor function for fundamental types

from outside PyGObject

There is no test, I am going to make use of it in gst-python but would like to make sure you agree on the
principle first.

As a starting point, it would be helpful to have small mockup of how this looks from the Python side. I guess it would be as simple as using GObject.Property with a type set to Gst.IntRange or something along those lines?

class Foo(GObject.Object):
    irange = GObject.Property(type=Gst.IntRange)


My aversion towards the proposal is I was hoping to move GObject.Property as pure Python dispatcher which would only create instance for basic ParamSpec types. Class registration would then look for ParamSpec instances in a classes dictionary and use them for GObject property registration. Then something like the following could work:

class Foo(GObject.Object):
    irange = Gst.ParamSpecIntRange()

The advantage is you wouldn't need a custom Python C binding. But I think we need fundamental support to be able to inspect the ParamSpecIntRange type hierarchy:

>>> Gst.ParamSpecFraction.mro()
    [gi.repository.Gst.ParamSpecFraction,
 gi.Struct,
 gobject.GPointer,
 builtins.object]


(GObject.ParamSpec needs to be a base class in there).

See also:
https://bugzilla.gnome.org/showdependencytree.cgi?id=685275&hide_resolved=1

(In reply to comment #2)
> But I think we need fundamental support to be able to inspect the ParamSpecIntRange type
> hierarchy:
> 
> >>> Gst.ParamSpecFraction.mro()
>     [gi.repository.Gst.ParamSpecFraction,
>  gi.Struct,
>  gobject.GPointer,
>  builtins.object]
> 
> 
> (GObject.ParamSpec needs to be a base class in there).


On further inspection it looks like there might be some GI parsing problems with GstParamSpecFraction:

>>> Gst.ParamSpecFraction.__gtype__
    <GType void (4)>

>>> Gst.ParamSpecFraction.__gtype__.parent
    <GType invalid (0)>


But there also exists a "Gst.ParamFraction":

>>> Gst.ParamFraction.mro()
    [gi.repository.Gst.ParamFraction,
 gi.repository.GObject.ParamSpec,
 builtins.object]

>>> Gst.ParamFraction.__gtype__
    <GType GstParamFraction (38657344)>

>>> Gst.ParamFraction.__gtype__.parent
    <GType GParam (76)>


Note that GObject ParamSpecs only expose a single structure:

>>> GObject.ParamSpecFloat.mro()
    [gi.repository.GObject.ParamSpecFloat,
 gi.repository.GObject.ParamSpec,
 builtins.object]

>>> GObject.ParamSpecFloat.__gtype__
    <GType GParamFloat (37785296)>

>>> GObject.ParamSpecFloat.__gtype__.parent
    <GType GParam (76)>

>>> GObject.ParamFloat
AttributeError: ...


Assuming there is a GI setup problem with GstParamSpecFraction, it seems like there is the possibility to get something like the following working without requiring a custom Python C binding:

class Foo(GObject.Object):
    frac = Gst.ParamSpecFraction()

(In reply to comment #3)
> On further inspection it looks like there might be some GI parsing problems
> with GstParamSpecFraction:

Some unfortunate magic which shows why GObject.ParamSpecXx shows a single unified structure:

https://git.gnome.org/browse/gobject-introspection/tree/giscanner/gdumpparser.py?id=1.39.0#n91

https://git.gnome.org/browse/gobject-introspection/tree/giscanner/gdumpparser.py?id=1.39.0#n204


Creating the Gst ParamSpecs work, just with a bit of naming confusion:

>>> foo = Gst.param_spec_fraction('foo', 'foo', 'foo', 0, 1, 100, 10, 3, 1, 0)

>>> foo.__gtype__
    <GType GstParamFraction (38657344)>

>>> foo.__gtype__.parent
    <GType GParam (76)>


So it seems likely things can work well and be future proof with either of the following scenarios:

class Foo(GObject.Object):
    frac = Gst.param_spec_fraction('frac','frac','frac',0,1,10,10,3,1,0)

or if we wanted to get something working in the immediate term and allow for some bike shedding of the convenience to get it right:

class Foo(GObject.Object):
    __gproperties__ = {
       'frac': Gst.param_spec_fraction('frac','frac','frac',0,1,10,10,3,1,0)
    }

-- 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/pygobject/issues/60.