GTK4 ComboBoxText question

Yesterday I tried to clear the content of a ComboBoxText instance. I assumed that I can do it with GtkEditable.setText(NULL) which seems to fail.

Questions: In Gtk.ComboBoxText, should GtkEditable be listed as an implemented interface? Only GtkCellEditable is listed. And is it expected that using setText() on a ComboBoxText instance with NULL for string parameter would crash? Well it is not advertised that it would work, for some other GTK functions NULL as agument work, so it took me some time to find the issue. No problem of course, I will pass an empty string.

Yesterday I tried to clear the content of a ComboBoxText instance. I assumed
that I can do it with GtkEditable.setText(NULL) which seems to fail.

Hi Stefan,

why do you think a combobox should implement GtkEditable? I would find
it quite confusing: I see GtkEditable as an interface to be applied to
a single piece of text while GtkComboBox owns a list of texts.

…
And is it expected that using setText() on a ComboBoxText instance
with NULL for string parameter would crash?
…

Yes, see the official
documentation
.
To be able to accept NULLs, a parameter must have the nullable (or
the old allow-none) annotation, see e.g. this
method
.

AFAIU from the gobject introspection documentation, only closures and gpointer are automatically nullable.

Ciao.

Oh sorry, I confused it with gtk_entry_set_text. See Gtk.Entry.set_text
Was really late yesterday, so I confused it. For gtk_entry_set_text() passing NULL as string parameter seems to result in that crash which I got yesterday, and your explanations seem to apply, thanks.

OOC, doesn’t Nim have a way to distinguish between nullable/optional values and non-nullable/non-optional values in the type system somehow? Or can everything be NULL/null/nil/etc like with C pointers or objects in e.g. Java or Go?

1 Like

OOC, doesn’t Nim have a way to distinguish between nullable/optional values

Indeed, Nim supports all that, but I do not know all the details that well currently, and I think the use of non-nil annotations is some work in progress in Nim still, I have to read more about the details. It was my feeling that GTK accepts NULL for most functions accepting strings, but that is wrong, at least gtk_entry_set_text() does crash when we pass NULL instead of a valid string. So it would make some sense to catch NULL parameters from inside Nim already.

You don’t have to assume but simply use the nullability annotations that each parameter/return value has :slight_smile:

1 Like

Yes. For Gtk.Label.set_text, from API docs NULL as string parameter is not supported? With our fine new [src] button we see " self->label = g_strdup (str ? str : “”);" which may indicate that NULL as string may work?

It might be missing the annotation, yes. That would be a bug.

From the bindings side you should always just rely on the annotations and don’t do any guesses yourself, except for potentially more conservative guesses (like never allowing NULL for parameters, always expecting NULL for return values).

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.