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)

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?

On 04/13/12 15:06, bioinfornatics wrote:
> Le dimanche 01 avril 2012 à 21:23 +0200, Artur Skawina a écrit :
>> 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.

> why use your library instead https://github.com/gtkd-developers/GtkD

You should use whatever suits your needs. My "library" is not really a library, but just a set of wrapper templates that call the real C library functions. The advantage is no overhead, the disadvantage is sometimes a bit uglier syntax (but that area improved a lot since v1).

Note that there are a few things that could be done, but currently are
not implemented, simply because i haven't needed the functionality so far.
Things like subclassing and registering gobject classes - it all can
be done manually, but could be made a lot easier with a little help from
the bindings (btw, does gtkd help here?). Other than that, everything
needed by a typical app (that does not need to create custom widgets
or actors) should be there.

> why do not contribute to this project?

The approaches are completely different, so there's not much that could be shared.

In short: if you don't mind working with a layer that makes you access small structs containing just four integers via an extra D class instance, which only contains a pointer to said struct, then gtkd might be for you.

But then you may want to consider using something like Pike [1] instead of D...

artur

[1] http://pike.ida.liu.se/generated/manual/ref/chapter_1.html#4
    http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/GTK2.html

At first I confused your project with GtkD. I'll take a look at it, to see how it compares. Many examples for Gtk use C code, and I end up looking for the correct GtkD class that offers the function. Otherwise I quite like the classical inheritance that is possible with GtkD, whereas you use the "alias this" trick, which is fair enough. Also you can bind events like onExpose naturally to class methods in GtkD. There is no data pointer involved.
On the other hand small executables are my cup of tea. I've compiled a small Haskell Gtk application, that weighted ~10 MB (stripped) and the same program in D using GtkD was 3.4 MB in size. Let's see...

-- 
Marco

On 04/21/12 12:24, Marco Leise wrote:
> At first I confused your project with GtkD. I'll take a look at it, to see how it compares. Many examples for Gtk use C code, and I end up looking for the correct GtkD class that offers the function. Otherwise I quite like the classical inheritance that is possible with GtkD, whereas you use the "alias this" trick, which is fair enough. Also you can bind events like onExpose naturally to class methods in GtkD. There is no data pointer involved.

Hmm, some sugar is likely possible for things like signal callbacks; i'll think about it.

> On the other hand small executables are my cup of tea. I've compiled a small Haskell Gtk application, that weighted ~10 MB (stripped) and the same program in D using GtkD was 3.4 MB in size. Let's see...
> 

"example_gtk", which is probably the smallest /useful/ GTK2 app is 315K
here (32-bit x86 linux), after commenting out the _dumpObj(event) call.

