Support for librocket

[Licho]

Thats not different from chili, except chili is in lua and youc an directly write handlers for onclick etc.

[koshi]

From what I've read so far librocket would actually handle automatic layout/resize, whereas it is my understand chilli does not.
I would see that as a huge benefit.

[Google_Frog]

How are users going to avoid all lua using this html UI? A UI needs information to display which will involve some kind of unit querying and information organisation. This will require lua widgets unless you are going to implement another widget callin framework for use with librocket.

Look into chilli if you have not already. Duplicating the functionality of something without even looking into it risks wasting your time. Chilli has the same "make a table to define an object" format as you have shown for librocket. Chilli UI widgets are mainly made up of a lot of object definitions in Initialise with the rest of the widget changing the information displayed by these objects. I don't see how librocket could be simpler as users must read the information somehow.

Anyway if there are no drawbacks go ahead and implement it. But I am worried that at some point it could become very slow or crashy, not for any good reason but because with new spring versions a few random things become slow or crashy. It is also another potential form of cheating that game developers have to watch as some callin it uses might get more information than a user should have, things like that.

[SpliFF]

Nobody is avoiding Lua. Any UI requires events and scripting. The difference is librocket logically seperates the behaviour (Lua), the structure (RML), and the appearance (RCSS) in a way that means any form of visual design requires only knowledge of the last two formats - and these are 95% compatible with the 2 most recognised markup languages in the design world. This is something no Spring framework can claim. It's importance can't be emphasised enough. Any web designer can design a librocket GUI which increases the potential developer base from the 10 people who understand chilli to the 10 million who understand HTML / CSS.

I've worked in graphic design for 20 years. The fact that I know even 1 language outside Javascript or Actionscript makes me a freak. As a rule the best designers are the worst programmers. Presumably because design is a left brain (creative) activity and coding is right brain (logic). Whatever the reason it's a fact.

As far as performance/stability you need need look no further than Kong which shows absolutely no signs of performance issues despite its GUI being 100% librocket. That's not to say there couldn't be any issues in Spring just that there appears to be no inherent issues in the library itself.

[smoth]

As a rule the best designers are the worst programmers. Presumably because design is a left brain (creative) activity and coding is right brain (logic). Whatever the reason it's a fact.

Sup....

just saying, you are living in a black and white world to make such a categorization. You are probably not THE BEST designer and I don't think anyone here is THE BEST programmer. That is like saying women are the best cooks because many of them live at home man. Completely pointless and baseless statement.

I think it would be a neat patch, hell if it doesn't cause any overhead, why not add support for it?

[SpliFF]

I meant it's a fact that it's a rule, not a fact it's a fact.

[smoth]

I don't agree it is a rule. Asians are not all good at math as a rule.

point remains, I still am asking, will there be any sort of overhead if this is actually added?

[SpliFF]

Well the rendering system will need to ask librocket for any geometry it has to render but presumably if you don't actually have any geometry there won't be anything to handle. I would imagine the same is true of events. I would assume the number of cycles required to handle a screen with no librocket panels would be extremely small as the library can just bail out early on updates.

There will be overhead if you actually have visible librocket panels but that would be true of any UI element including those written in Lua.

Ultimately only testing can really answer that question.

As for the "designers suck at coding" stereotype I find it stands up pretty well to observable evidence - having as I said over 20 years of of education and employment in the graphics and multimedia industry. When you have spent as much time around artists as I have I'll reconsider your position on the topic. We're talking about people who use Macs FFS.

[smoth]

appeal to authority.

[SpliFF]

argument from ignorance

Smoth, it's not that fucking important. As long as there are SOME designers who can't code the argument for seperation of code and design in the UI is valid.

[knorke]

So as this is CSS and whatnot, coud people use an WYSIWYG editor, design their UI with that and then get it into Spring? That would be a plus imo.

[SpliFF]

Up to a point yes. There are some RCSS styles that aren't found in standard CSS and vice-versa. On the whole though it looks pretty compatible with the latest standards. Hell, it supports more CSS than Internet Explorer 6 does and that browser is still in use.

In general I don't think you'd get a completely accurate impression of your layout without loading it up in Spring but often close enough is good enough. I wouldn't be surprised to see specialised librocket WYSIWYG tools appear if the library becomes more popular (I believe it's still fairly young).

[hoijui]

+1 on all spliff just said there!

[Petah]

im for full webkit intergration! including JS and Ajax

[SpliFF]

You are joking right? Webkit has more lines of code than the whole of Spring. It would be Spring embedded in Webkit rather than the other way round.

[Petah]

You are joking right? Webkit has more lines of code than the whole of Spring. It would be Spring embedded in Webkit rather than the other way round.

fine then, what about something else with full JS/CSS3/Ajax then?

[SpliFF]

The trouble with that idea is there's no such thing as a 'lightweight HTML5/CSS3/Ajax browser'. Look at the sizes of actual browsers:

http://www.neowin.net/forum/topic/63494 ... sage-list/

On average a modern browser requires about 30M of RAM just to show a blank page. In actual use most jump up to around 100-200M. Download size is typically around 10M (that's as a compiled compressed binary, in source code form they're going to be bigger). CPU spikes anywhere between 25-75% when loading pages.

Those kinds of loads are really not the kind of thing you want happening in the middle of a battle. Also from a coding perspective you don't want your compile times and source complexity going through the roof.

LibRocket in my opinion is a good middle-ground between insufficient functionality and outright bloat. It's designed to integrate neatly into games without completely taking them over. Chromium/Webkit etc are really intended for uses like rolling your own browser, help systems, WebTV, embedded devices, etc.

[hoijui]

i agree with spliff. thing is, as was already said, that it is unlikely that anyone will integrate it. if someone does it, and it is quite modular (as in, content not using it will not see any side effects), then maybe first ask the other engine devs/ask me to ask them in a meeting, and make sure there is more then a single content dev interested in using this.
i'd like to see something like this.

[SpliFF]

I'm actually not entirely opposed to having a go at this myself. I already know that tying it to Spring's VFS is almost an exact mirror of the process I used for Assimp.

Having said that I'd rather let Assimp settle before taking on another project. I'd also need to work out where the most logical place to merge it with Spring's render pipeline is and what would be involved in replacing Python with Lua (the website says it is supported, but I haven't investigated what's involved).

In a nutshell though the library is designed to integrate easily in a C++ project. It provides classes with some virtual functions you overload to handle IO, events and the geometry it generates. The best part is that unlike many GUI toolkits it doesn't expect to control the main program loop.

In short it sounds like a sensible approach would be to rig up a demo in my own repo and look at the issues involved and potential effects on performance and stability. That way we'll have a much better idea of what the potential cons are.

[knorke]

I wouldn't be surprised to see specialised librocket WYSIWYG tools appear if the library becomes more popular (I believe it's still fairly young).

ok, but at the moment there is no such tool? I mean webdesign is not trivial either.

and make sure there is more then a single content dev interested in using this.

It would probally take a while until someone seriously started using it. The most games use chili or have already done their own UI. As chili gets better (and better docu) it will probally spread more and have a headstart.
Oh, and would this allow for resizing and moving of elements? ie a tooltip that follows the mouse. Will it be possible to reload the UI ingame like with Lua?
What elements would there be, windows, buttons, scrollbars, checkboxes, drowndown menus,..? Could this the replace the engines command/build menu? Is it even possible to make moveable windows in HTML without javascript?
I am quite happy with my Lua UI now but I think those are some questions game makers would be interessted in.