Good news everyone!
I’m proud to announce that the GUI Editor has taken a giant leap forward!
Until now it was only possible to modify an existing GUI with it, but from now on it will also be possible to create a brand new GUI from scratch!
While this doesn’t mean that it’s finished, and ready for production use, it’s like I said a giant leap into the right direction!
Here’s a video showing the workflow for creating a new GUI and using it with Ryzom:
Can be a real pain!
Ryzom Core Studio is a cross platform tool, the entire point of creating it was to move away and get free of the shackles of Windows as the old Ryzom tools were written with MFC.
Unfortunately two of it’s plugins kept triggering an assert when loaded together.
As it turns out the source of the problem was that GCC and Visual Studio link libraries differently:
Ryzom is built on Nel the Nevrax libraries. One of these libraries is the LIGO library, which is basically a data library. Also Nel uses a quite powerful (de)serialization system which is based on an abstract object factory, which is implemented using static methods and static member variables. What’s also important that these Nel libraries are linked statically right now.
Unfortunately as it turns out it behaves differently depending on which compiler built it: GCC or Visual Studio.
When building with Visual Studio each plugin gets it’s own instance of the static variables, while with GCC they share the same one.
So when the LIGO library is started up, it registers it’s classes. When the first plugin that uses it loads there’s no problem, but with the second an assert is triggered because those classes have already been registered.
In this case solving this problem was fairly simple: Since those plugins use their own LIGO configs ( a context object of sorts ), guarding against multiple registrations was enough.
I’ve been getting complaint about the Ryzom Core Studio GUI Editor plugin crashing instead of rendering what it should, so I did a little investigation. Apparently if you try to render OpenGL into a simple QWidget it will crash the driver ( at least the Intel one I have on my lappy ).
The solution: use QGLWidget instead of QWidget on Linux, even if you don’t use the rendering features of it.
The screen shows it working on my HP 6910p laptop, running XUbuntu 14.04.
So as I found out not so long ago, different compilers handle this one totally differently ( they provide the names in a different format ), so it’s totally unreliable for cross-platform development.
This is probably in the spec, but I can’t recall reading this in any book I’ve read. It could have saved me lots of hair pulling while trying to find the issue in my code…