Dev meeting minutes 2011-03-21

[jK]

I get the feeling there's an awful lot of complaints based on misinformation and/or generalisations about "things" without examining the facts. I'm going to try again to clear some of that up.

How is that different to the complaints against chili?

I only ever put this forward as a feature request. Since it's clear no other devs are keen to develop it I have only 2 options: forget about it or do it myself. I *MAY* do it myself. If that happens, as with the assimp project, it will happen in an independent development branch. It would ONLY be merged with Spring if the consensus was there but at least that consensus would be based on solid evidence rather than the half-arsed and outright false evidence being presented in this thread.

In short, if people feel the need to object then do it based on reality not some fucking fantasies put forward by people with no goddamn clue of how librocket works.

If I would react this way every time ppl say wrong things about chili, I would be in a funny farm.

To complain about librocket you have to understand it. To reiterate, Librocket is a UI middleware that uses a subset of HTML/CSS and Python script for the interactive aspects. According to the librocket authors the Python scripting was designed to be interchangeable with other languages - ie, Lua, C++ or Javascript for example.

And still it has to be CODED, the Kong game you mentioned uses neither Lua nor is it opensource! You would have to pass down the keyboard/mouse events, you have to write a Lua DOM, you would have to write the Lua userdata objects, you would have to integrate Lua in librocket itself, ...

With Chili it's a sort of mish-mash of object creation, function calls, function parameters and scripting.

Erm chili is not a mishmash of these! If you want that ppl talk professional with you stop using pejorative languages against their work just to fortify your opinion!

Some people here are saying that is true of Chili. It is not. There is a considerable amount of work between the Photoshop stage and the UI that the examples given completely gloss over. This stage is provided by HTML/CSS in librocket without any need to code Lua.

Erm I am not a random guy coding his first GUI framework. I coded and worked with a lot frameworks and use _standard_ skin formats!

D.) Would likely lack features due to jK's time constraints and priorities versus those of the librocket team.

