http://www.librocket.com/

It's a UI middleware for creating windows/panels using a subset of HTML and CSS (called RML and RCSS respectively). In short if you want UI elements like tables or select boxes you design them in RML/RCSS and then load them through librocket.

The advantage of this approach is it removes the requirement for the UI designer to know Lua. Most designers aren't programmers so building your Spring UI currently requires a programmer to translate the designs into OpenGL calls.

LibRocket supports many GUI elements that are difficult to implement in Lua/OpenGL. Elements that come to mind are tables with dynamic cell resizing, drop-down lists, flowed content, floated elements, scrolling content, forms, tabs, backgrounds, borders and UI events like drag-and-drop. I'm not saying you can't do these things now, just that they are difficult and generally ugly to code.

I looked around at a variety of UI middleware but most are either:

1.) too ugly (fltk,gtk,etc)
2.) don't work over OpenGL (most of them)
3.) too heavy (QT,webkit,etc)

libRocket appears to provide enough CSS support for elegant designs without being prohibitively complex.

Chili has been designed to look like CSS. The ZK team has non-programmers able to modify the look and feel of our UI with ease.

would be awesome, but i guess it just won't happen unless you add it yourself

Why not Berkelium?

Then instead of a subset of html+css in a library that runs at an okayish speed, we get the efforts of the Google Chrome team, a full HTML5 CSS webkit browser, minus flash/silverlight, complete with javascript engine and wrapper interface.

Prefer to build your UI using photoshop+dreamweaver+JQuery?

I didn't know about Berkelium. It's practicality would probably depend on its size and ease of integration. I don't know enough about either project to comment on which is best.

Where did you hear that librocket runs at "okayish speed"? Is that just an assumption that Google writes better software or based on evidence?

Its based on the assumption that librocket doesn't have the sheer force of momentum that Google is pushing into Chromium/Google Chrome/Chrome OS, nevermind the side contributions pulled from webkit and Apple/etc.

If Mozilla and Microsoft are barely keeping up with Googles frenetic pace, can librocket?

libRocket is intended to be a lightweight UI for games. Berkelium is intended to be a fully functional HTML5 webbrowser. Regardless of who is developing them they have distinctly different priorities.

Honestly, all other concerns aside I can't see the other devs being exited about embedding millions of lines of browser code in Spring. It's a huge increase in complexity for the sake of being able to use CSS3 and Javascript inside an embedded window. I see it as overkill.

lightweight as in not as laggy as chili?

I agree.


viewtopic.php?p=404095#p404095
Explain me why jk is lying.

a challenger apears
not a single person has proven it.

Chilli is slow is the new creationism.

Chilli is slow is the new creationism.

Sure let me take some screens...

I think what people mean is chili shows little difference in performance on decent computers. However, on older/ low end computers... well let's see.

What is decent what is old?

I am running on a 2 year old pc:
8gigs of ram
nvidia 280
dual 3.5ghz
lotsa hd space with all that porn gone.

Who cares?
"computer too slow for chili" is like super retarted.
Most players with these problems can run at decent details and everything... Just some chili widgets cause the fps problems.
It is like being able to play Crysis or Call of Duty (or w/e is the newest highend graphic shooter atm) at high detail and then you press tab for the scoreboard and the screen freezes.
btw nice derail.

So, this librocket
-could you post an example how ie some buttons with this would look like code wise? Really just html?
-To interact with Lua, would there be new lua functions ie a callin "LibrocketButtonClicked (buttonname)"?
-would it be possible to change the UI runtime, ie adding a button for every selected unit and removing the button if the unit gets deselected?

considering browsers cannot do css/html right consistently and even have very huge inconsistencies between them I don't want to imagine using html to setup ui elements.

Somebody asked for samples. I looked around and found a commercial game using librocket with a nice clean design (as opposed to the butt-ugly sample linked from the librocket project site).



The settings panel shown above is defined entirely using RML and RCSS templates - as is the main menu below it and the background (which is a simple JPG). Even that funky color slider.

All UI events are mapped to python events (though librocket can support Lua and other bindings as well). The Python support is optional, it can be removed entirely and replaced with Lua bindings.

I also captured some video of the UI in action (YouTube).

The UI was perfectly smooth, even running under Wine. The shearing and stuttering artifacts you see in the video is from the screen recording process (VLC screen://).

You can download Kong free at http://www.konggame.co.uk/

I am a bit dubious about another UI framework. Unless it is significantly faster than lua (Chilli specifically) I do not see the point. I also prefer chilli as it is entirely lua which means it is not subject to failing because bugs are added to the engine every version and the development cycle for fixes can be much shorter,

When looking at the benefits of a UI framework, performance is one the last thing to consider. Honestly how often do you see a slow GUI these days? If it was a consideration I'd really have to say it's extremely doubtful librocket would be slower than existing Lua frameworks considering its foundation classes are C++.

On the other hand the top of my list of things to consider is how easy it is to use. Now I can't comment on any of Spring's existing frameworks for the simple reason that I haven't used them.

What I can say though is that every designer on the planet under the age of 30 should by now be familiar with HTML/CSS and/or the tools that generate them (like Dreamweaver). Hell, even MS Word can save as HTML (terrible, ugly, non-standard HTML but still...).

With LibRocket I can create a a batch of HTML files with the GUI elements I want already defined and scripted and give it to a designer who can then create CSS files for me. That designer wouldn't need to know any coding at all. They wouldn't need to touch my markup either as CSS can and should be defined in a seperate file. This is called seperation of presentation and logic (or MVC in jargon) and it's a fundamental part of good software and website design.

On the other hand the number of people on the planet who are both good designers and good Lua programmers must be tiny. If you want somebody who is a good designer to design and implement a Lua interface they'd pretty much have to learn both Lua and the UI framework from scratch.

So the REAL question here is NOT which framework is faster but who you are more likely to find to work unpaid on your game; the 1/100,000 designer who can competently code Lua or the 99,999/100,000 designer who can do CSS?

And for the record, nothing in the integration of librocket would prevent chili or any other framework from being used. It's about offering more choices, not replacing existing ones.

Actual code samples:

RML with embedded scripts and styles



RCSS