Native GTK2 bindings for D.


"Native" for two reasons:

1. Uses the C API directly. No class wrappers and no function wrappers. 2. OO interface, giving a native D look and feel.


The code generated when using these bindings is identical to the equivalent C version. Bit-for-bit, there is zero overhead. [1]


BINDINGS

The D modules in this package give access to:

 GLib-2.0
 GModule-2.0
 GObject-2.0
 Gio-2.0
 GdkPixbuf-2.0
 Pango-1.0
 Gdk-2.0
 Atk-1.0
 Gtk-2.0

There is also a minimal <cairo-1.0> stub, which only allows the GTK
stack to build, but isn't really usable.

[...more info in the README.txt file...]

---------------------------------------------------------------------------------

This is a *very* early release. Works for me (tm), but i've only tried the basic functionality so far. I don't know how much time I'll be able to spend on this in the next days and as it's already in a usable state. maybe somebody else wants to play with it already. At this point i'm mostly interested in API related thoughts -- i'd like to get it right *before* adding GTK3 support.

The code is available at http://repo.or.cz/w/girtod.git

The bindings are in the "gtk2" branch; the "master" branch has the tool used
to generate all the gtk2/*.d modules, some examples and a README.

Yes, there's even a section in there on "Why?" and the answer isn't NIH. :)


The gtk2 package (from the "gtk2" branch) can be used as-is, but if you'd like
to play with (re-)generating the bindings:

- The makefile is just an example of how to use the thing. It's GDC specific,
  x86 specific; the "configure" machinery still needs to be done. But it
  should be functional enough to rebuild the gtk2/*.d modules, with a few local
  tweaks. Which can then be moved and used in your application directly
  (place them in a "gtk2" subdirectory).
- See ./buildem for how to build the bindings.


artur

On 1/22/2012 1:54 PM, Artur Skawina wrote:
>
>
>                     Native GTK2 bindings for D.
>
>
> "Native" for two reasons:
>
> 1. Uses the C API directly. No class wrappers and no function wrappers.

This makes me suspect that part of this would be an ideal candidate for inclusion in the Deimos project:

https://github.com/D-Programming-Deimos/

The function names should be converted to camelCase.

> and a README.

gdc does cross module inlining if you pass all modules to it at once.

On 01/23/12 00:16, Trass3r wrote:
> The function names should be converted to camelCase.

No. I named it "native" for a reason. The method names are not manipulated in any way - they come directly from GTK.

I could *add* all kind of aliases, including camelCased ones, but why would anyone want to use those?

> gdc does cross module inlining if you pass all modules to it at once.
> 

As i mentioned in the README; but that's not really a solution. For me, LTO works for all apps using these bindings, but i added that footnote so that i could write "zero-cost" and not have people complain that the calls are not going directly to the PLT (as they do in C). :)

artur

> No. I named it "native" for a reason. The method names are not manipulated in any way - they come directly from GTK.
>
> I could *add* all kind of aliases, including camelCased ones, but why would anyone want to use those?

Cause those C names with underscores are just crappy.


>> gdc does cross module inlining if you pass all modules to it at once.
>>
>
> As i mentioned in the README; but that's not really a solution.

No, in there you claim gdc didn't support cross module inlining.

> No, in there you claim gdc didn't support cross module inlining.

Or at least it suggests that:
"As long as GDC cross module inlining doesn't work"

On 01/23/12 00:52, Trass3r wrote:
>> No. I named it "native" for a reason. The method names are not manipulated in any way - they come directly from GTK.
>>
>> I could *add* all kind of aliases, including camelCased ones, but why would anyone want to use those?
> 
> Cause those C names with underscores are just crappy.

Well, it would be a trivial addition. I'd just like to avoid having several conventions around, unless necessary.

I'd be more interested in comments on how to make the code using these bindings cleaner (the other meaning of "native" is "as-close- -to-natural-D-as-possible").

So far, a sample D GTK app looks like this:

http://repo.or.cz/w/girtod.git/blob/refs/heads/master:/example_gtk3.d

Anything I could change API-wise to improve things, that doesn't require language changes?

>>> gdc does cross module inlining if you pass all modules to it at once.
>>>
>>
>> As i mentioned in the README; but that's not really a solution.
> 
> No, in there you claim gdc didn't support cross module inlining.
> 

>From the README:
> (apparently, another workaround is to build all the *.d files together;
> I've never tried this)

It's a workaround, not a solution.

artur

Artur Skawina:

> So far, a sample D GTK app looks like this:
> 
> http://repo.or.cz/w/girtod.git/blob/refs/heads/master:/example_gtk3.d
> 
> Anything I could change API-wise to improve things, that doesn't require language changes?

The convention for D classes/structs/enums is CamelCase, while functions and methods are the same but start with a lowercase.


This line of code seems an example for people that like named arguments in D:
gtk.init(null,null);


Such lines of code contains a bad cast:
set_title(cast(char*)"Hello World!");
but.signal_connect!"button-press-event"(&bpress_cb, cast(void*)label);


I think toStringz shouldn't return a const pointer:
str0 = cast(char*)toStringz(display_string);

Bye,
bearophile

On 01/23/12 03:17, bearophile wrote:
> Artur Skawina:
> 
>> So far, a sample D GTK app looks like this:
>>
>> http://repo.or.cz/w/girtod.git/blob/refs/heads/master:/example_gtk3.d
>>
>> Anything I could change API-wise to improve things, that doesn't require language changes?
> 
> The convention for D classes/structs/enums is CamelCase, while functions and methods are the same but start with a lowercase.

There is no such thing as a language mandated identifier naming convention. If you think otherwise - make the compiler enforce it. :)

> This line of code seems an example for people that like named arguments in D:
> gtk.init(null,null);

This has nothing to do with named arguments, it's gtk wanting to parse and modify the C argv[], which i didn't want to rebuild in these examples. /* void gtk_init(/*inout*/ int* argc, /*inout*/ char*** argv=null);*/

A function which handles the argv conversion both ways would be a good idea. On the list. Thanks.

> Such lines of code contains a bad cast:
> set_title(cast(char*)"Hello World!");

If you had seen the glib code i was initially testing with... :) Unfortunately the immutable-strings don't mix well with non-D APIs, especially, like in this case, when practically all const annotations are lost in translation (the GIR files are already missing them).

Initially, i wanted to add a cstring type which would handle all the
casts and zero-termination transparently, but then decided to see
how things will work without that kind of magic. Not only would most
strings have to be duped, but an extra reference to the copies would
be needed, in case the string escaped.
Requiring explicit casts for most strings is ugly, but not something
that can be fixed both safely and cheaply. For a GUI toolkit the
amount of casts needed may be acceptable. [1]
I did remove the glib-using code from the repo because it made D look
bad...

> but.signal_connect!"button-press-event"(&bpress_cb, cast(void*)label);

Here <label> is really an opaque (void*) that gets passed to the callback. I don't see a way to get rid of the cast, while improving type safety...

> I think toStringz shouldn't return a const pointer:
> str0 = cast(char*)toStringz(display_string);

(immutable(char)*) C APIs are not exactly common. :)
IOW i think you're right.

> Bye,
> bearophile

Thanks,

artur

[1] Yes, this *will* cause bugs. But what's the alternative? A strongly typed C-string type would help catching most non-zero-terminated strings, but would need casts too (eg when initialized from literals) and still not help with the escaping references (libraries keeping the pointer around internally).

On Sun, 22 Jan 2012 22:54:03 +0100
Artur Skawina <art.08.09@gmail.com> wrote:

> 1. Uses the C API directly. No class wrappers and no function wrappers. 2. OO interface, giving a native D look and feel.
> 
> 
> The code generated when using these bindings is identical to the

> equivalent C version. Bit-for-bit, there is zero overhead. [1]

It is very nice to see that the GUI world of D is moving forward!

> Yes, there's even a section in there on "Why?" and the answer isn't NIH. :)

...although it would be nice to save breadth and work together.

Hopefully your project will stay maintained and developed further.


Sincerely,
Gour

-- 
In the material world, one who is unaffected by whatever good or evil he may obtain, neither praising it nor despising it, is firmly fixed in perfect knowledge.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810