Native GTK bindings v2

timotheecour thelastmammoth at
Fri Jun 1 03:01:44 PDT 2012

Have you tested it on osx?
I get lots of errors such as Error: module Atk from file 
gtk2/atk.d conflicts with another module Atk from file gtk2/atk.d 
I'm wondering whether it's due to case insensitivity on 
OSX/windows. I thought the convention was to use all lowercase 
for module names. As it is it seems to create collisions. Also 
there were a few other errors which I had tweak for eg:

phobos/std/bitmanip.d(66): Error: shift by 32 is outside the 
range 0..31
phobos/std/bitmanip.d(149): Error: template instance 
error instantiating
phobos/std/bitmanip.d(203):        instantiated from here: 
.../girtod/gtk2/glib2.d(3528):        instantiated from here: 

On Sunday, 1 April 2012 at 19:54:31 UTC, Artur Skawina wrote:
> What's new?
>  - Now, in addition to
>    GLib, GModule, GObject, Gio, GdkPixbuf, Pango, PangoCairo, 
> PangoFT, Gdk, Atk and Gtk+
>    there are also bindings for
>    Clutter, ClutterX11, Cogl, CoglPango and Mx.
>  - Struct inheritance. No more need for 
> "container.add(&vbox.widget);", you can
>    write that as just "container.add(vbox);", the compiler will 
> do all the work
>    to check if the 'vbox' is somehow derived from 'widget', and 
> convert the
>    pointer by itself.
>    This works not only for "struct Widget {}; struct VBox { 
> Widget widget; ... };",
>    but also for "struct Widget {}; struct VBox { Widget* 
> widget; ... };".
>    You can extend built-in widgets and still use them with the 
> std APIs.
> -  Objects can now be constructed as "gtk.VBox(0, 0)";
>    the old way, ie "gtk.VBox.new_(0, 0);" still works.
> -  All methods that take a (char*) pointer now also silently 
> accept D strings;
>    casting to (char*) and/or calling toStringz are no longer 
> necessary. It will
>    be done implicitly every time you try to pass a D string; 
> you can still pass
>    a (char*) to avoid the copy.
> -  GTK (GObject) interfaces supported.
> -  Better error messages when registering signal callbacks (the 
> messages given by
>    the compiler when a template instantiation fails are not 
> very helpful and, as
>    it typically happens via several alias levels, were often 
> just confusing).
> -  Some 64-bit fixes (I don't have a 64-bit GTK stack ATM, so 
> there could be
>    more problems around).
> -  The pre-generated D modules were built using newer library 
> versions
>    (still GTK2, only the glib version is newer than that).
> -  New examples: Clutter and Mx. Trivial, but enough to get you 
> started.
> A D GTK app now looks like this:
> doesn't need a single cast (other than for skipping the string 
> copies, using
> (void*) library APIs and object lookup tricks, all of which 
> could be avoided,
> but I intentionally didn't do this in the example), looks much 
> better than
> the equivalent C version would and couldn't be done any more 
> efficiently in C
> (assuming same compiler middle/backend and ignoring the string 
> differences, as
> for most cases these don't matter. The convenience makes up for 
> the few extra
> copies and these can be avoided in every case where performance 
> really matters).
> The code is here:
> The easiest way to try the bindings is probably to check out 
> the "gtk2" branch,
> copy the "gtk2" directory to your app directory and import from 
> there.
> The girtod tool used to generate the D modules lives in the 
> "master" branch.
> When used with different lib versions than the ones I tried it 
> on, it may need
> a few tweaks; sometimes new types appear or move between the 
> libs, new weird or
> broken introspection data shows up etc.
> artur
> PS. Are there any sane Cairo D binding out there? (What's 
> "sane"? Well, if
>     there's a "class" in there somewhere then it's not sane)

More information about the Digitalmars-d-announce mailing list