Native GTK bindings v2
bioinfornatics
bioinfornatics at fedoraproject.org
Fri Apr 13 06:06:13 PDT 2012
Le dimanche 01 avril 2012 à 21:23 +0200, Artur Skawina a écrit :
> 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:
>
> http://repo.or.cz/w/girtod.git/blob/refs/heads/master:/example_gtk.d
>
> 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: http://repo.or.cz/w/girtod.git
>
> 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)
why use your library instead https://github.com/gtkd-developers/GtkD
why do not contribute to this project?
More information about the Digitalmars-d-announce
mailing list