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.
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.
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.
Last edited by SpliFF on 19 Mar 2011, 04:33, edited 1 time in total.
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?
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.
Last edited by SpliFF on 19 Mar 2011, 05:45, edited 1 time in total.
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).
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.
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.
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.
Joined: 22 Feb 2006, 01:02 Location: cheap kitchen
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.
Users browsing this forum: No registered users and 1 guest
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum