Native GTK2 D Bindings

[Artur Skawina]

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).