CEGUI (Crazy Eddie's GUI) Forums

Recently I had an idea for a potential development direction -- not sure if I'm going to do this, mostly just want to listen to reactions of others to this idea.

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.

@iceiceice: Sounds like a very interesting idea, and seems like you've though it through. What worries me the most about C interface is not how we create it, but how useful it would be. CEGUI is OO. Python is too, therefore in python we can expose its OO nature. C isn't. So if u export CEGUI to C u lose some info - for example, inheritance and polymorphism. For example, what if u want to inherit a CEGUI class in C, and override one of its virtual functions? So, the way I see it, it'll really limit what u can do, so I doubt how useful it'll be.

It could be useful to expose CEGUI e.g. to Rust directly. Have u looked at SWIG?

The bug in Boost-Python was only in 1 specific version, so I don't think it should be a significant consideration.

Porting cegui to C and from there to Rust sounds to me, in a way, like translating from english to spanish by 1st translating to egyptian hieroglyphs and then to spanish..

Or maybe, English -> Latin -> Spanish.

@YaronCT, the thing is, figuring out how to deal with the exceptions and all that is something that *all* of these bindings that we make must do, whether its Python, Lua, or anything else. It seems a lot simpler to solve that problem once, rather than three separate times in three separate ways.

@iceiceice: Support of building cegui without exceptions is something that has already been proposed. Some changes had to be made, but haven't been done. If you finish that work it'll be highly appreciated!

So this will mainly be a wrapper? I am not sure what you mean by "interface". I assume you want to create a layer inbetween CEGUI C++ and the C code that could call functions to interact with CEGUi in pure C, is that right? I think it would be easily doable but you would have to either cut out or miss out on a lot of features