March 23, 2023
On 3/21/2023 3:56 PM, Bowler Hat wrote:
> For example, g_signal_connect is actually a macro for calling another function with specific parameters. That seems to have no direct equivalent in D.

Can you please post an example of the gtk.h lines of code that you are having difficulty with? Then we can help!
March 23, 2023

On Tuesday, 21 March 2023 at 22:56:07 UTC, Bowler Hat wrote:

>

On Saturday, 12 November 2022 at 15:35:03 UTC, Don Allen wrote:

>

On Wednesday, 9 November 2022 at 15:00:39 UTC, Don Allen wrote:

>

On Monday, 7 November 2022 at 22:05:38 UTC, Walter Bright wrote:

>

https://news.ycombinator.com/item?id=33509223

Once I came to that realization, I created a gtk.c file in a place visible to my source files containing just one line:

#include <gtk/gtk.h>

and then arranged for the clang pre-processor to produce a gtk.i file from it, using the standard pkg-conf method to tell Clang where all the gtk header-file directories are. The 'import gtk's in my D source files now see the gtk.i file and so I am now actually using ImportC, rather than imagining it. The problem is that it produces many errors, due to the expansion of gtk.h generating a lot of C that ImportC doesn't understand.

I tried modifying my gtk.c in an attempt to work around some of the problems, using #defines, a technique suggested in Walter's documentation. This helped, but ultimately, it just kicks the can down the road. The fundamental problem is that the expansion of gtk.h is extremely complex and, crucially, makes use of gcc and/or clang extensions that I could not work around; they are just too far from C11 or too difficult to modify. So to continue to use D, I will have to revert to my original method for dealing with gtk.

Hi Don,

I've looked at this thread for a while now and made several attempts at getting it to work. Unfortunately, my experience with ImportC follows exactly what you describe.

I'm actually more curious about the details of how you originally worked with gtk in D. I've tried the same method with some success but its not entirely obvious how you deal with certain cases. For example, g_signal_connect is actually a macro for calling another function with specific parameters. That seems to have no direct equivalent in D.

#define g_signal_connect(instance, detailed_signal, c_handler, data) \
    g_signal_connect_data ((instance), (detailed_signal), (c_handler), (data), NULL, (GConnectFlags) 0)

These gnome people are weird, it should be a simple function (D):

gulong g_signal_connect(gpointer instance, const gchar *detailed_signal, GCallback c_handler, gpointer data)
{
    g_signal_connect_data(instance, detailed_signal, c_handler, data, null, 0)
}
March 24, 2023

On Tuesday, 21 March 2023 at 22:56:07 UTC, Bowler Hat wrote:

>

On Saturday, 12 November 2022 at 15:35:03 UTC, Don Allen wrote:

>

On Wednesday, 9 November 2022 at 15:00:39 UTC, Don Allen wrote:

>

On Monday, 7 November 2022 at 22:05:38 UTC, Walter Bright wrote:

>

https://news.ycombinator.com/item?id=33509223

Once I came to that realization, I created a gtk.c file in a place visible to my source files containing just one line:

#include <gtk/gtk.h>

and then arranged for the clang pre-processor to produce a gtk.i file from it, using the standard pkg-conf method to tell Clang where all the gtk header-file directories are. The 'import gtk's in my D source files now see the gtk.i file and so I am now actually using ImportC, rather than imagining it. The problem is that it produces many errors, due to the expansion of gtk.h generating a lot of C that ImportC doesn't understand.

I tried modifying my gtk.c in an attempt to work around some of the problems, using #defines, a technique suggested in Walter's documentation. This helped, but ultimately, it just kicks the can down the road. The fundamental problem is that the expansion of gtk.h is extremely complex and, crucially, makes use of gcc and/or clang extensions that I could not work around; they are just too far from C11 or too difficult to modify. So to continue to use D, I will have to revert to my original method for dealing with gtk.

Hi Don,

I've looked at this thread for a while now and made several attempts at getting it to work. Unfortunately, my experience with ImportC follows exactly what you describe.

I'm actually more curious about the details of how you originally worked with gtk in D. I've tried the same method with some success but its not entirely obvious how you deal with certain cases. For example, g_signal_connect is actually a macro for calling another function with specific parameters. That seems to have no direct equivalent in D.

See the message I posted earlier in this thread (on 11/09/2022). It describes my general approach to using gtk3 from D without ImportC.

As to g_signal_connect -- yes, it's a C macro and you can't use it directly in D. But there are signal-connecting functions in gtk3, e.g., g_signal_connect_data, that you can use instead. See the gtk documentation. The signal-connecting functions live in gobject, so you'll need to go to that section of the documentation.

1 2 3 4
Next ›   Last »