Created attachment 119937 [details] [review]
pair class structures

Initial patch.  I didn't fix up the tests for this yet since it will conflict with the versioning patch.  Let's review and land this patch after versioning.

Mike is basically right here.
Jürg and I discussed this today and this is the conclusion we came to:

Class/Iface structs should be defined, but not as a toplevel record, rather as a "sub tag" record of the <class>, eg:

<class name="Action">
  <record name="Class" c:type="GtkActionClass">
    ...
  </record>
</class>

For the functions taking or returning a GtkActionClass parameter we'd just send in a Gtk.Action.Class which would resolve to the struct above.

This probably need typelib changes to allow a "Class" struct as part of the ObjectBlob and a slight change in the "." resolver to look at it.

Hmm...I'm wary of using '.' in names in the typelib since they are used already for the "namespace.name" notation.

One thing we could do instead is use '/' internally.  So in the typelib it would be namespace "Gtk", name "Action/Class".  Of course bindings don't have to expose it this way - so say pybank could know to turn "Gtk.Action.Class" into g_irepository_find_by_name (NULL, "Gtk", "Action/Class").

I'll take this one.

Created attachment 120690 [details] [review]
ignore class structs

This updated version of the earlier patch gets the GIR looking right.  Needs nontrivial work in girparser.c to parse and generate, and would conflict/overlap greatly with bug 555960.

Johan said this broke the drawable.h test - we remove TestPixmapObjectClass.  Does anyone remember what this was testing?

Colin: IIRC there are parameters referencing the pixmap object class. 
But I can't find these on my system after a quick grep. So maybe it's not a big deal after all. Just make sure that the gtk+ typelib compiles after these changes and we should be fine.

Looking at this one again (after committing the nested struct union bits), I'm actually now not sure about the proposal to put <record> under the main <class>.  The reasoning here is that I now think it somewhat conflicts with the nested struct/union support, in that a GIR consumer has to differentiate between the unique class record and any other structure that might appear inside classes.

For example (ok, this is unlikely) if someone did:

typedef struct {
  GObjectClass parent;

  struct {
    int x;
    double y;
  } FooWidgetStaticData;

} FooWidgetClass;

It also feels backwards in that the class struct is under <record>, whereas the instance struct is under <class>.

How about a unique name for this concept like <class-record>?

    <class name="Widget"
           c:type="GtkWidget"
           parent="Object"
           abstract="1"
           glib:type-name="GtkWidget"
           glib:get-type="gtk_widget_get_type">
      <implements name="Atk.ImplementorIface"/>
      <implements name="Buildable"/>
      <class-record>
        <field name="parent_class">
          <type name="ObjectClass" c:type="GtkObjectClass"/>
        </field>
        <field name="activate_signal">
          <type name="uint" c:type="guint"/>
        </field>
        <field name="set_scroll_adjustments_signal">
          <type name="uint" c:type="guint"/>
        </field>
        <callback name="dispatch_child_properties_changed"
                  c:type="dispatch_child_properties_changed">
          <return-value transfer-ownership="none">        
      </class-record>
      ...

Also in the .typelib, I propose this appear as Gtk.Widget/Class.  

While I argued above that merging the class record along with nested ones was less than optimal, here I don't think we need to support someone naming their nested structure "Class".

Perhaps just an attribute, since it's just a normal record, eg:

Either:

  <class name="Widget" ...> 
    ...
    <record glib:is-object-class="1">
    ...
  </class>

Or

  <class name="Widget" ...> 
    ...
  </class>
  <record glib:object-class="Widget">
    ...
  </record>

I think the last one is actually pretty nice.
We could just save the object-class as an additional offset in the file
and add:

    GIInterfaceInfo* g_struct_info_get_object_class(GIStructInfo *info);

Does that sound reasonable?

But normally you'd want to go from instance->class, not class->instance, no?  Actually, bad terminology here.  Let's say "class info"->"class C layout" instead.

So the API would be

GIStructInfo *g_object_info_get_class_layout (GIObjectInfo *info);

Created attachment 127988 [details] [review]
Bug-551738-Associate-classes-with-their-structs

+        print "PAIR %r => %r" % (class_struct, pair_class)

Pay no attention to the debug prints behind the curtain.  They no longer exist.

Comment on attachment 127988 [details] [review]
Bug-551738-Associate-classes-with-their-structs

>diff --git a/giscanner/glibtransformer.py b/giscanner/glibtransformer.py

>+        print "PAIR %r => %r" % (class_struct, pair_class)

We can probably live without that print.

The rest looks okay, I haven't looked very detailed at it, should probably be good enough for now.

I'd say commit it

[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]