Original title: GTK4, gtk_check_button_new_with_label() and optional label?
Is it really a good idea to make the label optional when there is still a plain gtk_check_button_new() and the function name actual is “with_label”?
The actual problem is
By default so we get for GTK4 two overloaded procs with same name, one without argument, one with optional string argument, and compiler complains when we try to use that proc.
Well we can manually fix the issue for this single proc, but automatic fixing such case for all procs is some more work. So I would prefer how it was in GTK3.
And again this ugly forum message popped up: “Title seems unclear, is it a complete sentence?”
gtk_button_new_with_label() is not nullable, probably for this very reason. There’s also a gtk_button_new() if you don’t want a label.
Also gtk_link_button_new_with_label() specifies nullable, gtk_toggle_button_new_with_label() doesn’t.
IMHO it would make sense to not have any of them nullable because the other function also exists. From a Rust bindings point of view having both new() and a nullable with_label() is also confusing and seems redundant.
You can always mark them as skip if you don’t want bindings to use them, but that’s not the point here. Even from a C point of view, gtk_button_new() and gtk_button_new_with_label(NULL) are redundant. Technically you can pass NULL in there but it doesn’t make much sense.
For the Rust bindings at least we use the constructors provided by C as “convenience” constructors for common patterns so users don’t have to first look at all the possible properties and figure out which they want to set and how. Want a button with a label? There’s a gtk::Button::with_label() and you don’t have to worry about all the other possibilities yet, but if you wanted to you can completely side-step those convenience constructors and go via the equivalent of g_object_new().
The problem here is now that for languages that don’t care about nullability the above doesn’t really matter. Everything can be NULL and that’s your problem if you do it wrong. But if the language expresses nullability then the above is mildly confusing. Why would you have to call gtk::Button::with_label(Some("blabla")) if there’s already a gtk::Button::new(), are gtk::Button::new() and gtk::Button::with_label(None) the same or do they actually behave slightly different, etc.?
It’s not a big problem, it’s just yet another little papercut and we’ll manually fix that in the Rust bindings at least. Just sucks that every other bindings has to do the same work if GTK wants things to stay as they are currently.
I guess nullability is just something C developers don’t really spend much thought on as part of the API design as it’s all the same in C anyway
I’ll keep my opinions about rusts nullability handling to myself and just say that I agree that gtk_button_new_with_label (NULL) is redundant - which is why @label isn’t annotated as nullable.
The label in gtk_link_button_new() is annotated as nullable since time immemorial, and that could just be removed if it bothers you. This came in with 6529c07614ebfbfac which rolled in a ton of allow-none annotations from gir-repository.
Let’s see if someone cares enough to submit an MR and to take care of the resulting discussions. It’s easy enough to work around on the bindings side and there seems to be a general disagreement on the topic of nullability and other binding aspects between us, and it seems like our discussions on these topics always end up being rather unproductive. I’ll leave any further GTK-related discussions to others who actually want to develop with GTK bindings. That’s probably more helpful.
The main reason I can see why many things in GTK land end up ‘technically’ nullable, even though we never expect them to be NULL in real-life situations is that NULL is unavoidable as default value for many property types, and we generally want setters and getters to be able to handle the default value.
