Artistry
Moderator: Moderators
- Funkencool
- Posts: 542
- Joined: 02 Dec 2011, 22:31
Re: Chili repository
https://github.com/jk3064/chiliui
source
http://springrts.com/wiki/Chili
wiki
http://gajop.github.io/chiliui/
docs
chili repo also has example widgets
source
http://springrts.com/wiki/Chili
wiki
http://gajop.github.io/chiliui/
docs
chili repo also has example widgets
Re: Chili repository
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).
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).
Re: Chili repository
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.
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.
Re: Chili repository
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.
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.
Re: Chili repository
My use of wrapper was closer than your usage of OO. I did nothing wrong, I was illustrating how off you were.
Re: Chili repository
Don't you mean table oriented programming?
Re: Chili repository
In principle it is like that, just that the progressBar needs some more parameters than just "grey".Jools wrote:I mean, if I could do things like:
Code: Select all
progressBar myprogressBar = new progressBar("grey");
A progress bar might be something like:
Code: Select all
myprogressBar = Progressbar:New{
parent = window,
y = 8,
x = 10,
width = 280,
height = 20,
max = 100;
caption = "progress of something";
color = {0.5,0.5,0.5, 1}; --"grey"
value = 1,
}
Code: Select all
myprogressBar :SetValue(75)
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
Code: Select all
Spring.Echo = spEcho
Spring.CreateUnit = spCreateUnit
Spring.CreateFeature= spCreateFeature
...
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:
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...OnMouseDown = {DoSomething()}
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.
Code: Select all
bar_metal = Chili.Progressbar:New{
parent = window,
color = col_metal,
height = p(100/bars),
right = 26,
x = 110,
y = p(100/bars),
tooltip = "This shows your current metal reserves",
font = {color = {1,1,1,1}, outlineColor = {0,0,0,0.7}, },
OnMouseDown = {function() return (not widgetHandler:InTweakMode()) end}, -- this is needed for OnMouseUp to work
OnMouseUp = {function(self, x, y, mouse)
if widgetHandler:InTweakMode() then return end
local reserve = x / (self.width - self.padding[1] - self.padding[3])
updateReserveBars(true, mouse ~= 3, reserve)
end},
}
- Attachments
-
- longcat.png
- (248.25 KiB) Downloaded 5 times
-
- Posts: 1398
- Joined: 17 Sep 2008, 04:36
Re: Chili repository
Something something GithubBut when the original widget gets some updates, now there is the problem how to merge in the changes, without losing your own customized stuff.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Chili repository
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).
Re: Chili repository
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.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:
Then I would see the benefits.Code: Select all
progressBar myprogressBar = new progressBar("grey");
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.
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.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Chili repository
Please don't pull an argh.Jools wrote:Redacted