[m!m]

I have an initial working implementation of the libRocket integration into FSO:


(the text and the image in the top left is the stuff that was drawn by libRocket).

Implementing the required interfaces was actually pretty straight forward and upon closer inspection, the framework seems flexible enough for our purposes. I still need to implement the animation display but hopefully that won't require too much effort.

[m!m]

Development update:


I have added support for handling input and I also already a few debug features. All current documents can be reloaded with Ctrl+Shift+R so modders don't have to exit the game to test their changes. Also, I added support for activating the integrated debugger which is also shown in action above.

However, while adding these new features I have also found a few bugs in libRocket and since development has pretty much stopped at this point we would have to fix all the bugs we find ourself. The development time so far has been pretty minimal so this would be a good time to reconsider alternative solutions if they exist.
Does anyone have a solution that could work better than libRocket?

[chief1983]

Is it that dead?  They had commits as recently as November.  Someone might still be merging PRs.

[The E]

They've had commits, but they also have an untreated bot infection on their main forums and no releases in two years.

[jg18]

Yeah IMHO we can't use a library  that isn't actively developed/supported/maintained, as cool as this library sounds. Besides bugs that may never be fixed, if compatibility with for example future OS changes breaks, we'll be up the creek.

[m!m]

Do you know another solution? Even in its current state it's pretty good so "no longer in development" would just go into the "Reasons against" list which would not automatically disqualify the library.

[The E]

I would agree. Given that this library isn't built on top of OS functionality (Like wx), I think the risk of running into incompatibilities is reasonably low, and if the necessary bugfixes are trivial, I see no real reason not to use it.

[jg18]

Okay, then.

[m!m]

I think I'm more or less done with the initial integration. GitHub branch is here: https://github.com/asarium/fs2open.github.com/tree/feature/libRocket

This should support everything that is needed for most UI screens. It doesn't have support for animations yet but it should be possible to add support for that at some point by adding a new element type. The current version even has support for localization since that is pretty easy to support thanks to how libRocket works.

I'll try to go ahead and build an options menu using this library which will probably expose a few more bugs.

Also, I currently named the new system simply "NewUI". Does anybody have a better name for it?

[X3N0-Life-Form]

SCPUI ? RocketUI ?

[m!m]

I like SCPUI, I'll use that.

[karajorma]

You should have gone with Even Snazzier UI.

[Darklord42]

Sounds really neat!  I suppose since it is dead,  future maintainability is important to you, and you intend on making it mission critical,  why not fork it and make it a sub project of FS2O on git?   Especially since you say currently no work needs to be done on it, and it has an MIT license.

[m!m]

I already use a fork of the project in my development branch. If it gets merged into the master then that fork would be transferred to the SCP organization.

[Darklord42]

Oh great!  Then problem solved, right?

[m!m]

No, the fundamental problem that the project isn't in development anymore still exists.

[Darklord42]

But you intend to fill that role for your own purposes.  If you can manage it, sometimes it's better not to have to rely on an upstream team as you know your needs better then anyone else. And this is already mature software, right?

[m!m]

I would like to avoid maintaining a code base I have no experience with. It would be better if I could just report a bug to upstream and get some help with fixing it.

[Darklord42]

I'm not saying being a pain isn't a con, but there are other advantages to it.  Eventually making it your own is one.

But, if the code is a mess and not maintainable or isn't commented very well, then that should be a good strike against it.

[karajorma]

Maybe the fact that it's being used might get some of the original team interested again. Might be worth a try to use the old "I'm interested in using your library in my software, I've got it working but I was wondering if it's still in development" trick.