giD v0.9.6: WebKit web browser engine binding, GObject property support, and improved docs

[Element Green]

On Wednesday, 30 April 2025 at 09:54:58 UTC, Luna wrote:
> Given that the type name itself does not matter for ABI I’d say 
> just name the C types like _GObject_t; and call the D classes 
> things like GObject. Ideally users will be using your D 
> interface and basically never touch the C stuff; so having that 
> interface be the focus for naming etc. is the way to go imho.

gidgen actually follows what the GIR format defines for type 
names, except when it can't, for built-in D names like Object, 
Exception, Error, etc. The GIR format is designed for use in 
other languages which support the concept of namespaces or 
modules. So the C prefixes are removed.  So instead of GtkWidget, 
its just Widget.  You'll find this in just about every language 
that provides GObject Introspection bindings.

The D binding is built on top of the C types and functions, so 
they have to exist in some form. Making them the native C symbol 
names is also exactly as they are defined in the GIR format and 
makes sense to follow.

If you look at the modern GtkDoc generated documentation, it 
actually shows the types without the prefix and treats the 
functions as methods (removes the C function prefix).  Using 
camelCase() for methods was a design decision and follows D 
convention. Otherwise much of the API can easily be deduced from 
C docs. But why resort to that when the [giD 
adrdox](https://www.kymorphia.com/gid/) are quite good.

We've gone several rounds with pretty major changes with naming 
conventions and I'm pretty satisfied with how it is now and it 
follows the D standards for the most part. Unless there are 
compelling reasons to change it, that aren't just personal 
preference, I will be keeping it as is.

At the moment gidgen is primarily targeted at the giD repository. 
When using it with ones own libraries, the easiest is to add it 
to giD, so that it can use any dependencies it needs. The GIR 
file is placed in gir/ and a definition file in defs/, which is 
often just a single statement that defines the GIR file name, 
since gidgen is pretty good about automatically binding 
well-formed GIR APIs.

I plan on adding support at some point for being able to generate 
bindings outside of giD, by making use of generated binding 
dependencies, but for the moment, gidgen doesn't have a way to 
import dependencies without processing the GIR files and 
definition files.  Perhaps it will stay that way, with just a way 
to specify
additional external binding dependencies (from giD for example).

Nothing's stopping someone from just stripping down giD to only 
those GIR files and defs/ files needed as dependencies though and 
distributing it with their application. It's licensed under the 
MIT license.