LiamM32

I've been thinking of turning raygui into a subpackage, so that both 3.5 and 4.0 will later be available in separate configurations.

> The enum changes _might_ work this way, but you need to make it very simple to generate new bindings, which I don't think this does. Keep in mind, all...

> > Do you think it's likely that existing enums will change? > > Yes > > https://github.com/raysan5/raylib/pull/3733/files Well, that's just the old "menu" button on Android, which modern Android...

> I'm still confused why we can't just generate the new enums instead of editing the file? They will still be visible to the user. > > Something like: >...

Check out [this new updater program](https://github.com/LiamM32/raylib-d/blob/new-updater/update-generators/enum_generator.d) I wrote and placed in a new branch. Right now it just generates the enums and places them in a separate module, but this...

> But I'd recommend at this point, separating out these ideas into a separate PR, and we can add the Rectangle methods now. I would do this, but I don't...

> I am OK adding anything that is not a direct translation of C code in a _separate_ module, as long as the binding modules are generated, and look similar...

> > Are you against putting anything that's not strictly a binding to a raylib symbol inside `package.d`? Alright then. I'll try to put new things in other modules. The...

I know that you (schveiguy) wrote elsewhere that you're "not looking for a raylib-cpp style API reimagining" (not that that's really what this proposal is) but I think it's worth...

If I did this, how would I go about it? It looks like the current `raygui.d` was made by copying `raygui.h`, and then making edits until it's valid in D....