Native GTK bindings v2

Artur Skawina art.08.09 at gmail.com
Sat Apr 21 05:26:59 PDT 2012


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


More information about the Digitalmars-d-announce mailing list