Enum idiosyncrasies about gir

[EPashkin]

Can we just add to this enum next values: Other(int) and DontScale=-1?

[gkoz]

Yes but in the automation context the more interesting question is if it's possible to detect such enums and divine the required additional variants. The "don't scale" case might be better reflected with Option::<IconSize>::None.

[EPashkin]

After better looking I found that we need find solution only for 3 functions gtk_icon_set_render_icon, gtk_style_render_icon, gtk_widget_render_icon that accepts -1.
All other function accepts only registered values, so user can just store value returned by get_icon_register and use it in function calls.
Only possible problem with IconSize matching but IMHO it mostly unneeded or can be solved direct comparing with stored value.
For 3 problem function we really can use optional size parameter, but it can't be detected automatically and need some config.
Also we needed solve difference in <type name="gint" c:type="GtkIconSize"/> but IMHO it can be applied to all enums.

[EPashkin]

Updated previous comment.

[EPashkin]

When checking for <type name="gint" c:type="GtkIconSize"/> found many
<type name="gint" c:type="int"/>
and only 2 other ginted ctypes: cairo_format_t and pid_t.
GUinted ctypes uid_t with some unsigned or unsigned int.

[gkoz]

So this issue is extremely rare? Good. We could implement the conversions manually and let the generator assume they exist.

It's not clear why cairo_format_t is replaced with an int. Manually adding conversions to/from int would take care of that I expect.

<type name="gint" c:type="int"/> is weird but probably harmless, the rest seem like integers too.

[gkoz]

So, the current assumption in the code that enums are passed directly is problematic in light of these exceptions.

What do we do with GType? There's enum Type in glib so the generator should ideally treat it as a converted enum as well.

[GuillaumeGomez]

I think we can close this issue now.