GNOME Bugzilla – Bug 693932
Property changes not fired for uint, uint16 (and possibly other types)
Last modified: 2017-09-21 12:43:51 UTC
Created attachment 236332 [details] Sample program Vala's code generator doesn't create property change notifications for all types of properties. This means the "notify" syntax can't be used for these types. A sample program is attached. The output of this program is: int changed string changed The expected output is: int changed uint changed uint16 changed string changed From examining the generated code, one can see that the calls to g_object_notify() are missing from the uint and uint16 setters.
I noticed there's a bug in the minimal test case Eric attached. testuint is declared as uint16. testuint does fire a signal when changed to a uint.
int16/uint16/short have no GType, your property is not even a gobject property.
Are you saying this is by design?
It's a limit of gobject. You can see the GType for fundamental types here: http://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-TYPE-INVALID:CAPS
If the "notify::<name>" signal doesn't work for certain types of properties, I think it's a design flaw (or even a bug) that they can be made properties. From a coder's point of view, there's no indication to me from the compiler that there's no signal for one property but there is for another. I'm not 100% up on GType, but couldn't int16/uint16 be registered as types? Would that solve this problem? I would rather Vala not allow me as a programmer to create int16/uint16 properties and avoid this problem in the future than silently allow it and exhibit unexpected behavior.
Created attachment 348796 [details] [review] codegen: Report error if property-type is not compatible with GLib.Object Not all types are supported to be used for "real" Object-properties. Therefore start to report an error instead of not registering it silently.
I think this should not throws an Error, but automatically register a GType for property's type, when is possible. So, if user wants to use an int64 instead an int, because makes more sense for its case, like in database applications, Vala should help by automatically register this data type. This is very common on libgda, it register it's required data types when needed.
> I think this should not throws an Error, but automatically register a GType > for property's type, when is possible. Seeing what impact it has, a warning would be more reasonable. > So, if user wants to use an int64 instead an int int64 is not a good example of yours since it has a GTtype G_TYPE_INT64 and therefore is valid and treated like that.
(In reply to Rico Tzschichholz from comment #8) > > I think this should not throws an Error, but automatically register a GType > > for property's type, when is possible. > > Seeing what impact it has, a warning would be more reasonable. > Many thanks for this. May you can add a suggestion to register this type in order to get a fully working property. > > So, if user wants to use an int64 instead an int > > int64 is not a good example of yours since it has a GTtype G_TYPE_INT64 and > therefore is valid and treated like that. Sure you're right, I mean uint, for example.
Created attachment 358502 [details] [review] codegen: Report warning if property-type is not compatible with GLib.Object Not all types are supported to be used for "real" Object-properties. Therefore start to report a warning instead of not registering it silently.
Created attachment 359598 [details] [review] codegen: Report warning if property-type is not compatible with GLib.Object Not all types are supported to be used for "real" Object-properties. Therefore start to report a warning instead of not registering it silently.
Created attachment 359610 [details] [review] glib-2.0: Use type-id/marshaller-type for (u)int16/(u)short from (u)int32
Attachment 359598 [details] pushed as 6aa600c - codegen: Report warning if property-type is not compatible with GLib.Object Attachment 359610 [details] pushed as a8091c2 - glib-2.0: Use type-id/marshaller-type for (u)int16/(u)short from (u)int32