Wrapper does not handle varargs

Looking at the gtk source it looks like most functions have an alternative that accepts a array or a va_list. altough only GtkListStore? has them documented.
I also checked to see how gtkmm handled this, They seem to just ignore the variadic functions not wrapping them.

Is this something we need to work on? Like Mike said, gtkmm doesn't handle them, so should gtkD?

We could do something like this:

public void setAttributes(CellRenderer, T...)(CellRenderer cell, T t )
{
	// void gtk_cell_layout_set_attributes (GtkCellLayout *cell_layout,  GtkCellRenderer *cell,  ...);
	gtk_cell_layout_set_attributes(getCellLayoutTStruct(), (cell is null) ? null : cell.getCellRendererStruct(), t);
}

but then you'll need to pass C strings to the functions with varargs, or we need to find a way to change those in the function.

I tried a few thing to change the char[] in the tuple to a char*, all tries result in a: Can't evaluate X at runtime. error or something similar.

Some of the glib functions like g_build_filename and g_build_path also use varargs and cause a runtime error when used because the varargs are never passed to the underlying C function. I've created a patch buildFilename that uses varargs and it seems to work. I would be great if the patch could be reviewed.

In my opinion, the following function could be added to glib.Str: public static char** toStringzArray(...)

This way the it will be easier to use this new functions in order to transform D varags into a their glib/gtk equivalent gchar**.

Fix Util.buildFilename()

In my patch, I've only changed the code to buildFilename even though buildPath is in the same nasty situation. This is because I wanted your feed back first, I will be glad to apply the same changes to buildPath if the code is good and to resubmit a final patch.

If i could suggest something:

public static string buildFilename(string[] firstElement ... )
{
	// gchar* g_build_filename (const gchar *first_element,  ...);
	return buildFilenamev(Str.toStringzArray(firstElement));
}

That still has the problem that the char* returned by Gtk isn't freed as you noted on IRC, this probably has something to do with ticket #14, before svn r353 strings returned by Gtk were not duped but GtkD would return a slice of the original string nimus the trailing \0.

Replying to potyl:

This is because I wanted your feed back first, I will be glad to apply the same changes to buildPath if the code is good and to resubmit a final patch.

We would rather have an solution that could be handled by the wrapper, if possible.

gtkD+demos svn build fine with this patch using Tango svn (with dmd and "dsss build"). Is there a way this should also be tested?

I haven't found a place in the gtkD source code where this function is used.

Replying to Mike Wey:

If i could suggest something: {{{ #!d public static string buildFilename(string[] firstElement ... ) { // gchar* g_build_filename (const gchar *first_element, ...); return buildFilenamev(Str.toStringzArray(firstElement)); } }}}

I'm confused with this suggestion. I think that firstElement should be of type string and not string[]. Using varargs in D has an advantage it makes the code easier to write:

import glib.Util;
Uitl.buildFilename("a", "b", "c");

Of course there's no more type checking thus there's no guaranty that everything passed as an argument is a string.

Replying to potyl:

Replying to Mike Wey:

If i could suggest something: {{{ #!d public static string buildFilename(string[] firstElement ... ) { // gchar* g_build_filename (const gchar *first_element, ...); return buildFilenamev(Str.toStringzArray(firstElement)); } }}}

I'm confused with this suggestion. I think that firstElement should be of type string and not string[]. Using varargs in D has an advantage it makes the code easier to write: {{{ import glib.Util; Uitl.buildFilename("a", "b", "c"); }}} Of course there's no more type checking thus there's no guaranty that everything passed as an argument is a string.

Please forget my last comment. I wasn't aware of the construct string[] var ... , which by the way is quite neat as it fixes the type checking!

The best option currently looks like to remove the functions that accept varargs, and ad some of them back manually on a need basis.

Is this something you guys feel needs attention in prior to the 1.0 release, or something that should be discussed for the 2.x series coming later? I've given my opinion earlier, please let me know what you guys think.

Also, sorry for my absence over the past week. I've had a lot going on!

Leaving functions that throw an segfault in the 1.0 release doesn't sound like a good idea.

I'll look into the option of omitting the functions with varargs in gtkD.

Omitting is actually what I meant when I said not working on implementing them into the wrapper. Sorry for the confusion!

Anyways, point being, after omitted, should we create a ticket for 2.x to include varargs?

with svn r552 there is no cdeo generated for functions with varargs.

Feel free to report vararg functions that are now missing but are still needed.