Seeing as there are breaking changes coming v4 soon, what do you think about giving the other flags there own type?

For example, the various WindowFlags are all of type int and imgui.BeginV() for example, expects type int. However, it would be an improvement I think, if we define a new type, WindowFlags.

Thank you for noticing this. I did not have time to go through those as well - perhaps @the-goodies can assist/double check, they provided the 1.81 upgrade.

I'm OK with unifying the flag values to be typed. However please avoid switching them back to be iota based. They were originally so, someone else changed them to be explicit (to match imgui.h), now they would be going back to iota. Neither approach ensures they match the header, sadly.

Please tell when you are done with this change.

I should point out that this isn't an issue that was introduced in the recent merge. The flag values I've changed have always had type int, despite there existing in those cases a special purpose type and the function signatures requiring values of that type.

Understood and agree with the iota. As you say, neither way ensures consistency with imgui.h but at least with the non-iota option it is self-documenting.

I'll make the changes to WindowFlags etc. and let you know when I've finished.

Have you considered enabling the Discussions feature for the repository? I think it would be good for people to ask questions, coordinate what they're doing or planning to do, without opening up an issue. It might turn out to be unpopular but it's worth experimenting with I think.

All flags and other constant types now have their own type. This makes navigation of documentation more straightforward and should make tab-completion type tools return better results.

Moreover, effective use of the type system helps in detecting programming errors. Indeed, I've already detected one error in my project's code base due to the use of an incorrect flag type.

The only set of constants I've not touched are the Key values defined in IO.go. I'm not sure how to handle that and what it would mean.

I've made a couple of choices which might not be liked. For example, the MouseCursor type is used to specify the mouse cursor for the SetMouseCursor() function. This conflicts with the MouseCursor() function, the Go function that calls GetMouseCursor(). I've renamed that function to CurrentMouseCursor() to avoid the conflict.

The alternative would be to name the type, MouseCursorID, but that doesn't seem right to me. No right-or-wrong answer, I don't think, and I'll be happy to change it if necessary.

I've also renamed StyleVarID and StyleColorID to StyleVar and StyleColor. Again, this is a question of personal-taste and I did it to align with what seems to me to be the overall naming convention in the project. I'll be happy to change them back if opinions differ.

One other breaking change I would like to make is to replace color definitions that use imgui.Vec4 with something like imgui.Color. The field names in the Vec4 type aren't well suited to specifying colors IMO.

With a bit of work we could maybe even use the color package from the go standard library, but that might be too big of a change.

We need to be cautious about how much to change in one go.

To rename the majority of constants from singular case to plural case seems like a lot to break. Originally I saw one constant to be singular, but it seems that wasn't followed anymore at one point - and keeping the plural form also for constants probably is closer to the original. So, OK on that change - thank you for the tedious work there. (still too bad to have no enum-equivalent in Go)

As for other things:

• StyleVar and StyleColor - No, please back to *ID for the type name. Because they aren't a color (or variable), but identify them.
• This then allows to answer for MouseCursor: Make the type MouseCursorID, keep the names of the current constants (e.g. MouseCursorHand) - and keep the original function of MouseCursor().
• Color changes: Also, no. Without better knowledge on how imgui-go is widely used, it's difficult to say whether to stick to the original interface of the wrapped library, or completely abstract things away. So far my intent was to lean towards a thin wrapper, without additional intelligence. Also, fearing calculations to be done for every frame and color usage, I see it better to have a pre-calculated item.

Please have another pass at this, then we can be closer to a v4 release.

We need to be cautious about how much to change in one go.

Agreed.

To rename the majority of constants from singular case to plural case seems like a lot to break

I think I only did this with BackendFlags* and ConfigFlags*. This matches the convention in the parent imgui project.

StyleVar and StyleColor - No, please back to *ID for the type name. Because they aren't a color (or variable), but identify them.

This then allows to answer for MouseCursor: Make the type MouseCursorID, keep the names of the current constants (e.g. MouseCursorHand) - and keep the original function of MouseCursor().

Agreed. Both reverted.

Color changes: Also, no.

Understood. On reflection, I agree with your policy of keeping the package as thin as possible.

Perfect - thank you again for the contribution!