Are you able to add custom .gir files to generate bindings for when built?

[foxyfocus]

How would I go about doing this? I am trying to add Gtk4LayerShell-1.0.gir, https://github.com/wmww/gtk4-layer-shell? I am on Linux, by the way.

[badcel]

Hi,

this is actively worked on by @adamreeve (See #1078).

If the work is finished there will be a nuget tool which can be used to create new bindings.

As this tool has not yet landed there are two ways going forward:

• If the desired library is already part of the GNOME flatpak SDK it is easy to add to Gir.core directly and can be maintained here directly.
• Otherwise you need to create your own binary:
  • Checkout the latest GirCore release (including git submodules).
  • Add the Gir file of your desired library into the Gir platform folder it is made for (under "ext/gir-files")
  • Add a new folder into the Libs folder matching the name of your Gir file exactly.
  • Add some minimal project structure (compare GtkSource-5)
  • Add the name of the Gir file to GenerateLibs.fsx either as a commandline arg or inside the script
  • Call the script to generate the whole set of bindings including your library.
  • As you checked out a GirCore release the binary will be compatible to the official binaries.

Please be aware that your library can have some API which is not yet supported by the generator and it would get skipped or the generation could even fail. In this case bug fixes are very welcome here to improve the code.

This happens regularly for the already supported libraries as they progress. It is not seldom as the generator only supports things which are needed. Supporting every kind of possible parameter combination would be extremely time consuming before any release would be possible.

If you have success and like what you were doing: Any helping hand is welcome here. You can focus on things important to improve the binding for the LayerShell library for example. This would benefit all other libraries, too.

[foxyfocus]

Okay, thanks! However, I have a question: do you have to modify GirCore.Libs.slnf as well, in order to run dotnet build GirCore.Libs.slnf? I tried to and I received this error:
I also added the project using the dotnet sln command but to no avail.

[MicrogamerCz]

I use Hyprland compositor, so there's no compatibility problem on my side and with some other Gtk4LS methods it seems as if it's working, but not actually modifying the window

Gtk4LayerShell.Functions.IsSupported() returns true, IsLayerWindow for the window also returns true, edge anchor is also correct, but the exclusive zone doesn't work and neither the window. Handles from the trace listener are called from window and label constructors, but nothing else. And there's also nothing before the HarfBuzz errors, that's probably related to GTK4 and not GTK4LS

[badcel]

I wonder what is the difference to the C program? Why is it behaving differently?

[MicrogamerCz]

Not just C, it works in python and vala as well. I'll try to generate new Gtk3 and Gtk3LS bindings to see if that works.

[badcel]

The GirCore generator does not support GTK3.

There are APIs which are not very binding friendly and probably cant be generated. This is why GTK3 was removed some years ago. And it will probably pretty tedious to try as you would need to generate the whole stack which is several bindings like, GDK, too.

Another idea would be to write a new program without GirCore at all and just do exactly the same as the C program: So manually define the DLLImports without all the stuff GirCore adds like memory management classes and so on. Then call all this functions and see what happens.

As your demo program is pretty short it should not be too much work.

Which distribution are you using? Are your system binaries build in some special way? Perhaps there is some very low level difference so the call gets lost. GirCore does not handle C calling conventions in any special way.

Which system architecture are you using? Is it different from x64? What kind of device are you using?

[MicrogamerCz]

Ah, that's unfortunate. Gtk3 is quite easy to work with in Vala.

Anyway, I finally had some time, so I wrote it manually and it still doesn't work. I'm not entirely sure, but the problem might be related to gtk_layer_init_for_window. The last two things I can try is building and installing from source instead of a package and rewriting some parts of gtk_layer_init_for_window in C#

I use arch, so the packages are most likely built directly from the source code without changes and I have a normal laptop (x86-64)

[badcel]

This is super strange especially if GTK works like expected but layershell does not.

If it has the same wrong behaviour if you write the C# code matching the C code without GirCore at all I would say GirCore is not to blame here.

The question is what is going wrong? You could try to check which binaries are called during runtime via ldd.

[MicrogamerCz]

It didn't show any GTK-related libraries, only whatever is necessary for running C# apps on Linux. What I found that works is writing it with... GTK 3. Not exactly a great idea, but it seems I will have to use the older Gtk3 bindings or make a new ones at the cost of stability or maintainability.

I'm glad it's not a gir.core bug

[badcel]

It has to show GTK related libraries if you call something like ldd dotnet run Window.csproj.

[MicrogamerCz]

No, it doesn't.

And even using ldd on a published executable it doesn't show anything

Maybe there is just some issue with Interop of Gtk4 and Gtk4LayerShell. Writing my program with GtkSharp (Gtk3) and manual interop of GtkLayerShell ends up working just fine.

[badcel]

Ah sorry it was the wrong command: LD_DEBUG=libs ./Katana 2>&1 | grep gtk