The motivation is that, for certain purposes, it would be more convenient if there were a pure C interface to CEGUI.
For instance, suppose I am working on a new game engine, and I want to use Rust instead of C++.
It's easy to ask, why would you want to do that, and there are tons of other languages like, Swift, C#, etc., which are in many ways extremely similar to C++, but the main advantage is that they have some proprietary corporate backer which provides certain support -- otherwise, I think it's fair to regard Swift instead of C++ as like "the king's english" more or less.
However in the case of Rust there really are significant new features. Instead of references, Rust has a "borrow checker", and things like const and reference are not part of the type system, so you don't have issues like you get with `std::vector<const std::string>`. This eases a lot of generic programming and prevents a lot of segfaults and problems that no other language fixes. Also Rust is backed by Mozilla, which while a large corporation, doesn't have a history of evil, which is a plus
However, while Rust has destructors like C++ does, it does not have exceptions, and it can't really talk directly to C++ code that may throw exceptions.
One of the most significant shortcomings to rust right now is that there are few libraries, especially GUI libs. It's probably not feasible to port CEGUI to Rust, but if there were some kind of compat layer there's a good chance people making Rust projects would use it that way.
Another way that having a C interface would help, is that it might make it a lot easier to bind python and lua to it. Currently we do that with boost python and tolua++. But those bindings seem a bit rickety lately -- tolua++ is not developed anymore afaik and the boost::python thing seems difficult to maintain, judging by the experience of the bug that there was against boost 1.60.
It would be cool if we had like a unified bindings generation system, where basically the whole lib is given a nice C interface first, and then more conventional tools create bindings to that for each particular language.
Another advantage is that a C interface would be very stable from ABI point of view. For instance, in C++11 they made a breaking change where gcc was forced to change how `std::string` worked in order to not do copy on write, because that is not thread-safe and the committee decided that std::string should be thread-safe. CEGUI is generally good about not breaking ABI, so its not really an issue, but there are probably some users who won't use a C++ lib like CEGUI because they fear ABI breaks, and might use it if there were a C interface.
In many ways CEGUI's interface already matches nicely to C anyways, because of the way that the managers work. In my experience, usually you either ask a manager to construct a widget for you, and it gives you a pointer, or you `new` an object yourself, but it adds itself to the manager. Then you manipulate it all via non-owning pointers. It could easily be adapted to C -- each widget would be manipulated via an opaque pointer type, and there would be free functions for each widget method that take the opaque pointer as first parameter. AFAIR it's quite rare that you necessarily pass large or complicated C++ objects back and forth with CEGUI.
It might be possible to use some kind of tool to automatically generate bindings like that, I'm not sure. It might be possible to build one using `libclang`.
The main spots that I can think of where something would have to be adapted would be:
- CEGUI memory buffers: I remember there being an object "RawDataContainer" which gets passed back and forth when you make a custom resource provider
- Event subscribers: You'd have to use some kind of function pointer / `void *` type-erasure system to create appropriate delegates, that would be kind of a pain in the butt.
Gluing other programming languages to C++ is hard, there's no easy answers, but it would be cool to hear people's thoughts on this.