If you want that jK works on more `visual` things, then you have to _help_ him with the crap he is doing right now.
I spend much time on bugs and cleanups, quite simple but very annoying things. So I had to fix the crashhandler a second time (yeah, we got a linux watchdog now but it is nothing I really really wanted to add) and yeah it is still not fully functional (e.g. it doesn't print a stacktraces for div-by-zeros). I didn't wanted to rewrite half of the sound interface structure to fix the soundvol bug, I didn't wanted to rewrite half of lualobby just because the implementation sucked, I didn't wanted write a new widgetHandler (there should many ppl in the community able to do so!), ...
All these things are small things but eat time I can't spend on the things I really want to do (Chili, new terrain rendering, new model rendering, OpenGL3/4 features, ...).
I already noted in a meeting we need a special forum with such small thingies, so new devs have starting projects and could support the devs. But hey I am just a random guy talking out of his such crazy mind ...

[hoijui]

smoth, you should re-read the thread or something. your questions do not make sense.

[FLOZi]

I already noted in a meeting we need a special forum with such small thingies, so new devs have starting projects and could support the devs. But hey I am just a random guy talking out of his such crazy mind ...

May I just slip in a big +1 to this.

(The forum, not the random crazy guy part )

[smoth]

I am saying that ...
I am saying that ...
I am saying that ...

They are saying it is a plus.

Separating design from coding is good.

I am trying to see how they are going to bridge this. I don't care if they do or don't just wondering how will it work out.

[Pxtl]

@SpliFF - question about the Python-based script system - is this just for internal event-driven manipulation of the DOM, as Javascript does in a web-page?

I mean, if it's directly binding to the main Spring lua interpreter for event handling and DOM manipulation, I could see that would be pretty clean and nice - but if it needs a separate Lua interpreter for those things, it'd be a bit ugly, even though you'd use the same language for both ends.

I think the only reason people are skeptical about this is that Zero-K has done so very much with Chili using the pure Lua interpreter.

[Forboding Angel]

I am saying that ...
I am saying that ...
I am saying that ...

They are saying it is a plus.

Separating design from coding is good.

^^ This. I could design a fantastic UI in html/css. In lua, I can probably manage to draw a box and put some words in it.

With the html/css I could design the UI, then pass it off to the supposed lua dev, and he could make it actually work. In other words, to design a UI, I no longer have to know lua.

[SpliFF]

To directly answer smoth and pxtl's questions about whether the Lua UI scripting is independent from the game Lua scripting.

I have not studied the librocket code in depth but from the API and developer pages I get the impression that librocket does not really care how it's events get handled by the script layer. As librocket itself is primarily a C++ component it is only concerned that it passes an event to the C++ event handler and gets back a response. The same is true when script wants to modify the UI. Between the event and the response is our code so whether we want to create a new Lua state or use an existing one is a decision the library does not appear to force in any way. Either way we control the script interface, not librocket.

So given we almost certainly have a choice it's really up to us whether we want to talk directly with the widget handler through callbacks or create a new Lua state. The widget handler handling the UI makes the most sense and that's how I would want to implement it but using a new state could be part of the overall strategy to spread processing across more system threads (ie: the Lua-split debate).

There's also got to be some thought on whether we need a new Lua state for the engine main menu and frontend or whether we should load the widget handler as soon as the engine starts. Also how LuaLobby might fit into the picture if we wanted to build a game browser / lobby in the engine itself.

One thing is certain. As jK correctly pointed out there is a lot of work involved in building the script<->librocket bridge, but it also means we have a lot of control over how we implement it. We control librocket, not the other way around. This is a significant advantage over systems like QT which force you to use their main loop.

On the positive side I've seen 3 projects that claim to use librocket+Lua.

http://www.youtube.com/watch?v=wM6Wrc6I ... re=related
http://www.youtube.com/watch?v=IdMU48saXaY
http://www.youtube.com/watch?v=Mqt7Cavp ... r_embedded

This is good news on 2 levels. Firstly it means that Lua integration is achievable. Secondly I believe one of those projects (the fluid dynamics simulator) is an open-source project.

@jK: You're right I should keep my criticism of Chili to a minimum. I don't know enough about the skin interface or your future plans. At any rate I have no actual beef with it and no intention to replace it despite what some people seem to be claiming. At the same time there are pros and cons of both systems which is why I'm for having another choice (just like I was for having a choice between S3O/3DO and other formats).

[smoth]

I have no idea why people would feel you are trying to replace chili. Honestly though I figured people were mostly trying to save you from wasting time... but then again, if you want to do it, is your time really wasted? I think not, it is your time after all.

[Forboding Angel]

I like chili, I don't think I ever implied otherwise, however, I can see the giantly massive advantage of having librocket would be.

I dunno if I know enough about xml to bitch, but I don't like the thought of using xml for a gui (as was proposed for chili), but seeings as how I can't exactly do my own stuff for chili really, I don't really have a whole lot of room to talk.

[Google_Frog]

Forb, it sounds like if you cannot do your own stuff with chili you will not be able to do it with librocket. You will still need to write something in lua to make your UI interact with the game and the code will be as complex as it is in chili. The difference seems to be that librocket windows are defined externally in html while the chili windows are defined in the widget by creating a few objects.

[Pxtl]

Forb, it sounds like if you cannot do your own stuff with chili you will not be able to do it with librocket. You will still need to write something in lua to make your UI interact with the game and the code will be as complex as it is in chili. The difference seems to be that librocket windows are defined externally in html while the chili windows are defined in the widget by creating a few objects.

And remember that if you want to do more complicated things like lists and whatnot, you'll likely still have to construct much of your logic in Lua to manipulate the DOM and even create LibRocket objects dynamically entirely in Lua.

A more familiar GUI system like HTML+CSS would improve the ease of creating new GUIs in Spring, but it's not panacea. And it's not like HTML+CSS doesn't have its own collection of hideous idiosyncrasies as well. When players start asking for draggable or resizable GUI elements, your Librocket-based GUI code will end up just as hideous as your pure-Lua code. So we'll still need Chili-style frameworks in the back to make things like that easier.

Which isn't to say that LibRocket wouldn't bring some awesome things to the table. Just that anybody who has coded a really, really dynamic web-page knows how messy DOM manipulations can get once you've got specific ideas on how things should work.

[AF]

Announcing my new project, LQuery!!....

[CarRepairer]

Announcing my new project, LQuery!!....

Lua code is already so concise by design that you can compare it to jquery already. Here's some Chili example, call it MVC or whatever you want.

Code: Select all

--Coder's code
local function ShootSuperGun(self)
	Spring.SendCommands(self.unitID, ...asdfasdfasdf)
	EmitCrazyCEGs(...qwerqwerqwer...)
	...
end
	
local function initalize()
	local charwindow = screen1:GetChildByName('charstats')
	charwindow.unitID = Spring.GetSelectedUnits()[1]
	charwindow:GetChildByName('supershootbutton').OnClick = { ShootSuperGun }	
end


--Designer's design

local red = {1,0,0,1}
local green = {0,1,0,1}

Chili.Window:New{ 
	name='charstats',
	caption='Character Stats',
	parent=screen1,
	children = {
		Chili.Button:New{ name='supershootbutton', label='Shoot Super Gun', color=red, width='50%' }
		Chili.Button:New{ name='singbutton', label='Sing!', color=green, bottom=1, width='50%' }
	}
	
}
	

[Pxtl]

@Car, that actually looks kind of like ExtJS.... which is a project that creates Windows-like GUI interfaces out of HTML+CSS+Javascript, no hand-coding HTML required.

It's turtles all the way down.

[smoth]

It's turtles all the way down.

[Forboding Angel]

Forb, it sounds like if you cannot do your own stuff with chili you will not be able to do it with librocket. You will still need to write something in lua to make your UI interact with the game and the code will be as complex as it is in chili. The difference seems to be that librocket windows are defined externally in html while the chili windows are defined in the widget by creating a few objects.

With the html/css I could design the UI, then pass it off to the supposed lua dev, and he could make it actually work. In other words, to design a UI, I no longer have to know lua.

[SpliFF]

And remember that if you want to do more complicated things like lists and whatnot, you'll likely still have to construct much of your logic in Lua to manipulate the DOM and even create LibRocket objects dynamically entirely in Lua.

While there will be times you will want to manipulate your UI from Lua to create/hide/modifying custom UI elements it should be noted that your example of "list" is already a native element. Your RML would be:

Code: Select all

<select id="chooser">
   <option>Pick me!</option>
   <option>No! Pick me!</option>
</select>

If you had to build it dynamically it would be something like

Code: Select all

local chooser = librocket.getElement("chooser")
for optText in ipairs(myOptions) do
  local opt = chooser:addChild("option")
  opt.val = optText
end

Note that in this code example the 'chooser' element already exists (but empty) in the RML so I can still design it without concern for its dynamic contents.

There are also native elements for text input, tables, radio and checkboxes, sliders, windows, buttons and images. Style support includes complex border styles and backgrounds, custom fonts, shadows, scrollbars, floating and clipping. Event support includes drag-and-drop, mouseover, click, keypress etc.

Obviously you need to hook events up to your Lua but I'm just saying you'd be surprised how much you can achieve without resorting to writing your own Lua elements.

[AF]

But its no substitute for:

Code: Select all

$('#charstats Button').hide();

[smoth]

btw. I didn't have time to double check my app architecture but I did so this morning.

fwiw. I hate MVC I prefer the linear approach of n-tier, specifically 3 tier architecture