AutoGenerated File Errors

[archanox]

I've been trying to incorporate the Gir.Core changes within my project as a submodule, but i'm getting a horrendous amount of formatting errors. Non-build breaking. But nevertheless bothersome.

As an example,

[DllImport("libglib-2.0-0.dll", EntryPoint = "g_async_queue_length_unlocked")]
public static extern int length_unlocked(IntPtr queue);

What would be the ideal way to tackle this, and upstream?

Preferably, I would rather see "LengthUnlocked" rather than something written in snake case.
But I have included a GlobalSuppressions.cs file to suppress the errors for each referenced project.

Another contentious point is that SonarQube is reporting, this "Major Code Smell".
https://rules.sonarsource.com/csharp/tag/pitfall/RSPEC-4200
Just wondering what everyone's thoughts are here?

[archanox]

Obviously this will get swept under the rug when the nuget packages are ready. (Out of sight, out of mind 😛)
But I'm more than happy to help with remedying these issues, if I'm clear on how we wanna approach this.

[badcel]

Actually we do not want to have those snake case methods. The scriban template for GLib is not yet on par with those of GObject. If you check for example the Gtk3 Button.Generated.cs you will see that there is a region called Native including s.th. like this:

protected static new class Native
{
   ...
    
    [Obsolete("")]
    [DllImport("Gtk", EntryPoint = "gtk_button_get_alignment")]
    public static extern void get_alignment(IntPtr button, out float xalign, out float 
}

The target is to hide the low level api bindings in a protected class in the first step. This code is currently auto generated. To make those methods available to the public the Button class has to have a function calling into this code. This code is currently not generated. For now we write those "bindings" manually but want to get rid of it. We just do it to get a feeling of the needed functionality for a generator rewrite (#100) which would hopefully include generating code for properties and methods.

This will remove the code smell, too.

So this should be solved with the generator rewrite. A first step would be to move the generated GLib methods into a internal static class Native like for GObject or in struct.sbntxt.

This would only need a small change in struct_as_class.sbntxt in the Generator project. If some of those methods are already needed a call from the public api to those hidden methods must be written manually. If you want to help us out you could go ahead with this. A PR is very welcome.

[badcel]

The native class for GLib is added in #207.

[mjakeman]

Thanks for pointing this out.

That's actually a bug with our generation, as the internal snake_case API shouldn't be publicly accesible, so AsyncQueue obviously isn't generating correctly. Normally we hide these functions inside a static class called Native, and then hand-write methods which 'wrap' the C API.

A quick overview of the project structure for reference:

We currently have two "layers" in the project. The autogenerated layer is comprised of files such as SomeConstruct.Generated.cs, while the managed layer would be SomeConstruct.cs. Anything checked into this repo is part of the managed layer, while the autogenerated layer is the internal private API.

At the moment, the bindings are largely hand-written. We're looking at progressively automating more of it down the line, but we want to get the core GObject<->C# part down first before commiting to anything.

If you'd like to help us add more of the API, Window.cs is a good starting point for how our managed layer is supposed to look. We wrap three things by hand at the moment:

• Properties (in the GObject sense, using Property Descriptors)
• Methods (a nice, safe managed wrapper around the internal API)
• Constructors

---

@badcel Once again, you've beaten me to it 😅

[badcel]

@firox263 Yeah I wondered if you are writing in parrallel 😉 But it is great that our answers complement each other 👍