After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 616127 - C generated code is not gseal-compliant
C generated code is not gseal-compliant
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Bindings: GTK+ GStreamer WebKitGTK+
0.8.x
Other All
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks: 585391
 
 
Reported: 2010-04-18 19:05 UTC by Javier Jardón (IRC: jjardon)
Modified: 2010-06-19 23:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Javier Jardón (IRC: jjardon) 2010-04-18 19:05:24 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
Comment 1 zarevucky.jiri 2010-04-22 08:33:32 UTC
This is a bindings bug. I suggest changing the component to reflect that.
Comment 2 Luca Bruno 2010-04-24 09:11:59 UTC
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.
Comment 3 Evan Nemerson 2010-04-28 01:37:08 UTC
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.
Comment 4 Michael Terry 2010-05-05 01:43:01 UTC
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.
Comment 5 Javier Jardón (IRC: jjardon) 2010-05-05 02:18:13 UTC
> 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?
Comment 6 Evan Nemerson 2010-05-05 03:52:52 UTC
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.
Comment 7 Luca Bruno 2010-06-02 15:32:51 UTC
(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.
Comment 8 Evan Nemerson 2010-06-18 23:06:28 UTC
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
Comment 9 Michael Terry 2010-06-19 04:26:59 UTC
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.
Comment 10 Jürg Billeter 2010-06-19 23:59:33 UTC
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.