diff options
Diffstat (limited to '')
-rw-r--r-- | ClientHamr/GuiLua/GuiLua.c | 81 | ||||
-rw-r--r-- | ClientHamr/GuiLua/skang.lua | 52 |
2 files changed, 53 insertions, 80 deletions
diff --git a/ClientHamr/GuiLua/GuiLua.c b/ClientHamr/GuiLua/GuiLua.c index e0efd00..2b5f161 100644 --- a/ClientHamr/GuiLua/GuiLua.c +++ b/ClientHamr/GuiLua/GuiLua.c | |||
@@ -160,86 +160,7 @@ database stuff for now, but should keep it in mind. | |||
160 | 160 | ||
161 | /* skang package | 161 | /* skang package |
162 | 162 | ||
163 | In here should live all the internals of matrix-RAD that don't | 163 | Currently this is in skang.lua, but should bring this in here later. |
164 | specifically relate to widgets. This would include the "window" though. | ||
165 | |||
166 | skang.module(Evas) | ||
167 | skang.module(Elementary) | ||
168 | skang.load('some/skang/file.skang') | ||
169 | |||
170 | This package is also what "apps" that use the system should "inherit" | ||
171 | from, in the same way matrix-RAD apps did. Skang "apps" could be Lua | ||
172 | modules. They could also be C code, like the extantz modules are likely | ||
173 | to be. Skang "apps" would automatically be associated with skang files | ||
174 | of the same name. So a Lua skang "app" could look like this - | ||
175 | |||
176 | local skang = require('skang') | ||
177 | local result = {}; | ||
178 | result.author = 'onefang' | ||
179 | result.version = '0.72 alpha 2004-11-19 16:28:00' | ||
180 | local bar | ||
181 | -- The first argument would be the name of a local variable / method. Which could be accessed via _G? | ||
182 | -- Not sure if we could use a global bar, AND use it directly. | ||
183 | result.bar = skang.newParam('bar', "Required", "Shortcut", "Default", "Help text") | ||
184 | result.func = skang.newCommand('arg1_type,arg2_type', 'Help Text', function (arg1, arg2) | ||
185 | ... do something here ... | ||
186 | end) | ||
187 | |||
188 | ... do something here ... | ||
189 | |||
190 | return result; | ||
191 | |||
192 | |||
193 | A basic skang file could look like this - | ||
194 | |||
195 | #!skang myApp.skang | ||
196 | -- There's an implied local this = require('myApp') | ||
197 | -- There's an implied local skang = require('skang') | ||
198 | local widget = require('EvasWidgets') | ||
199 | local other = require('otherPackageName') | ||
200 | skang.clear | ||
201 | skang.window(200, 200, "G'day planet.") | ||
202 | quitter = widget.button('Quit', 0.5, 0.5, 0.5, 0.5) | ||
203 | quitter:action('quit') -- 'quit' is looked up in ThingSpcae.commands, and translated into the Lua 'skang.quit()'. | ||
204 | other.foo = 'stuff' | ||
205 | this.bar = other.foo | ||
206 | this.func(1, 'two') | ||
207 | |||
208 | The skang command (written in C) would strip off the first line, add the | ||
209 | two implied lines, then run it as Lua. The skang.load() command would | ||
210 | do the same. So that skang C comand would just pass the file name to | ||
211 | skang.load() in this library. B-) | ||
212 | |||
213 | |||
214 | The old skang argument types are - | ||
215 | |||
216 | {"name", "java.lang.String"}, | ||
217 | {"action", "java.lang.String"}, | ||
218 | {"type", "java.lang.String"}, | ||
219 | {"data", "java.lang.String"}, | ||
220 | {"URL", "java.lang.String"}, | ||
221 | {"file", "java.lang.String"}, | ||
222 | {"method", "java.lang.String"}, | ||
223 | {"lx", "java.lang.String"}, | ||
224 | {"ly", "java.lang.String"}, | ||
225 | {"lw", "java.lang.String"}, | ||
226 | {"lh", "java.lang.String"}, | ||
227 | {"normal", "java.lang.String"}, | ||
228 | {"ghost", "java.lang.String"}, | ||
229 | {"active", "java.lang.String"}, | ||
230 | {"toggle", "java.lang.String"}, | ||
231 | {"boolean","java.lang.Boolean"}, | ||
232 | {"number", "java.lang.Integer"}, | ||
233 | {"int", "java.lang.Integer"}, | ||
234 | {"x", "java.lang.Integer"}, | ||
235 | {"y", "java.lang.Integer"}, | ||
236 | {"w", "java.lang.Integer"}, | ||
237 | {"h", "java.lang.Integer"}, | ||
238 | {"r", "java.lang.Integer"}, | ||
239 | {"g", "java.lang.Integer"}, | ||
240 | {"b", "java.lang.Integer"}, | ||
241 | {"alpha", "java.lang.Integer"}, | ||
242 | {"acl", "net.matrix_rad.security.ACL"}, | ||
243 | 164 | ||
244 | */ | 165 | */ |
245 | 166 | ||
diff --git a/ClientHamr/GuiLua/skang.lua b/ClientHamr/GuiLua/skang.lua index 25aedac..1b0a199 100644 --- a/ClientHamr/GuiLua/skang.lua +++ b/ClientHamr/GuiLua/skang.lua | |||
@@ -1,3 +1,55 @@ | |||
1 | -- TODO - This should be in C, but so far development has been quite rapid doing it in Lua. | ||
2 | --[[ | ||
3 | In here should live all the internals of matrix-RAD that don't | ||
4 | specifically relate to widgets. This would include the "window" though. | ||
5 | |||
6 | skang.module(Evas) | ||
7 | skang.module(Elementary) | ||
8 | skang.skang('some/skang/file.skang') | ||
9 | |||
10 | This package is also what "apps" that use the system should "inherit" | ||
11 | from, in the same way matrix-RAD apps did. Skang "apps" could be Lua | ||
12 | modules. They could also be C code, like the extantz modules are likely | ||
13 | to be. Skang "apps" would automatically be associated with skang files | ||
14 | of the same name. | ||
15 | |||
16 | For a .skang file, the skang command (written in C) would strip off the | ||
17 | first line, add the two implied lines, then run it as Lua. The | ||
18 | skang.load() command would do the same. So that skang C comand would | ||
19 | just pass the file name to skang.load() in this library. B-) | ||
20 | |||
21 | The old skang argument types are - | ||
22 | |||
23 | {"name", "java.lang.String"}, | ||
24 | {"action", "java.lang.String"}, | ||
25 | {"type", "java.lang.String"}, | ||
26 | {"data", "java.lang.String"}, | ||
27 | {"URL", "java.lang.String"}, | ||
28 | {"file", "java.lang.String"}, | ||
29 | {"method", "java.lang.String"}, | ||
30 | {"lx", "java.lang.String"}, | ||
31 | {"ly", "java.lang.String"}, | ||
32 | {"lw", "java.lang.String"}, | ||
33 | {"lh", "java.lang.String"}, | ||
34 | {"normal", "java.lang.String"}, | ||
35 | {"ghost", "java.lang.String"}, | ||
36 | {"active", "java.lang.String"}, | ||
37 | {"toggle", "java.lang.String"}, | ||
38 | {"boolean","java.lang.Boolean"}, | ||
39 | {"number", "java.lang.Integer"}, | ||
40 | {"int", "java.lang.Integer"}, | ||
41 | {"x", "java.lang.Integer"}, | ||
42 | {"y", "java.lang.Integer"}, | ||
43 | {"w", "java.lang.Integer"}, | ||
44 | {"h", "java.lang.Integer"}, | ||
45 | {"r", "java.lang.Integer"}, | ||
46 | {"g", "java.lang.Integer"}, | ||
47 | {"b", "java.lang.Integer"}, | ||
48 | {"alpha", "java.lang.Integer"}, | ||
49 | {"acl", "net.matrix_rad.security.ACL"}, | ||
50 | ]] | ||
51 | |||
52 | |||
1 | -- Trying to capture best practices here for creating modules, especially since module() is broken and deprecated. | 53 | -- Trying to capture best practices here for creating modules, especially since module() is broken and deprecated. |
2 | 54 | ||
3 | -- Wrapping the entire module in do .. end helps if people just join a bunch of modules together, which apparently is popular. | 55 | -- Wrapping the entire module in do .. end helps if people just join a bunch of modules together, which apparently is popular. |