This PR has been opened to hopefully get some help in identifying the remaining issues before making a mergeable solution. See forum thread for more context.
Add a work-around fix for VS2015 boost pointer errors, and by extension Python3 on Windows. This required updating the generated python bindings which are not reproducibly runnable today.
1) PyCEGUI on Ubuntu (gcc, 64 bit, python2) never calls constructors when executing getSingleton.
will return None and if built in release mode will assert false on static singleton being NULL). Calling the singleton constructor explicitly is not populating the singleton value that is being referenced in getSingleton. (i.e.
2) Windows builds with msvc still have some unresolved external symbols and some weird cv cast issues between identical types. (e.g. error C2440: 'return': cannot convert from 'volatile const cleanMouseCursorEventArgs ' to 'volatile const cleanMouseCursorEventArgs ').
A few notable additional changes:
1) Fixed python calls in cmake for Python3 compatibility
2) Fixed ogre boost pointers for VS2015
3) Added build instructions to generate.py
4) Upgraded generate.py to use CastXML / latest py++ library
Any news on this from your side? I still dont have much of an idea.
I sort of dropped working on this when I went on vacation. I'll look at picking it up again the next weekend I have free. Was hoping the singleton NULL issue would be something that'd been seen before or had some tricky assignment order that an original developer knew about.
The default branch PyCEGUI is currently broken? Would this help fix it?
I just tried to compile CEGUI for CEED with VS2013 but PyCEGUI still has Vector2f and stuff
Our most recent plan several months ago was to migrate CEED to C++ by just using QT C++. There is a branch for this but somehow me and @mpreisler never managed to continue work on this and to finish this off, although it wouldnt be terribly much work (ceed has a LOTTT of work put into it). It is somewhat my fault this was not done - just too many other things in my life going on.
Why we wanted to do this? Because the whole python ++ stuff is a mess. It is best avoided by just not using python for this atm. I developed quite a lot on CEED to get some new features in like founding the basis of the LNF editor and the whole python bindings stuff slowed me down a lot back then - the API of CEGUI wasnt ready for supporting the editor on that and rebuilding CEGUI meant rebuilding bindings which took ages really really really long to compile.
The original plan for using python for QT in CEED by using C++ generated python bindings was good but it fell flat due to dropped plan of some highly experienced guy who wanted to do the C++ python generation in a proper way. I forgot who it was or how the project was called, I only know this from @mpreisler so if we really care we would have to poke him about it.
So my suggestion would be to put effort into the C++ port of CEED rather than on python stuff. It will resolve the issues and make our future life easier. The costs of using C++ instead of Python for the development process are minimal. CEED doesnt have a huge startup time or anything that would require runtime editing.
Yes I think this PR was trying to get some older tooling / pairing working with modern VS versions. I’m not sure it’d directly resolve the master branch issues referenced.
I really liked the idea of a clean way of building GUIs from native Python, but without core support with improved python interactions/tests in mind those ++ bindings are a really painful to regenerate and reason about. The NULL pointer I got blocked on above is a prime example.
As a python consumer, making a think cython layer that pulls/wraps C/C++ classes in as the parent application needs to call them rather than pre-compiling all bindings might be easier to interface, test, and maintain. It also remove boost as a dependency for python support (which is a huge pain, albeit convent result). I haven’t been working on my side project that was trying to use CEED for a while now as life got busy, but I’d probably be willing to give a Cython wrapper example a try and see if I am missing any constraints in this line of reasoning.
It likely does, or at least takes a more maintainable approach to the root problem. I’m fine with closing this. I haven’t worked on the project I was playing with PyCEGUI in for a couple years now so if I come back to it I’ll likely check what the new status quo is in the library.
Kk, I will migrate cegui to github over these days so you might wanna check there then