Spring RTS Engine

Redacted

https://github.com/jk3064/chiliui
source

http://springrts.com/wiki/Chili
wiki

http://gajop.github.io/chiliui/
docs

chili repo also has example widgets

Note: Don't bother reading this if you don't know what a git submodule is, it'll just confuse you.

Btw, if you are a fan of git like myself you may consider setting chili as a submodule, it makes keep chili uptodate much easier.

Check https://github.com/gajop/Scenario-Editor-Core/ and https://github.com/gajop/IngameLobby, but basically what I do is pull chili as a submodule in libs/chiliui and then copy the api_chili.lua to the LuaUI/widgets folder and set it to load chili from libs/chiliui.
That way you can just pull the chili submodule each time there are major updates upstream (and you can contribute back easy).

Redacted

To make things clear, the chili repository only contains elementary controls, skins and utility functions.

There is no (that I know of) common repository that contains chili widgets for a generic Spring game, you will have to dig those out from each game individually.
Sadly, your best bet will be to dig those things out from ZK or BAR.

Jools that is not the advantage or even point of Object oriented. Please don't use the term as a buzzword.

your widgets may USE objects and their properties/methods but your code might still be only using bits and pieces. OO is just a concept not a language wrapper.

also gajop my repo is out there.

Redacted

My use of wrapper was closer than your usage of OO. I did nothing wrong, I was illustrating how off you were.

Redacted

Don't you mean table oriented programming?

Redacted

Jools wrote:I mean, if I could do things like:

Code: Select all

progressBar myprogressBar = new progressBar("grey");

In principle it is like that, just that the progressBar needs some more parameters than just "grey".

A progress bar might be something like:
and then to change the value of progress bar:
v---general choatic blabla about chili---v

Chili widgets are imo two parts, also seen in above example.
1) The definitions of the buttons, labels, windows. (That is basically just tables.)
Can be some hundreds lines, even for relatively few UI elements example https://github.com/ZeroK-RTS/Zero-K/blo ... s.lua#L515 and sometimes looks confusing, if you do not know what the end result is supposed to look like on screen.
2) The logic. For example myprogressBar :SetValue(metal)

Problem seems to be that sometimes people copy over some widget into their mod and then want to customize the definitions, which is pretty straightforward, for example editing color = {0.5,0.5,0.5,0.5}
But when the original widget gets some updates, now there is the problem how to merge in the changes, without losing your own customized stuff.
So maybe having the definition-stuff and logic-stuff in seperate files might be useful in some cases?
But for original author it is maybe just extra work.

Another problem is longcat.
What is longcat:
-long
-after a while not very interessting
-it follows the format of bla = blub.

For example many wupdgets begin with a long list of It is something that is needed in some way but you never want to mind about it, there is nothing interessting happening, but still takes up many lines.

Other examples of longcats are:
-long lists of constants
-- https://github.com/spring/spring/blob/d ... lors.h.lua
-- https://github.com/spring/spring/blob/d ... keysym.lua
-unitDefs or unit-definitions stuff to be used in similiar way
--https://github.com/ZeroK-RTS/Zero-K/blo ... e_defs.lua
--https://github.com/ZeroK-RTS/Zero-K/blo ... cmds.h.lua

Longcats are nessecary but one does not want them to block view all the time.
Sometimes it is very easy to ignore longcat, for example the localisation-speedup-things are easy to scroll past. Some longcats have lots of {,.[{[%{=]}]=,])) where one has to look slower.

picture of longcat: http://springrts.com/phpbb/download/file.php?id=8998
Usually it is easy to get longcat out of the way: for example by putting him into a config file.
However...

The chili longcats are outta control
With chili one uses many tables and lines to describe the GUI elements.
That is okay, however it is a longcat. It is longcat with many {,.[{[%{=]}]=,]))

The thing is how the logic-things can get mixed into the longcat definition-things.
For example if you want the function DoSomething() to be called when a button is clicked, one might add into button-definition:

OnMouseDown = {DoSomething()}

But seems sometimes one justs wants to do something "small" and then it can be put directly into the definition and there is something like...
Think below snippet is from some resource-bar where you can click to set the reserve level, like share-level works in engine default resource-bars.
So one needs to get position of where the bar was clicked on, and translate that into some 0%-to-100% value, because 0-to-100 is maybe what the logic expects but the resourcebar has maybe width of 1234 pixels. So the "interessting" logic part can be "hidden" inside some loooooooooong uninteressting list (all the UI elements and their color, positions, size, tooltips,...), where one just scrolls and scrolls and scrolls past. Who knows what longcat is hiding in belly? That makes it somewhat cumbersome to look at code of others.

But when the original widget gets some updates, now there is the problem how to merge in the changes, without losing your own customized stuff.

Something something Github

I do agree with the point that the separation between definitions of UI elements and the code that then controls them makes for awkward updating when games borrow each others code. But widgets have suffered from the problem in various forms for as long as I can remember. I think the only solution is competent game devs; with that, which for the most part Spring does have, it's imo completely manageable, especially with github/svn/winmerge and friends. Also, on my experience (I currently maintain both Chili and non-Chili stuff), within a given widget, that separation makes for much better modularized code (besides the more visible benefits of Chili).

Jools wrote: To me this is the biggest shortcoming of chili, as the whole idea of delegating the GUI part to a third party to me would be to outsource the management of that part and instead concentrate on my core business.

But if I anyway have to write the widgets/gadgets from scratch instead of extending a class object, then what is the benefit to use chili in the first place?

I mean, if I could do things like:

Code: Select all

progressBar myprogressBar = new progressBar("grey");

Then I would see the benefits.

Installing chili is not difficult, but there is no API: there's just a object hierarchy chart and three tutorials: http://springrts.com/wiki/Chili

The Chili Component Hiearchy would be a good outline from which to build an API.

You seem to be very confused in what chili is. In particular, Chili (like every other GUI library, e.g.: gtk, win forms, QT, android GUI, etc.) is only meant to provide a way to create and manipulate basic GUI controls, such as: button, label, editbox, combobox, window, checkbox, scrollpanel, layoutpanel, etc.

It is not meant to provide complete widgets such as resource bars, unit commands, selected units, game menu and similar. This is something you will have to find elsewhere: write it yourself, copy and adjust from a different game or make a separate widget collection/library that depends on chili (which is hard since every game has slightly different concepts).

Also, there's an API (probably slightly outdated and incomplete) that can be found in the link you gave.

Jools wrote:Redacted

Please don't pull an argh.