(I wonder how large an equivalent gtkD version would be... But, as i care more about /runtime/ efficiency, it's not a very interesting metric)


If you care about executable sizes, some GDC specific notes:

- compile with "-ffunction-sections -fdata-sections -Wl,--gc-sections"
    Things like std.bitmanip unconditionally emit functions, which will
    be rarely used, but bloat the executable.
- do *not* compile with "-Wl,--export-dynamic"
    This option will slow down linking, while enabling better backtraces;
    unfortunately it will also prevent the gc-sections optimizations above
    from working.
- use '-frelease -fno-bounds-check'
- use '-flto'
- do not use '-g' together with '-flto' for the final executable linking
    GCC (4.6) bug, can result in ICE.
- strip the executable

artur

Am Sat, 21 Apr 2012 14:26:59 +0200
schrieb Artur Skawina <art.08.09@gmail.com>:

> On 04/21/12 12:24, Marco Leise wrote:
> > At first I confused your project with GtkD. I'll take a look at it, to see how it compares. Many examples for Gtk use C code, and I end up looking for the correct GtkD class that offers the function. Otherwise I quite like the classical inheritance that is possible with GtkD, whereas you use the "alias this" trick, which is fair enough. Also you can bind events like onExpose naturally to class methods in GtkD. There is no data pointer involved.
> 
> Hmm, some sugar is likely possible for things like signal callbacks; i'll think about it.
> 
> > On the other hand small executables are my cup of tea. I've compiled a small Haskell Gtk application, that weighted ~10 MB (stripped) and the same program in D using GtkD was 3.4 MB in size. Let's see...
> > 
> 
> "example_gtk", which is probably the smallest /useful/ GTK2 app is 315K
> here (32-bit x86 linux), after commenting out the _dumpObj(event) call.
> 
> (I wonder how large an equivalent gtkD version would be... But, as i care more about /runtime/ efficiency, it's not a very interesting metric)
> 
> 
> If you care about executable sizes, some GDC specific notes:
> 
> - compile with "-ffunction-sections -fdata-sections -Wl,--gc-sections"
>     Things like std.bitmanip unconditionally emit functions, which will
>     be rarely used, but bloat the executable.
> - do *not* compile with "-Wl,--export-dynamic"
>     This option will slow down linking, while enabling better backtraces;
>     unfortunately it will also prevent the gc-sections optimizations above
>     from working.
> - use '-frelease -fno-bounds-check'
> - use '-flto'
> - do not use '-g' together with '-flto' for the final executable linking
>     GCC (4.6) bug, can result in ICE.
> - strip the executable
> 
> artur

I just noticed cairo.d is still a dummy. I am using image surfaces. "-ffunction-sections -fdata-sections -Wl,--gc-sections" is a good idea, but I found it to break exception throwing for my programs.

-- 
Marco

On 04/21/12 19:16, Marco Leise wrote:
> I just noticed cairo.d is still a dummy. I am using image surfaces.

Yes, cairo.d is generated from GI data too and only contains the few symbols
and types required to use the other libs. There are other cairo D bindings, which
probably could be used with a small glue layer. Making sane cairo bindings is
on my to-do list, but I won't have the time for that in the next few weeks.

"-ffunction-sections -fdata-sections -Wl,--gc-sections" is a good idea, but I found it to break exception throwing for my programs.

GDC/DMD? Would you happen to have a small contained sample that breaks? Not garbage collecting sections means executables that are several times larger (IIRC for the small gtk example the difference was 1.2M vs 0.3M).

artur

Am Sat, 21 Apr 2012 21:46:18 +0200
schrieb Artur Skawina <art.08.09@gmail.com>:

> On 04/21/12 19:16, Marco Leise wrote:
> > I just noticed cairo.d is still a dummy. I am using image surfaces.
> 
> Yes, cairo.d is generated from GI data too and only contains the few symbols
> and types required to use the other libs. There are other cairo D bindings, which
> probably could be used with a small glue layer. Making sane cairo bindings is
> on my to-do list, but I won't have the time for that in the next few weeks.

No hurry, I have GtkD. It's biggest win is that it is considered stable and usable by many for a long time.

> "-ffunction-sections -fdata-sections -Wl,--gc-sections" is a good idea, but I found it to break exception throwing for my programs.
> 
> GDC/DMD? Would you happen to have a small contained sample that breaks? Not garbage collecting sections means executables that are several times larger (IIRC for the small gtk example the difference was 1.2M vs 0.3M).
> 
> artur

No example. I don't know what I tried it on, but I remember that I was hunting a bug that occurred, because an important exception wasn't thrown. I think it was a plain old "throw ...". It was with GDC, since DMD doesn't offer a one-section-per-function flag. I can give it a second try. I didn't post any bug reports, since gc-sections is a difficult beast:
https://bitbucket.org/goshawk/gdc/issue/293/ffunction-sections-fdata-sections-for
https://bugzilla.redhat.com/show_bug.cgi?id=788107
Without support from Iain, I don't expect a bug would be fixed by adding some hack to keep a function from being garbage collected (or whatever caused me problems).

-- 
Marco

On 04/22/12 00:06, Marco Leise wrote:
> Am Sat, 21 Apr 2012 21:46:18 +0200
> schrieb Artur Skawina <art.08.09@gmail.com>:
> 
>> On 04/21/12 19:16, Marco Leise wrote:
>>> I just noticed cairo.d is still a dummy. I am using image surfaces.
>>
>> Yes, cairo.d is generated from GI data too and only contains the few symbols
>> and types required to use the other libs. There are other cairo D bindings, which
>> probably could be used with a small glue layer. Making sane cairo bindings is
>> on my to-do list, but I won't have the time for that in the next few weeks.
> 
> No hurry, I have GtkD. It's biggest win is that it is considered stable and usable by many for a long time.
> 
>> "-ffunction-sections -fdata-sections -Wl,--gc-sections" is a good idea, but I found it to break exception throwing for my programs.
>>
>> GDC/DMD? Would you happen to have a small contained sample that breaks? Not garbage collecting sections means executables that are several times larger (IIRC for the small gtk example the difference was 1.2M vs 0.3M).
>>
>> artur
> 
> No example. I don't know what I tried it on, but I remember that I was hunting a bug that occurred, because an important exception wasn't thrown. I think it was a plain old "throw ...". It was with GDC, since DMD doesn't offer a one-section-per-function flag. I can give it a second try. I didn't post any bug reports, since gc-sections is a difficult beast:
> https://bitbucket.org/goshawk/gdc/issue/293/ffunction-sections-fdata-sections-for
> https://bugzilla.redhat.com/show_bug.cgi?id=788107
> Without support from Iain, I don't expect a bug would be fixed by adding some hack to keep a function from being garbage collected (or whatever caused me problems).

The first bug is about GDC having gc-sections as a *default*, which Iain seems to think
isn't important because a) phobos will be a shared library soon and b) it needs testing.
I agree with the latter, but the former is wrong - it will be many, many years before
even considering using a phobos DLL will be an option (for reasons that i mentioned in
#293).
The second ticket is about some already fixed upstream binutils bug.

I've been running with phobos built using "-ffunction-sections -fdata-sections" since ~ the time of #293 and so far haven't seen any problems (which of course doesn't mean that there aren't any).

Preventing a section from being garbage collected could be as simple as adding "KEEP()"
around its name in the linker script. But i've failed to reproduce any problems.
I'll need to remember to keep adding the options to every app makefile, because so far i
often didn't bother to do it... But, at least for exceptions, i wouldn't expect problems,
as the C++ case is already handled and GDC uses a similar scheme.

artur

Am Sun, 22 Apr 2012 00:54:41 +0200
schrieb Artur Skawina <art.08.09@gmail.com>:

> On 04/22/12 00:06, Marco Leise wrote:
> > Am Sat, 21 Apr 2012 21:46:18 +0200
> > schrieb Artur Skawina <art.08.09@gmail.com>:
> > 
> >> On 04/21/12 19:16, Marco Leise wrote:
> >>> I just noticed cairo.d is still a dummy. I am using image surfaces.
> >>
> >> Yes, cairo.d is generated from GI data too and only contains the few symbols
> >> and types required to use the other libs. There are other cairo D bindings, which
> >> probably could be used with a small glue layer. Making sane cairo bindings is
> >> on my to-do list, but I won't have the time for that in the next few weeks.
> > 
> > No hurry, I have GtkD. It's biggest win is that it is considered stable and usable by many for a long time.
> > 
> >> "-ffunction-sections -fdata-sections -Wl,--gc-sections" is a good idea, but I found it to break exception throwing for my programs.
> >>
> >> GDC/DMD? Would you happen to have a small contained sample that breaks? Not garbage collecting sections means executables that are several times larger (IIRC for the small gtk example the difference was 1.2M vs 0.3M).
> >>
> >> artur
> > 
> > No example. I don't know what I tried it on, but I remember that I was hunting a bug that occurred, because an important exception wasn't thrown. I think it was a plain old "throw ...". It was with GDC, since DMD doesn't offer a one-section-per-function flag. I can give it a second try. I didn't post any bug reports, since gc-sections is a difficult beast:
> > https://bitbucket.org/goshawk/gdc/issue/293/ffunction-sections-fdata-sections-for
> > https://bugzilla.redhat.com/show_bug.cgi?id=788107
> > Without support from Iain, I don't expect a bug would be fixed by adding some hack to keep a function from being garbage collected (or whatever caused me problems).
> 
> The first bug is about GDC having gc-sections as a *default*, which Iain seems to think
> isn't important because a) phobos will be a shared library soon and b) it needs testing.
> I agree with the latter, but the former is wrong - it will be many, many years before
> even considering using a phobos DLL will be an option (for reasons that i mentioned in
> #293).
> The second ticket is about some already fixed upstream binutils bug.
> 
> I've been running with phobos built using "-ffunction-sections -fdata-sections" since ~ the time of #293 and so far haven't seen any problems (which of course doesn't mean that there aren't any).
> 
> Preventing a section from being garbage collected could be as simple as adding "KEEP()"
> around its name in the linker script. But i've failed to reproduce any problems.
> I'll need to remember to keep adding the options to every app makefile, because so far i
> often didn't bother to do it... But, at least for exceptions, i wouldn't expect problems,
> as the C++ case is already handled and GDC uses a similar scheme.
> 
> artur

Ok, my trust in gc-sections is slowly returning. So far it works as advertised. :) It shaved off ~900 KB, so I am at acceptable 2.2 MB now. LTO is not working for me due to https://bitbucket.org/goshawk/gdc/issue/284/lto-undefined-reference-to .

-- 
Marco