diff options
author | David Walter Seikel | 2014-03-18 09:02:43 +1000 |
---|---|---|
committer | David Walter Seikel | 2014-03-18 09:02:43 +1000 |
commit | 92e532e67c6a401b27752f107b3a1377d8f6ba11 (patch) | |
tree | 81df64f216e8e9c65b8720b96c0e4efbf37ffde9 | |
parent | Same typo -- lol (diff) | |
download | SledjHamr-92e532e67c6a401b27752f107b3a1377d8f6ba11.zip SledjHamr-92e532e67c6a401b27752f107b3a1377d8f6ba11.tar.gz SledjHamr-92e532e67c6a401b27752f107b3a1377d8f6ba11.tar.bz2 SledjHamr-92e532e67c6a401b27752f107b3a1377d8f6ba11.tar.xz |
Added notes on how to translate Java skang to Lua.
-rw-r--r-- | ClientHamr/GuiLua/README | 161 |
1 files changed, 161 insertions, 0 deletions
diff --git a/ClientHamr/GuiLua/README b/ClientHamr/GuiLua/README index d24812a..a456cee 100644 --- a/ClientHamr/GuiLua/README +++ b/ClientHamr/GuiLua/README | |||
@@ -125,6 +125,167 @@ Raster also wants to thread lots of edje, likely including having edje | |||
125 | Lua scripts as threads, much like I'm doing with LuaSL already. Plus | 125 | Lua scripts as threads, much like I'm doing with LuaSL already. Plus |
126 | LuaJIT SPEEEEED!!. B-) | 126 | LuaJIT SPEEEEED!!. B-) |
127 | 127 | ||
128 | Skang notes | ||
129 | ----------- | ||
130 | |||
131 | So, what will this variation of skang look like? For a start, the | ||
132 | syntax will have to be more Lua like, so that's a real basic change. | ||
133 | Can't use a space as an argument separator, Lua allows only ',' and | ||
134 | ';'. Strings can still use single or double quotes. | ||
135 | |||
136 | The magic "_123" system I used before to specify "position / size in | ||
137 | characters instead of pixels" just wont work in Lua. Using _ as a table | ||
138 | name with a meta table means that this syntax now becomes "_.123", which | ||
139 | is kinda acceptable. Note that _.123 is syntax sugar for _["123"], so | ||
140 | I'm not sure if using a number there works. An alternative is to just | ||
141 | use a string - | ||
142 | |||
143 | foo = widget.label(0, "1", 100, 0, 'Text goes here") | ||
144 | |||
145 | Uses as many characters, and ends up being a value instead of an index, | ||
146 | which is the right thing to do. While on this subject, anything less | ||
147 | than 1, but more than 0, can be used as a percentage, maybe combined | ||
148 | with "character" mode (this is a new thing) - | ||
149 | |||
150 | foo = widget.label(0, "0.1", 0.5, 0, 'Text goes here") | ||
151 | |||
152 | "widget" would be a table with functions for dealing with widgets. It | ||
153 | would include metatable stuff for widget set introspection. So | ||
154 | "widget.label" would introspect in our widget set for a widget type of | ||
155 | "label", and return a widget type table. So we could do - | ||
156 | |||
157 | foo = widget.label(0, "0.1", 0.5, 0, 'Text goes here :") | ||
158 | foo:colour(255, 255, 255, 0, 0, 100, 255, 0) | ||
159 | foo:hide() | ||
160 | foo:action("skang.load(some/skang/file.skang)") | ||
161 | |||
162 | Also allow access via table elements - | ||
163 | |||
164 | foo.action = "skang.load('some/skang/file.skang')" | ||
165 | foo.colour.r = 123 | ||
166 | foo.look('some/edje/file/somewhere.edj') | ||
167 | foo.help = 'This is a widget for labelling some foo.' | ||
168 | |||
169 | We can use the concat operator (..) to append things to widgets, like | ||
170 | adding choices in a drop down, rows in a grid, etc. | ||
171 | |||
172 | Hmm, need a skang table as well - | ||
173 | |||
174 | skang.module(Evas) | ||
175 | skang.module(Elementary) | ||
176 | skang.clear() | ||
177 | skang.load('some/skang/file.skang') | ||
178 | |||
179 | |||
180 | I don't think we need variable introspection as much, since in this case | ||
181 | Lua is both the skang and the underlaying language, the variables can | ||
182 | just be accessed directly. Not sure on this, need to experiment. This | ||
183 | is what we normally need variable introspection for - | ||
184 | |||
185 | foo = 'bar' -- Using the metatable to override '=' to set the actual value of the widget, say the text of a label or edit widget. | ||
186 | bar = foo -- The reverse of the above. Though perhaps these can't be done? | ||
187 | foo = foo .. 'stuff' .. 'more stuff' .. 'another line of the dropdown or whatever' | ||
188 | |||
189 | OK, first two can't be done, metatable only overides that for table elements. The third one can only be - | ||
190 | |||
191 | foo.value = 'stuff' .. 'more stuff' | ||
192 | foo.value = foo.value .. 'another line of the dropdown or whatever' | ||
193 | |||
194 | Skang relied on the use of the set command to make sure that any | ||
195 | matching widgets and variables got updated. And the get command. | ||
196 | |||
197 | foo:set('stuff') | ||
198 | bar = foo:get() | ||
199 | |||
200 | On the other hand, given the module / package stuff mentioned below, and | ||
201 | some metatable magic, we could do - | ||
202 | |||
203 | local other = require('otherPackageName') | ||
204 | other.foo = 'stuff' | ||
205 | bar = other.foo | ||
206 | |||
207 | Sooo, how does that squeeze into a "skang" file? | ||
208 | |||
209 | #!skang myApp.skang -- This is Lua, so this might not work. | ||
210 | -- There's an implied local this = require('myApp') | ||
211 | -- There's an implied local skang = require('skang') | ||
212 | local widget = require('EvasWidgets') | ||
213 | local other = require('otherPackageName') | ||
214 | skang.clear | ||
215 | skang.window(200, 200, "G'day planet.") | ||
216 | quitter = widget.button('Quit', 0.5, 0.5, 0.5, 0.5) | ||
217 | quitter:action('quit') -- 'quit' is looked up in ThingSpcae.commands, and translated into the Lua 'skang.quit()'. | ||
218 | other.foo = 'stuff' | ||
219 | this.bar = other.foo | ||
220 | |||
221 | |||
222 | Original Skang infrastructure | ||
223 | ----------------------------- | ||
224 | |||
225 | Skang starts with a Thing as the base. In Java it's a base object for | ||
226 | everything else, with a bunch of methods and elements. We can probably | ||
227 | use a Thing metatable and replicate most of it. The widget used in the | ||
228 | previous section is built on top of Thing. Things are stored in | ||
229 | ThingSpace, which is a BonsaiTree of LeafLike Things. Java's version of | ||
230 | multiple inheritance was used. Commands are a Thing. | ||
231 | |||
232 | ThingSpace is per users session. classCache stores ... , command stores | ||
233 | commands, module stores loaded modules, param stores variables and their | ||
234 | values, widget stores widgets and their value / state. | ||
235 | |||
236 | Skanglet is a generated mapping between actual methods / variables in a | ||
237 | class, and skang. Each method or variable that ends up in the skanglet | ||
238 | was marked by special javadoc tags. It also included some meta data | ||
239 | like version and the default skang. For variables it defined - | ||
240 | |||
241 | "Name", "Field/Method()", "Required", "Shortcut", "Default", "Help text" | ||
242 | |||
243 | ... and for methods - | ||
244 | |||
245 | "Name", "Method", "Syntax", "Help text" | ||
246 | |||
247 | In both cases the "Name" was the skang name, it could be different from | ||
248 | the Java name specified in the second field. Likely we can do away with | ||
249 | the need to generate these skanglet files, and just add stuff to the | ||
250 | Thing. Modules wrap Skanglets, and takes care of loading them into ThingSpace. | ||
251 | |||
252 | Module are used for - | ||
253 | loading the Skanglet for the Thing currently running (match java class name to skang file name). | ||
254 | loading the AWT interface in skang files. | ||
255 | loading OTHER skanglet based Things | ||
256 | loading Squeal, StuffSkang, and Who from java when needed. | ||
257 | |||
258 | So in Lua, we can use the package system. First require(moduleName) to | ||
259 | load up the skang module. Require can return a table, the Lua package | ||
260 | called ends with "return someTable". See LuaLSL for an example. This | ||
261 | package is actually run, so it can figure out what to put in the | ||
262 | returned table. So for instance it could use inlined methods and such - | ||
263 | |||
264 | local skang = require skang | ||
265 | local result = {}; | ||
266 | result.author = 'onefang' | ||
267 | result.version = '0.72 alpha 2004-11-19 16:28:00' | ||
268 | local foo | ||
269 | -- The first argument would be the name of a local variable / method. Which could be accessed via _G? | ||
270 | -- Not sure if we could use a global foo, AND use it directly. | ||
271 | result.foo = skang.newParam(foo, "Required", "Shortcut", "Default", "Help text") | ||
272 | result.func = skang.newCommand('arg1_type,arg2_type', 'Help Text', function (arg1, arg2) | ||
273 | ... | ||
274 | end) | ||
275 | return result; | ||
276 | |||
277 | |||
278 | Stuff is the base class used to track database rows and other multi | ||
279 | value things. Would still need to deal with variable sub things, though | ||
280 | that's likely just using tables. SquealStuff is the database version, | ||
281 | using Squeal as the database driver wrapper. Squeal could wrap | ||
282 | esskyuehl? | ||
283 | |||
284 | |||
285 | The pre tokenized structure thingy I had planned in the TODO just wont | ||
286 | work, as it uses symbols. On the other hand, we will be using Lua | ||
287 | tables anyway. B-) | ||
288 | |||
128 | 289 | ||
129 | EO notes | 290 | EO notes |
130 | -------- | 291 | -------- |