aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/ClientHamr
diff options
context:
space:
mode:
Diffstat (limited to 'ClientHamr')
-rw-r--r--ClientHamr/GuiLua/README222
1 files changed, 222 insertions, 0 deletions
diff --git a/ClientHamr/GuiLua/README b/ClientHamr/GuiLua/README
index e1f8578..03178e3 100644
--- a/ClientHamr/GuiLua/README
+++ b/ClientHamr/GuiLua/README
@@ -38,6 +38,228 @@ NAWS, just like matrix-RAD was originally planned. Then I can put off
38writing NAWS for another decade. lol 38writing NAWS for another decade. lol
39 39
40 40
41Design notes
42------------
43
44Edje Lua does not wrap elementary widgets, and is not likely to due to
45elementary being compiled after edje. Smart objects and swallows
46probably can deal with that though, I'm not familiar enough with them to
47know. Eo on the other hand allegedly offers introspection, which was
48always the corner stone of matrix-RAD. So access to elementary widgets
49via Eo might be possible. That's kinda the entire hook I'm hoping will
50help to make matrix-RAD style stuff work as well as it did there.
51
52Edje Lua is restricted to scripts in edje files, AND sandboxed to those
53edje files as well. We want to step outside that sandbox, and run stand
54alone Lua scripts, as well as GuiLua / LuaSL scripts internal to
55extantz. Some merging of LUaSL and Edje Lua, leaving room for GuiLua,
56would be great, but I might have to convince Raster. Note that the
57socket idea wont work in sandboxed edje LUa scripts, unless the socket
58is in C code, that uses edje messages as the internal transport.
59
60Just so it's easier to find, I'll repeat a bit from the Enlightenment
61mailing list here, the result of discussions with raster and other
62interested parties -
63
64"First step is to write edje functions for generically bundling up one
65or more Lua tables into a message, sending that message, then unpacking
66it again. This will be able to be done from edje, from C, and from Lua
67directly. Perhaps adding that as one more edje messege type. This is
68for sending Lua tables between threads. A later addition will be to
69send them through the 'net, probably as eet.
70
71Host apps can register arbitrary functions with edje Lua, using a more
72generic version of the code I already wrote for letting edje register
73lua functions. These host functions are by default not thread safe.
74Edje puts a wrapper function around the host app, and registers that
75wrapper function with Lua. The wrapper function, when called from Lua,
76does this -
77
78ecore_thread_main_loop_begin();
79call the host app callback();
80ecore_thread_main_loop_end();
81
82The first alternative, which the host app must request, is for the
83wrapper function to use the table message functions to marshal the
84arguments, send it to the main thread, wait for the response (or do
85something else), then unmarshal the result before sending it back to
86Lua.
87
88The second alternative, which the host app must REALLY request, is for
89the host app to say "I'm REALLY going out of my way to be threadsafe,
90just call me direct". No edje wrapper function, BUT the host app still
91has to use edje to register this function.
92
93The first two might be done this way -
94
95host_cb = edje_lua2_functions_add(...);
96edje_lua2_function_marshal_set(host_cb, function);
97
98The last one could be -
99
100host_cb = edje_lua2_threadsafe_function_add(...);
101
102Note the difference between _functions_ and _function_. The first call
103registers an entire metatable full of functions, in the same way that
104edje does for it's functions. These are the default sort of
105functions. The second call references one of those previously
106registered functions, and makes it marshal arguments and results. The
107third one registers a single function, but it could be added to an
108existing metatable registered by the first function."
109
110and -
111
112"We are actually half way there. Anticipating that there would be way
113more edje and evas stuff to add to the edje Lua API in the future, I
114created generic wrapper functions to make that easier. Implementing
115this would mean exposing those static functions, and writing more of
116these generic wrapper stuff.
117
118Lua already provides a mechanism for this sort of thing, but we
119currently sandbox that out. We can provide a very limited version of
120the package module, that only lets the Lua script load modules that the
121host app explicitly provides. This keeps edje Lua in it's strictly
122sandboxed state."
123
124Raster also wants to thread lots of edje, likely including having edje
125Lua scripts as threads, much like I'm doing with LuaSL already. Plus
126LuaJIT SPEEEEED!!. B-)
127
128
129extantz
130 GuiLua front end for other programs it starts
131 3D rendering of multiple virtual worlds in tabs
132 including the same virtual world logged in more than once with different accounts
133 Nails interface to virtual world backend modules. Each module converts nails commands to / from it's own network protocol.
134 A SledjHamr grid, which definately should be running independantly,
135 so others can log on and stay on when extantz closes down
136 which may be a local or remote grid
137 might be part of some other grid (a sim)
138 A local only SledjHamr grid, with no other logins.
139 loaded from an on disk SledjHamr grid, or even across the 'net
140 which can be persisted as a SledjHamr grid on disk
141 An OS/SL module that connects up to OS/SL grids and translates between OS/SL networking protocols and nails / GuiLua.
142 sending OS/SL network crap to the grid in response to nails commands
143 getting OS/SL network crap from the grid
144 translating and sending nails commands to extantz so it can update it's 3D models
145 including nails encapsulated GuiLUa commands to deal the with OS/SL GUI stuff
146 An Open Croquet module.
147 importer / exporter
148 Which basically grabs an area / selected objects from the current tabs world,
149 then sends them as nails commands to -
150 a file
151 across the 'net
152 the inventory browser
153 the IAR & OAR file writer
154 or grabs one of those things listed before, and sends it as nails commands to the current tabs world
155
156LuaSL
157 socket for other programs to send scripts and other info through
158 LSL -> LuaSL compiler
159 LuaSL script runner - likely to be running thousands of scripts
160 LuaJIT to speed it up, EFL luaproc to run them as worker threads
161 LSL constants and functions implemented as a Lua library
162 The functions want to use nails to talk to the server backend.
163 Currently just sending Lua function() call strings instead.
164 The "server backend" could be OpenSim (with a shim), an actual SledjHamr server (direct nails), or extantz (direct nails).
165 The server backend is whatever is on the other end of the socket.
166 it should be able to deal with multiple socket users, but may have to fix it if it does not
167 LuaSL scripts might include LSL style GUI elements (very few, very limited)
168 convert them to and from nails encapsulated GuiLua
169 if what's on the other end of the socket is extantz, no worries
170 otherwise the other end is OpenSim, the OS end can translate GuiLua into OS/SL viewer network stuff
171 let the OS end deal with the issues. It's their fault. :-P
172 LuaSL (but not LSL) scripts could include GuiLua and other nails stuff directly.
173 Note, OpenSim being the server backend wont know what to do with GuiLua, and will only know about nails later.
174 This is just a temporary thingy anyway.
175 Might be able to convert it to use more generalised message parsing, PLUS teach Edje some of LuaSL's message parsing tricks. Find a happy medium.
176
177GuiLua
178 library of all the matrix-RAD type stuffs, so others can use it
179 should include the code so that proggies using it can be client, server, or both
180 including the GuiLua script runner
181 Should only be running dozens at most, and at human speeds (maybe).
182 In the end Lua is lean on resources by design, so we can afford to have lots of proggies using it all over.
183 matrix-RAD style -
184 server creates skang GUI, sends it to client
185 client deals with GUI stuff, sends values back to server
186 server stores values and does things
187 client can do things to
188
189nails command pump
190 library, including C and Lua bindings, so all can use it as client, or server, or both
191 dedicate one nails command to encapsulate GuiLua skang commands
192 "G", so GuiLua skang can look like "GuiLua.widget("name", "Button", 0, _0, 100, 4, 0, "label");"
193 could even have a nails command for Lua / LuaSL / LSL commands or scripts. This might help with the OpenSim nails shim, we can start with that, and expand it later. B-)
194 "L" and "l", though currently LuaSL is using SID.foo(), where SID is the UUID of the script. Easy enough to whack an L in front of that.
195 The LuaSL scripts are using _LSL as the table name, but that's just using _ as an "internal variable" marker. Also easy to change.
196 SledHamr grids / sims are stored on disk or sent across the 'net as nails commands.
197
198IAR & OAR file reader / writer
199 loads up the file, sending it as nails commands
200 converts and stores incoming nails commands as an IAR or OAR file
201
202Edje Lua
203 Lua embedded in edje files, and sandboxed to them.
204 add table marshalling into an edje message
205 add host proggy supplied Lua functions
206 So we can add nails.foo(), GuiLua.foo(), and even LSL.foo().
207 LuaSL adds these to their generated scripts -
208 local _bit = require("bit")
209 local _LSL = require("LSL")
210 But require() is part of the package library that Edje Lua disables.
211 Tweak Edje Lua so that we can use it for external GuiLua and LuaSL scripts.
212 Edje Lua can add the bit library if it detects LuaJIT or 5.2.
213 This new host function thingy can be used to add GuiLua and nails ourselves. All users of it probably want to be sandboxed, the scripts should be loaded up by extantz, OpenSim, or SledjHamr, not run from the operating system.
214 LuaSL stuff needs to be sandboxed as well, maybe we can use this new host function thingy to add LSL to?
215 Really should investigate if this shit being duplicated in thousands of LuaSL scripts soaks up lots of memory? And require("LSL") versus this new host function thingy.
216 On the other hand, a lot oy this LSL library would end up being wrappers around nails in the future, which is a shared library.
217 LuaJIT? Optional?
218 Need to sort out it's memory allocator, coz apparently the one Edje uses is not thread safe, but the LuaJIT one does not limit memory per script like Edje does.
219 Maybe Edje can use an Eina allocator?
220 LuaSL uses luaL_newstate() for now, which uses the default Lua allocator (which might be the LuaJIT one if that's in use).
221 Edje uses lua_newstate(_elua_alloc, &ela) instead.
222 merge the actual script threading code from LuaSL into Edje Lua?
223 once this code is in Edje Lua, both LuaSL and GuiLua can use that
224
225in world object editor
226 Good to be separate, coz often you spend a lot of time NOT editing.
227 GuiLua based, so it can even be replaced / hacked up / tweaked.
228 Probably not much point dealing with GUI itself, as you want a 3D rendering of what you are editing, thus need extantz as the front end.
229 sending nails to extantz to render the results
230 extantz sends nails to the virtual world backend modules, which deal with translating and sending them on
231 also gotta deal with OS/SL backends that prefer to send the entire thing round robin and only update the screen once it's hit the server
232
233woMan
234 account manager
235 GuiLua for dealing with the account info
236 either sending the GuiLua to extantz, or dealing with it itself
237 settings manager
238 reading legacy viewer XML GUI files for preferences
239 reading legacy viewer XML settings files
240 translating that to GuiLua
241 either sending the GuiLua to extantz, or dealing with it itself
242 writing changed settings to legacy viewer XML settings files
243
244inventory browser
245 Good to be separate, coz often you spend a lot of time NOT dealing with inventory.
246 On the other hand, people might have their inventory window open all the time, I do. lol
247 handles local inventory as the usual nails files
248
249IM client
250 Separate coz it could also be used as a normal IM client.
251 either sending the GuiLua to extantz, or dealing with it itself
252 calls libpurple for the hard work
253 needs stuff for extantz / woMan to feed it IM / group / local chat stuffs from grids
254 gotta be modular, perhaps same module that handles other grid stuff for extantz?
255 or a libpurple module for OS/SL, and have authentication credentials for those grids passed from elsewhere (woMan?)
256
257web browser
258 We may have to deal with external web proggies, which may in the end be the best way.
259 Except for MOAP. lol
260 Maybe later we can have a HTML to GuiLua translater module? Muahahaha
261
262
41skang vs edje vs LL shit 263skang vs edje vs LL shit
42------------------------ 264------------------------
43 265