Future plans

[weirdf0x]

@vurtun do you have any future plans concerning the direction of the library? Is there something that needs to be done / you want to do, or does it solely depend on feature requests / issues?

[vurtun]

There are multiple factors which makes this hard to answer for me and I couldn't really read out the intention of your question, but in general at least at the moment I have no master plan for the future. I am not even 100% sure if I even should add a lot more to the main library branch. Not because there are no more things to fix (like better graph support) or add (tables, shortcuts, docking, more widgets, ...) but the cost of adding them

For example the cost in complexity of adding gamepad or keyboard widget selection would be immensely high and only a small fraction of user would benefit from it. On the other hand it is quite easy to modify Nuklear and create a specialized versions which would work with gamepads. Another point is that imguis are already hard to write, but I also added a lot of additional constraints (especially in terms of memory) on top of that which often requires unconventional solutions. Adding tables for example would be quite easy and could even be done in user code but I don't have a solutions that fits nicely into my self set constraints. The same could be said about a docking system which is usually quite easy to write but my self set memory constrains would require a solution which does not consume memory while also working with overlapping windows (I even had a solution for this problem but it was quite complex to just add).

One could ask why even keep all these constrains and instead of just adding features. But this would lead me into the direction of QT while being the only main contributer (which would result in a bloated library). Furthermore I would even argue that my self set constraints produced a relatively simple library with a wide range of customizable functionality.

So to summarize I am quite happy what Nuklear currently is. Not because of the number of features or because it provides prebaked solutions for every problem, but because of how easy I can modify the library into a specialized direction to solve a specific problem space. That being said if somebody requests a feature I will at least try to find a solution to make sure it is possible to achieve it in a specialized library version. In some cases (for example multiple lines/bar in one chart) either somebody provides me with a good solution or I come up with a good solution myself which fits into my constrains and I have to problem adding it into the library. I hope this at least somewhat answered your question.

[weirdf0x]

This answers my question, indeed, and makes me happy, thanks a lot! I think it's a great idea to expand (or not) the library within a set of constraints. This allows other people to create more stuff on top of it and lessens your burden as a maintainer. I worked with several UI libraries / toolkits and I started to appreciate small, lightweight ones. It is mostly easier to add new things and you don't need to have 5-10 MB extra code containing things you'll never use.

Do you have any policy on backwards compatibility? I've seen you renamed the library and released 1.0 about 2 months ago, do new releases happen often?

[vurtun]

Version 1.0 is so far the only time I used the term release version. The reason was that I changed almost everything once per month to test things out before 1.0. So everything was quite unstable.

Then a short time before the release version 1.0 I tried to get everything into a "shipping" state and asked for feedback on the old version and got a lot of new ideas which led to the massive release commit.

As for the name change it was one of the complains I got that the old name zahnrad is hard to pronounce and remember for non-german speaker (especially non native english speakers) so I changed it since before the release version it wasn't as widely known anyway. As for changes and backward compatibility so far there was only one breaking change (I removed hard to use code with a low probability to be used anyway).

Other than that a stable API is quite important to me. Hence the reason why I even had a release version 1.0 to mark a stable API point of time. As for bug fixes and purely additive features I use a rolling release schedule and directly push changes.