aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/ClientHamr/GuiLua/README
blob: e1f8578258a69cc8b127bbfa47bb2f57d58bc7c9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
GuiLua is basically a redo of my ancient Java based matrix-RAD system,
but using Lua and EFL.  The ultimate goal is for the various ClientHamr
parts to be able to either host their own UI, or have it hosted in the
in world 3D window.  Matrix-RAD's ability to run either server or client
side, with no change to the code, is great for this sort of thing.  If I
can manage the ability to "tear off" windows, in other words, pull them
out of the 3D window to be real windows, then that's something people
have been asking for from LL forever.

Stdin/out might be good to use.  Extantz starts up "client" programs,
with a "use stdin/out" argument, the clients pass skang commands (open
this internal window with these widgets) to extantz through their
stdout, extantz passes skang commands (these values where set by these
widgets) back through their stdin.  With no "use stdin/out" argument,
the programs host their own UI.  Perhaps extantz can just pass the UI
skang stuff back to the client, which will mean "draw your own window",
to support the "tear off" feature.  If I remember skang had suitable
serialization stuff to support this.  Lua does anyway.  B-)

Naturally, like matrix-RAD, all this UI stuff can happen across a socket
as well as through stdin/out.  Should be transparent to the user proggy.

I can redesign skang to be more Lua like, to take advantage of Lua's
meta language capabilities.  Since no one used skang anyway, I can get
away with this.  Also should add a Lua friendly wrapper around nails, so
that addons for Extantz can be supplied entirely as Lua scripts.  In
other words, LuaSL scripts.  On top of all that, should also allow
access to the Edje Lua stuff I've already written, but drag it outside
of an edje file.

This pretty much means that GuiLua should be a shared library, coz in
the ClientHamr use case, several programs are gonna be using it at once. 
Should also be separate modules for development stuff like the skin
editor, which could be just another proggy using GuiLua.

Initially GuiLua can wrap elementary / evas, with the goal of wrapping
NAWS, just like matrix-RAD was originally planned.  Then I can put off
writing NAWS for another decade.  lol


skang vs edje vs LL shit
------------------------

EDJE
Verbose, complex.
Used to place and decorate widget parts.
Can be used to place entire widgets through externals and swallows.
Basic parts relative to each other.
Signals and messages.
Embryo scripts.
Lua scripts (sandboxed).


SKANG
Tight, simple.
Used to place widgets, and describe actions.
Can include some really basic scripting.
Widgets in a fixed position, but included stuff for relative placement in the TODO.
Automated associations between widget name and variable (and method?) via introspection.
Actions.
Looks (could easily be extended to edje groups).
Extensible.
Can be used to pass values around.


LL SHIT
Verbose, even worse, XML, more crap than is needed.
Menus.
Windows with widgets relative to each other.
    Basically nested rectangles.
Manual association of widgets to methods.
Can include tool tip string, enabled, visible, hover cursor, bounding rectangle?, mouse opaque?, tab groups, font (name, size, style, and alignment).
    More stuff, typically hidden in the OO somewhere.  sigh
Generally uses fixed image and colour names, which skins overide.
Skins can also overide the XML files.
Translations provide override XML files that need only override the text bits.


old notes
---------

See if it's possible to disable the Emerald/Phoenix/Firestorm LSL bridge
when connecting to OpenSim.  Actually, they finally came to their senses
and support OpenSim now, so that should be sorted already.