Upgrade to RayGUI 3.5

[LiamM32]

For two years now, the D version of RayGUI has been at raygui-3.5-dev, not even an actual release! Fortunately, that's fixed now. I've done the edits to reflect all the changes that were made to RayGUI between the time the current D version was written and the release of 3.5.

I have tested that everything works with both the example provided and my own game. While this isn't downright everything, I went through everything thoroughly enough to doubt that there will be any compatibility problems.

GuiTextBoxMulti was a function in RayGUI at during the development of version 3.5, but it ended up being commented out of the final release. However, it has been here in the D version for two years. Therefore, I've decided to label it "deprecated".

raygui is now listed as a subpackage so that later on multiple configuration options can be added. However, I didn't manage to remove source/raygui.d from the main package without a build error in the example, so it remains. Therefore, everything as of now should cause zero breaking changes.

[LiamM32]

I wasn't sure what to edit in generating.md, since this new version wasn't made using Dstep, but by looking at the git comparison of RayGUI between the time the D translation was written and the release. I plan to also do this for version 3.6, and possible 4.0, which may make those instructions irrelevant.

[schveiguy]

Thank you! I will have a look at this at some point. I've not used raygui so as long as the thing compiles, I'm tempted to just merge it.

It is OK to have breaking changes but only when a new raylib is released. I'm thinking instead of making this a subpackage, we can make it a standalone package. That way its updates are not dependent on raylib-d (and indeed raygui is developed separately from raylib)

[LiamM32]

Thank you! I will have a look at this at some point. I've not used raygui so as long as the thing compiles, I'm tempted to just merge it.

Sure. Go ahead. I don't think you'll get any complaints.

I'm thinking instead of making this a subpackage, we can make it a standalone package. That way its updates are not dependent on raylib-d (and indeed raygui is developed separately from raylib).

Well, I suppose that can be worth doing, as it allows separate versions of Raylib-D and RagGUI to be specified in the DUB dependencies. Before I was planning to have a RayGUI subpackage with different configurations for version 3.6 and version 4.0, but after thinking about it, having a separate package would probably be better. If you choose to make a new package, I recommend doing it rather soon, so that you can put out a release of RayGUI-D 3.5 before I submit 3.6.

Or should I attempt to start it? I've never submitted a package to DUB before, but I suppose I can setup the GitHub repository.

It looks like there is only one RayGUI package on DUB right now, called draygui, but it's only a binding, so I think "RayGUI-D" would be the most appropriate name.

[schveiguy]

Ugh, I need to review this, sorry for the delay.

[schveiguy]

Doing a new release for 5.5, and going to look into removing raygui and making its own package.