GNOME Bugzilla – Bug 663914
Clutter.Animator() does not work for 'x'/'y' properties
Last modified: 2018-08-17 19:17:49 UTC
Created attachment 201285 [details] test python script to reproduce the observed behaviour I am porting a pyclutter app to pygobject. Now i get these warnings: Warning: g_value_set_float: assertion `G_VALUE_HOLDS_FLOAT (value)' failed This happens when i use the Animator to change 'x'/'y' property of an Actor. The animation does not work then, the actor does not move. With other properties like scale-x/y this problem does not occur. I suspect this has something to do with x/y being gfloat, e.g. scale-x/y (which works) is gdouble. I used jhbuild with moduleset "gnome-suites-core-3.2" to build the modules "gtk+", "clutter" and "pygobject". "git describe" in checkout/gnome/pygobject says "3.0.2-11-g4f63721". Attached is a test script to reproduce this. The files __doc__ does also contain the output it produces.
(In reply to comment #0) > Created an attachment (id=201285) [details] > test python script to reproduce the observed behaviour > > I am porting a pyclutter app to pygobject. Now i get these warnings: > > Warning: g_value_set_float: assertion `G_VALUE_HOLDS_FLOAT (value)' failed I guess you need to pass a GValue with an specific type, like it's done in: http://git.gnome.org/browse/pygobject/tree/tests/test_gi.py#n1007 Otherwise PyGObject will have to guess what type the API expects and it will get it wrong sometimes.
That does indeed work. Thanks.
(In reply to comment #2) > That does indeed work. Thanks. The it would be good to either close this bug, or move it to clutter with a suggestion for improving the bindings, as bugzilla isn't a support forum :)
I only filed this as a bug because someone on IRC suggested I do so. Since it turns out not to be a bug at all, sure this can be closed. On the other hand I agree that the bindings could be improved in this regard at least from a user POV. The solution feels like a low level workaround in Python.
Ah, yes this can be fixed in clutter by providing overrides, however there really is no good way to fix generic interfaces that take GValues when dealing with similar types such as float and double. The only fix when dealing with GValues is to specify the type explicitly. Variants have a slightly better way of dealing with this by giving type signatures but in the end of the data Variants and GValues both need to be wrapped so we know how to encode. There is another "fix" which would be for the APIs to be a bit looser in what types they accept. In other words if an interface expects a float but gets a double it could decide to cast and throw an error only if there is an overflow. That is up to the clutter devs though.
I don't think it's Clutter's role to decide this. we use the type of the property to initialise the GValue, and we use the GValue API after that; if we decided to do some sort of coercion on the type then we'd also have to do int-to-float, int64-to-float, etc. and it's not always doable in a language-neutral way. Python doesn't have a concept of float/double, so it should be the one that does the coercion when it gets to the C level, given that it's the layer that can actually raise an exception if the range is not valid (GObject will either silently discard it, with or without a warning on the terminal).
(In reply to comment #6) > I don't think it's Clutter's role to decide this. we use the type of the > property to initialise the GValue, and we use the GValue API after that; if we > decided to do some sort of coercion on the type then we'd also have to do > int-to-float, int64-to-float, etc. and it's not always doable in a > language-neutral way. > > Python doesn't have a concept of float/double, so it should be the one that > does the coercion when it gets to the C level, given that it's the layer that > can actually raise an exception if the range is not valid (GObject will either > silently discard it, with or without a warning on the terminal). I think that when J5 said Clutter, he meant pyclutter. It cannot be in PyGObject itself because it's specific to the API that is being bound and PyGObject cannot depend on every API it can be used to call.
The issue is clutter expects a certain type but the interface has no way of exporting that unlike the properties interface which works because we special case set_property. Unfortunately for any other interface which takes properties there is no way for introspection to know that it should grab the property type to know how to marshal it. Perhaps we should have a property annotation but then how would list of properties work? Python can't do anything here if it doesn't know the parameters are properties, however an override should be able to handle wrapping the GValue. Failing that users will have to understand the GValue API in order to use the interface.
Two other "fixes" which we used in python-dbus were: 1) Create a wrapper object for each supported type - e.g. glib.Float(2.1) glib.Int64(999999999999999) which our marshallers could explicitly cast. This is much nicer than the GValue API but in dbus we felt it was a bit verbose. 2) allow passing of type strings - e.g. _signature="sf" - this is similar to how the Variant API works and we would use the Variant format for type representation. I like option 1 as the better of two evils because it is easier to implement and is only used for edge cases. Option 2 would tie in nicely with Variants and D-Bus but isn't immediately readable by the casual pygobject developer. In any case, I don't have any time to implement this but if someone wanted to I can tell them where to look.h
re-assigning, sorry for the spam.
gnome-phone-manager is not under active development anymore since 2015. Its codebase has been archived: https://gitlab.gnome.org/Archive/pyclutter/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.