nullable string parameters

[rythmkraze]

Some Gtk functions take string parameters that can be null, such as the one below.

GtkWidget * gtk_frame_new (const gchar *label);

Creates a new GtkFrame, with optional label label . If label is NULL, the label is omitted.

In the above case we are unable to omit/disable the label widget, as we are unable to pass NULL to the C function.

Gobbi's implementation currently does'nt take into account the nullable string parameters.

func FrameNew(label string) *Frame {
	c_label := C.CString(label)
	defer C.free(unsafe.Pointer(c_label))

	retC := C.gtk_frame_new(c_label)
	retGo := FrameNewFromC(unsafe.Pointer(retC))

	return retGo
}

The Gotk3 library handles this correctly.

func FrameNew(label string) (*Frame, error) {
	var cstr *C.char
	if label != "" {
		cstr = C.CString(label)
		defer C.free(unsafe.Pointer(cstr))
	}
	c := C.gtk_frame_new((*C.gchar)(cstr))
	if c == nil {
		return nil, nilPtrErr
	}
	obj := glib.Take(unsafe.Pointer(c))
	return wrapFrame(obj), nil
}

The Gir files do indicate nullable parameters (nullable="1"). So code generation should be possible.

<parameter name="label"
           transfer-ownership="none"
           nullable="1"
           allow-none="1">
  <doc xml:space="preserve">the text to use as the label of the frame</doc>
  <type name="utf8" c:type="const gchar*"/>
</parameter>

Would appreciate if you could get this working and a possible workaround if possible until then :)

[rythmkraze]

Currently working around it by setting gtk.Frame.SetLabelWidget(nil)

[pekim]

I'm not sure that treating an empty string as a special case is the best approach. It may work for gtk_frame_new, but perhaps there are other situations were it wouldn't have the desired effect?

Maybe a better approach would be honour the nullable attribute in the in api, and stay closer to the C function signature. So the signature would change from

FrameNew(label string) *Frame

to

FrameNew(label *string) *Frame

[rythmkraze]

Maybe a better approach would be honour the nullable attribute in the in api, and stay closer to the C function signature.

I agree. This indeed would be a better approach.