CEGUI (Crazy Eddie's GUI) Forums

There's a talk on the frontpage about how CEGUI 1.0 will use a Model/View "pattern" if I may call it so. Is this similar to a MVC pattern? Can we get a bit more information about this?

Personally I would hate it if CEGUI moved in the direction of something similar to a MVC pattern because those tend to force you to code in a very particular manner. The classical API approach of CEGUI makes it an alternative to other libraries with more "webby" models like librocket that are often times not appropiated for game development. And I love this "toolbox" approach of CEGUI because it gives you a lot of flexibility. IMHO, it would be a shame if CEGUI would move in that direction, and if that's the plan it would be really appreciated if I could get a heads-up.

So basically, what is it that all about, is this something that will affect me as a library user? Or are those changes that will happen internally?

Finally, I'd like to say that it's really cool to see that this project is still alive and would like to thank everybody who's trying to move the project forward. If there are changes I will try to adapt, but it probably wouldn't be bad if we have a discussion about it.

For future reference, this was the news: http://cegui.org.uk/news/gsoc-2014-mode ... ct-summary
It was the GSOC2014 project and the changes are applied to default branch. From my understanding it is a MVC pattern.

Timotei can tell you more..

Please note that you are not forced to use MVC, you can if you want to or you can use the integrated class that has the model and view inside for the old behavior.

Sort of similar to how Qt does it with QTreeView vs QTreeWidget.

Hi Montred,

You can consider the Model-View pattern similar to MVC or MVVM, but it's more like just separating the items data source (model) from the view. So, the data is not in the view, using classes tightened to UI, but is extracted outside. And yes, it will affect its users, since it's an API modification, but we've tried to keep compatible to the way things have been written until now to minimize migration requirements.

However, we also have convenience classes that allow people to use the old way of adding items in the widgets. That means migrating to the new API will be as less effort as possible required, and we have documentation & samples on the way to use the new API. We appreciate having actual users of the new API before we release its first version so that we can modify/improve it accordingly.