Closed kelnos closed 2 years ago
Is adding the manual_traits bit in Gir.toml necessary? It didn't appear to change the output of the codegen when I re-ran it.
It is needed for the generated docs, see the list of "Implements" traits.
So my feeling is that Option<(&str, &str)> is the right way to go here, since it has the same behavior when passed to down to libgtk (even though I don't think that behavior is particularly good or useful when an empty array is passed).
Please see how we have implemented that in gtk4-rs, the corresponding PR should have details on why we decided to not use a Option<&[(&str, &str)]>
Ah, doh, should have looked at gtk4-rs first to see if this was done already! Probably best that I just copy over your work rather than reinventing.
Ok, just copied over the gtk4-rs version (and added the feature gate).
Looks like binding for this was skipped because the signature is not very Rust-idiomatic.
Two things:
manual_traits
bit inGir.toml
necessary? It didn't appear to change the output of the codegen when I re-ran it..to_glib_none()
on aVec
will give us aNULL
-terminated pointer array. (I think this is the case from looking atto_glib_none_from_slice()
, which uses aGPtrArray
, but wanted to be sure.)add_choice()
function signature:options: [(&str, &str)]
(noOption
around it), and just interpret "empty array" as "I want this to be a boolean choice".Some
/None
there, though. But in practice I think an implementation would have to treatNone
and&[]
as the same, since a combo box with zero items isn't all that useful. Interestingly, I think libgtk just considers passing empty lists as a programmer error, as it doesn't bother to check for that; passing an empty array will just get you an empty combo box, and the only way you get a check box is by passingNULL
.Option<(&str, &str)>
is the right way to go here, since it has the same behavior when passed to down to libgtk (even though I don't think that behavior is particularly good or useful when an empty array is passed).