digitalmars.D.announce - Re: Native GTK bindings v2
- bioinfornatics <bioinfornatics fedoraproject.org> Apr 13 2012
- Artur Skawina <art.08.09 gmail.com> Apr 21 2012
- Artur Skawina <art.08.09 gmail.com> Apr 21 2012
- Artur Skawina <art.08.09 gmail.com> Apr 21 2012
- Trass3r <un known.com> Apr 23 2012
Le dimanche 01 avril 2012 =C3=A0 21:23 +0200, Artur Skawina a =C3=A9crit :What's new? =20 - Now, in addition to =20 GLib, GModule, GObject, Gio, GdkPixbuf, Pango, PangoCairo, PangoFT, Gd=
=20 there are also bindings for =20 Clutter, ClutterX11, Cogl, CoglPango and Mx. =20 - Struct inheritance. No more need for "container.add(&vbox.widget);", y=
write that as just "container.add(vbox);", the compiler will do all th=
to check if the 'vbox' is somehow derived from 'widget', and convert t=
pointer by itself. =20 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. =20 - Objects can now be constructed as "gtk.VBox(0, 0)"; the old way, ie "gtk.VBox.new_(0, 0);" still works. =20 - All methods that take a (char*) pointer now also silently accept D str=
casting to (char*) and/or calling toStringz are no longer necessary. I=
be done implicitly every time you try to pass a D string; you can stil=
a (char*) to avoid the copy. =20 - GTK (GObject) interfaces supported. =20 - Better error messages when registering signal callbacks (the messages =
the compiler when a template instantiation fails are not very helpful =
it typically happens via several alias levels, were often just confusi=
=20 - Some 64-bit fixes (I don't have a 64-bit GTK stack ATM, so there could=
more problems around). =20 - The pre-generated D modules were built using newer library versions (still GTK2, only the glib version is newer than that). =20 - New examples: Clutter and Mx. Trivial, but enough to get you started. =20 =20 A D GTK app now looks like this: =20 http://repo.or.cz/w/girtod.git/blob/refs/heads/master:/example_gtk.d =20 doesn't need a single cast (other than for skipping the string copies, us=
(void*) library APIs and object lookup tricks, all of which could be avoi=
but I intentionally didn't do this in the example), looks much better tha=
the equivalent C version would and couldn't be done any more efficiently =
(assuming same compiler middle/backend and ignoring the string difference=
for most cases these don't matter. The convenience makes up for the few e=
copies and these can be avoided in every case where performance really ma=
=20 =20 The code is here: http://repo.or.cz/w/girtod.git =20 The easiest way to try the bindings is probably to check out the "gtk2" b=
copy the "gtk2" directory to your app directory and import from there. =20 The girtod tool used to generate the D modules lives in the "master" bran=
When used with different lib versions than the ones I tried it on, it may=
a few tweaks; sometimes new types appear or move between the libs, new we=
broken introspection data shows up etc. =20 artur =20 PS. Are there any sane Cairo D binding out there? (What's "sane"? Well, i=
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?
Apr 13 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
Apr 21 2012
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
Apr 21 2012
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
Apr 21 2012
Trass3r <un known.com> 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).
Me too. If you don't use gc-sections there shouldn't be any difference and if you do a lot of unnecessary code is stripped.
Apr 23 2012