Open LoganDark opened 4 years ago
A fix to this is planned in 0.5.0, and I appreciate your input! I'll definitely look into that approach, but there is some complexity there because libui
doesn't give us as much access to memory management as I'd like.
This library is still in version 0 ("rapid prototyping phase"), so you don't need to increment major for breaking changes.
We are aware of this.
It seems like UI
is just a token, that is:
UI
, you initialize libui
UI
to a component, you assure the component that libui
is here, functional, and that we're calling from its threadI don't see an immediate solution to this, so I see why the decision was made now.
This is just a bit annoying.
Is there any other way this could be done? Perhaps the UI specified during creation could be stored in a field of the struct, like this:
That way you wouldn't have to also specify this UI object to every single method you call on that object.
In fact this could be done in a non-breaking way by preserving the original methods which take the
&UI
argument, and simply deprecating them.small semver note: This library is still in version 0 ("rapid prototyping phase"), so you don't need to increment major for breaking changes. Anyone using this library should be doing
iui = "~0.3.0"
or similar. It is definitely possible to make version 0.4.0 a breaking change. Although deprecating methods now and then removing them in version 1.0.0 would be preferable.