giD v0.9.6 has been released. This release adds a WebKit 6 binding, the popular web browser engine used in Safari and other popular web browsers (D web browser anyone?). With the additional support libraries this brings the total giD library support count to 64.

This release also adds support for GObject property methods which was added to gidgen. Until now these had not been implemented since there are usually getter/setter methods also part of most GIR APIs. Some objects rely completely on GObject properties though which was why support was added and because it looks elegant as well (especially compared to calling getProperty/setProperty GObject templates).

Example:

  with(new Window) {
    window.title = "Hello World Example";
    window.defaultWidth = 200;
    window.defaultHeight = 200;
    window.child = new Label("Hello World!");
    self.present;
  }

Some rather significant object renames were also done to make the API more consistent. This mainly affected classes which use reserved D names, such as "Object", "Exception", "Error", "Monitor", etc. Instead of appending the library name to the class name, "Wrap" is just used. So ObjectG became ObjectWrap. VariantG was also just named Variant, since a rename is not required. At this point we don't expect such significant backwards compatibility breaking changes moving forward to a 1.0 release.

Many improvements were also made to the generated adrdox documentation.

On Monday, 21 April 2025 at 14:35:37 UTC, Element Green wrote:

Forgot to link the giD package, for those who have trouble finding it.

On Monday, 21 April 2025 at 14:38:46 UTC, Element Green wrote:

Well done. Great and so underrated project.

Andrea

On Monday, 21 April 2025 at 14:35:37 UTC, Element Green wrote:

EG, you rock as always. Thanks for this - amazing job!

However, I think the code you gave as an example is incorrect. It should be:

with(new Window) {
  title = "Hello World Example";
  defaultWidth = 200;
  defaultHeight = 200;
  child = new Label("Hello World!");
  self.present;
}

(window. removed). This is all so nice and clean. Love it!

I wish we did not have to rely on "self" in our code but hey, Walter and Co. did
not give us a good alternative... I wish some of the core devs actually noticed my post from few weeks ago: https://forum.dlang.org/thread/xroybbdawaojiavsqydb@forum.dlang.org

Another example of the new properties in action:
https://codeberg.org/dejan/gid-examples/src/branch/main/adw-simple/source/app.d#L26

On Friday, 25 April 2025 at 12:27:08 UTC, Dejan Lekic wrote:

And thanks to you for thinking of adding the WebKit binding. Seems like we've reached the point where adding a binding is pretty trivial.

with(new Window) {
  title = "Hello World Example";
  defaultWidth = 200;
  defaultHeight = 200;
  child = new Label("Hello World!");
  self.present;
}

Thanks for the correction. I knew I should have actually compiled the example ;-)

Agree, it would be great if there was a way to reference the subject of the with statement. I just read over the forum thread you linked and see that there is an issue filed over a decade ago for this! Maybe it's a case of, if you want it, code it yourself! ;-) Makes me wonder how difficult such an effort would be.

On Monday, 21 April 2025 at 14:35:37 UTC, Element Green wrote:

  with(new Window) {
    window.title = "Hello World Example";
    window.defaultWidth = 200;
    window.defaultHeight = 200;
    window.child = new Label("Hello World!");
    self.present;
  }

My personal recommendation would be to follow the GLib naming standard instead; so instead of ObjectWrap, or ObjectG; just call it GObject, for Pango call it PangoFont, etc.
That makes it consistent with existing GLib documentation for cases where you're gidgen'ing your own API bindings, etc.

On Monday, 28 April 2025 at 21:01:52 UTC, Luna wrote:

Problem is that GObject is already there - the C type. ObjectWrap wraps it. It was named ObjectG before, but Element Green gave it a more meaningful name that automatically tells is what the type is about...

On Monday, 28 April 2025 at 21:01:52 UTC, Luna wrote:

I forgot to add - giddy keeps it as close to the actual types as possible so people familiar with these libraries can quickly code their stuff in D as well.

On Tuesday, 29 April 2025 at 09:28:09 UTC, Dejan Lekic wrote:

On Wednesday, 30 April 2025 at 09:54:58 UTC, Luna wrote:

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 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.