Improve struct generation

[badcel]

Differentiate struct types and render them as appropriate:

Todo

• Support opaque atribute #747
• Support boxed opaque records (Support opaque records #908)
• Support unboxed opaque records (Support opaque untyped records #942)
• Support boxed record (Support boxed records #965)
  • Value GetStringArray: ensure correct type before accessing pointer (GValue.GetStringArray: Ensure type before accessing data #991)
  • Add field access including tests (TypedRecord: Add field access #994)
• Support unboxed record (Add support for untyped records #1013)
• Support foreign untyped records (Support foreigen untyped records #1029)
• Remove legacy record code (Remove legacy record code #1028)
• Write unit tests for GLib.VariantIter (regular record) (Test: Add Variant test which uses VariantIter and VariantBuilder #1033)
• Ensure there are parameterless constructors for typed and untyped record types to be able to create new instances of them even if no constructor is defined on the C side. Add tests to ensure the constructors are present. Not needed for opaque record types as those have constructors defined. (Typed Record: Add parameterless constructor #1002)
• Render class property definitions for boxed properties in a class which are a a records (typed, opaque, foreign) (Generator: Generate property descriptors for boxed records #1031)
• create a new record type "foreign typed record". Those types can't have a managed handle, can't have a internal struct and can't have a parameterless constructor, have no methods, constructors, ... (they are manually implemented) but are registered in the type system (Support foreign records #1010)

---

For non opaque records: Consider to somehow use ref struct to avoid memory allocations?

---

Verify if we can differentiate between different types of structs to improve the overall struct handling.

E.g.:

• Use a class in the public API for C structs which are opaque or class structs
• Use a struct in the public API for C structs which are only transporting data into / out of an object

Verify: If we handle structs as structs could they be passed as "ref" to / from native code? How or those structs freed? Can those structs be defined as public ref struct xxxx?

Rust is implementing struct fields manually.

---

Is it useful to differentiate between Gdk.ColorRef and Gdk.Color?

In this way ColorRef could have a method which converts its pointer in an actual struct.

If it is not useful it would be possible to use generated properties on the structs to access it fields without the need to introduce the actual struct to the user. The properties would hide the struct.

---

Verify:

• In parameter modifier
• Out parameter modifier
• ref parameter modifier

---

As there is some kind of memory management available for boxed structs this issue should perhaps only be applied for those record types. All other records should be generated like they are now. Meaning adding new converters and so on only for records which are a boxed type.

https://docs.gtk.org/gobject/boxed.html#boxed-types

JavaScript docs: http://webreflection.github.io/gjs-documentation/GObject-2.0/GObject.TYPE_BOXED.html

The internal namespace connects the public API to the native C world. Structs are currently generated in the internal namespace. Verify if the struct can be generated in the public namespace with private fields. Public properties could be generated for all fields which should be part of the public API. The aforementioned parameter modifiers could help to avoid allocations.

---

Boxed types in GLib: https://gitlab.gnome.org/GNOME/glib/-/blob/main/gobject/gboxed.c

If there is no information in the gir regarding boxed types this should probably as easy as possible to add manually per type in the bindings.

Alternatively only support structs which support the new copy/free annotations. If a struct does not have those annotations there could be some fallback implementation which makes a copy for each returned struct to avoid referencing memory which could freed by c in the meantime.

Example: a struct is returned (as pointer or ref) if the free/ copy methods are available we use those to copy / increase ref count (depending on c implementation). If not available we make a copy of the struct and pass it on.

Every record which has a get type function is a boxed type. A record without a get type func is just a struct. A boxed type can use g_boxed_copy.

[cameronwhite]

Looking at what rust's bindings did, they seemed to use a similar approach to what we're currently doing (wrapper around a handle), but with some accessors for the fields
https://docs.rs/gdk/latest/src/gdk/auto/rectangle.rs.html#7-15
https://docs.rs/gdk/latest/src/gdk/rectangle.rs.html#22-24
Although I think the BoxedInline may avoid the extra heap allocation

However the cairo bindings are different, possible from being manually written https://docs.rs/cairo-rs/latest/src/cairo/rectangle\_int.rs.html#12-17

I also noticed from this that g_boxed_free() could be used for cleaning up records without having to figure out the correct free function (https://docs.gtk.org/gobject/boxed.html), and it seems like it would even work for the foreign records from Cairo (https://github.com/freedesktop/cairo/blob/master/util/cairo-gobject/cairo-gobject-structs.c)

[PlatinumLucario]

@badcel Since #907 has been merged, does the struct generation have any new issues? Just curious

[badcel]

Nothing happened till now. The pr was just for preparation of struct generation as it only fixed #747.

[badcel]

All points collected in the initial issue are handled (see linked pull requests).