GNOME Bugzilla – Bug 616127
C generated code is not gseal-compliant
Last modified: 2010-06-19 23:59:33 UTC
Some code generated by valac still uses direct access instead accessor functions. This should be fixed to be compatible with the upcoming GTK+3 release. An example: https://bugs.launchpad.net/deja-dup/+bug/563762
This is a bindings bug. I suggest changing the component to reflect that.
deja-dup should use get_action_area() rather than accessing the field, it's not up to the compiler to generate or not gseal-compliant code. VAPI should use the new has_separator property and remove the public fields.
I think the code generated is correct for the VAPI as it is currently, but maybe it would be better to generate the VAPI with "public Gtk.Widget action_area { get; }" instead? I know I greatly prefer using foo.action_area to foo.get_action_area (). AFAIK vala would interpret that as a read-only GObject property named action-area, but would that assumption case problems anywhere? I think vala always accesses the property using the method (as opposed to g_object_get/set)... If it would cause a problem, perhaps vala could provide some sort of attribute to clarify that a property is not registered with GObject. Maybe we could even reuse [Compact]. If we keep it as is, it should be marked as deprecated when #614712 is resolved.
Another example of GSEAL problems in generated code is Gtk.Widget's various is_* functions. Like is_toplevel(). The current VAPI makes that a GTK_WIDGET_TOPLEVEL() macro call. But ideally it would translate it into a gtk_widget_is_toplevel() call. Granted, this requires GTK+ 2.18, but I've seen valac not be squeamish about introducing new symbols via old calls and thus requiring newer GTK's in the past. I wish I could substantiate that claim. I'm thinking maybe during the tooltip API reorganization in 2.12? I don't recall exactly.
> Another example of GSEAL problems in generated code is Gtk.Widget's various > is_* functions. Like is_toplevel(). The current VAPI makes that a > GTK_WIDGET_TOPLEVEL() macro call. But ideally it would translate it into a > gtk_widget_is_toplevel() call. Indeed GTK_WIDGET_TOPLEVEL() is a deprecated macro that will be removed in the upcoming GTK+3 release.(In reply to comment #4) Is there a plan to make valac GTK-3 (GSEAL) - compilant?
Vala may have bumped dependencies to newer gtk+ versions in the past, but I don't think that was intentional. More likely, someone (possibly me) just ran vala-gen-introspect and the generated bindings were updated to reflect the newer API. I remember at least once a bug being filed (bug 601221) this, with the result being that we ended up hiding a symbol to preserve compatibility. Javier brings up a good point... gtk+ 3 will provide a new pkg-config file (e.g., gtk+-3.0), right? When gtk+ 3 is released we can just generate bindings for them and maintain gtk+-2.0 bindings in parallel to gtk+-3.0. Projects that want to use gtk+ 3 can just switch from --pkg gtk+-2.0 to --pkg gtk+-3.0.
(In reply to comment #3) > I think the code generated is correct for the VAPI as it is currently, but > maybe it would be better to generate the VAPI with "public Gtk.Widget > action_area { get; }" instead? I know I greatly prefer using foo.action_area to > foo.get_action_area (). > > AFAIK vala would interpret that as a read-only GObject property named > action-area, but would that assumption case problems anywhere? I think vala > always accesses the property using the method (as opposed to > g_object_get/set)... If it would cause a problem, perhaps vala could provide > some sort of attribute to clarify that a property is not registered with > GObject. Maybe we could even reuse [Compact]. > > If we keep it as is, it should be marked as deprecated when #614712 is > resolved. I don't really like to invent properties whereas no property is being defined. Just keep get_something() which I don't think it's evil.
commit dcbd995c4c5cdb75c83d64b340700fff716731c3 Author: Jürg Billeter <j@bitron.ch> Date: Thu Jun 10 17:03:48 2010 +0200 Add gdk-pixbuf-3.0, gdk-3.0, gdk-x11-3.0, and gtk+-3.0 bindings
I wouldn't call this fixed yet. While there is indeed a gtk+-3.0.vapi file, it still has bits like: [CCode (cname = "GTK_WIDGET_TOPLEVEL")] public bool is_toplevel (); Which is both not gseal-compliant and will not compile because GTK_WIDGET_TOPLEVEL doesn't exist in gtk3. These functions need to use the gtk3 versions, which are actual functions of the appropriate names.
commit 740bdbbb52a51a2e591eff323f4ddac77fb82500 Author: Jürg Billeter <j@bitron.ch> Date: Sun Jun 20 01:57:33 2010 +0200 gtk+-3.0: Drop sealed fields Fixes bug 616127.