aboutsummaryrefslogtreecommitdiffstatshomepage
diff options
context:
space:
mode:
authorDavid Walter Seikel2013-02-02 21:22:58 +1000
committerDavid Walter Seikel2013-02-02 21:22:58 +1000
commit7d48bd9a65bc5fe92ede80ea7fc49e7526d07c7a (patch)
tree10f5afed6d45ceb28bbd08d97151141c6b60eff9
parentAdded GuiLua stub. (diff)
downloadSledjHamr-7d48bd9a65bc5fe92ede80ea7fc49e7526d07c7a.zip
SledjHamr-7d48bd9a65bc5fe92ede80ea7fc49e7526d07c7a.tar.gz
SledjHamr-7d48bd9a65bc5fe92ede80ea7fc49e7526d07c7a.tar.bz2
SledjHamr-7d48bd9a65bc5fe92ede80ea7fc49e7526d07c7a.tar.xz
Rearrange ClientHamr README's into better bits.
-rw-r--r--ClientHamr/GuiLua/README60
-rw-r--r--ClientHamr/extantz/README160
-rw-r--r--ClientHamr/extantz/skin.txt37
-rw-r--r--ClientHamr/woMan/README148
4 files changed, 213 insertions, 192 deletions
diff --git a/ClientHamr/GuiLua/README b/ClientHamr/GuiLua/README
index 70f67b8..8c798c7 100644
--- a/ClientHamr/GuiLua/README
+++ b/ClientHamr/GuiLua/README
@@ -1,2 +1,58 @@
1GuiLua is basically a redo of my ancient Java based matrix-RAD system to 1GuiLua is basically a redo of my ancient Java based matrix-RAD system,
2Lua and EFL. 2but using Lua and EFL. The ultimate goal is for the various ClientHamr
3parts to be able to either host their own UI, or have it hosted in the
4in world 3D window. Matrix-RAD's ability to run either server or client
5side, with no change to the code, is great for this sort of thing. If I
6can manage the ability to "tear off" windows, in other words, pull them
7out of the 3D window to be real windows, then that's something people
8have been asking for from LL forever.
9
10
11old notes
12---------
13
14Might be good to allow Lua scripting. One way of dealing with viewer
15prefs perhaps? Certainly think about Lua for the UI, and a built in
16editor, etc. ala skang. All the fancy stuff like development and such
17should be kept in some sort of module, so as not to bloat the main
18proggy. See if it's possible to disable the Emerald/Phoenix/Firestorm
19LSL bridge when connecting to OpenSim. See if we can do it from Lua,
20with some sort of generic Lua system for munging things.
21
22
23skang vs edje vs LL shit
24------------------------
25
26EDJE
27Verbose, complex.
28Used to place and decorate widget parts.
29Can be used to place entire widgets through externals and swallows.
30Basic parts relative to each other.
31Signals and messages.
32Embryo scripts.
33Lua scripts (sandboxed).
34
35
36SKANG
37Tight, simple.
38Used to place widgets, and describe actions.
39Can include some really basic scripting.
40Widgets in a fixed position, but included stuff for relative placement in the TODO.
41Automated associations between widget name and variable (and method?) via introspection.
42Actions.
43Looks (could easily be extended to edje groups).
44Extensible.
45Can be used to pass values around.
46
47
48LL SHIT
49Verbose, even worse, XML, more crap than is needed.
50Menus.
51Windows with widgets relative to each other.
52 Basically nested rectangles.
53Manual association of widgets to methods.
54Can include tool tip string, enabled, visible, hover cursor, bounding rectangle?, mouse opaque?, tab groups, font (name, size, style, and alignment).
55 More stuff, typically hidden in the OO somewhere. sigh
56Generally uses fixed image and colour names, which skins overide.
57Skins can also overide the XML files.
58Translations provide override XML files that need only override the text bits.
diff --git a/ClientHamr/extantz/README b/ClientHamr/extantz/README
index b7b4de4..5fb1d5f 100644
--- a/ClientHamr/extantz/README
+++ b/ClientHamr/extantz/README
@@ -1,19 +1,7 @@
1Extantz is a front end to virtual world viewers, mostly of the SL 1Extantz is the main virtual world front end. Also, during this
2(Second Life) variety since that's my focus. Most SL style virtual 2experimental phase of development, this will be a test bed for all the
3world viewers can be invoked with options to start them logging on, and 3GUI stuff. Eventually lots of it will be split off to separate
4skipping the login screen. So this project aims to be that login 4programs.
5screen, doing all the things that can be done from the meta-impy login
6screen, plus more. Once the user hits the login button, extantz figures
7out what parameters to pass to what viewer, then starts it up and gets
8out of the way. Following the ClientHamr philosophy of breaking the
9viewer up into modules that do simpler tasks, and do them well. So that
10means that meta-impy will eventually loose it's login screen, to be
11replaced by extantz.
12
13Also, during this experimental phase of development, this will be a test
14bed for all the GUI stuff. This could end up being the front end for
15the entire system, but still having the various bits split off into
16separate programs.
17 5
18Extantz is a made up word. The challenge was to find a word beginning 6Extantz is a made up word. The challenge was to find a word beginning
19with E, is as traditional with EFL (Enlightenment Foundation Library) 7with E, is as traditional with EFL (Enlightenment Foundation Library)
@@ -31,140 +19,6 @@ So I hope to invoke thoughts of a volume that exists and stands out. In
31other words, virtual worlds. Meh, I'm not that artsy, it needed a name. 19other words, virtual worlds. Meh, I'm not that artsy, it needed a name.
32lol 20lol
33 21
34Extantz starts off looking like any other viewers login screen, showing 22Extantz will handle all the 3D rendering. The other parts can use nails
35the login page of the default, or last visited grid, a small menu at the 23to control the world that is rendered, and GuiLua to present their UI
36top with the usual functions, and the usual login buttons at the bottom. 24on top of the rendered world.
37Added to that will be a better grid manager, with proper user
38management, suitable for people with more than one account per grid.
39The user will have the ability to choose a virtual world viewer to be
40the default, and even to associate a particular viewer with a particular
41grid. This is useful, for instance, for grids that have their own
42custom viewers, but the user wants to use a more generic viewer for all
43the other grids. Or if the user wants to use one viewer for OpenSim
44grids, but another for LL (Linden Labs) grids. Coz perhaps their chosen
45viewer is not TPVP (Third Party Viewer Policy, an LL thing) compliant,
46and LL are just more anal than the rest of the universe.
47
48The grid manager will also include some sort of search capability, as is
49currently being discussed by various people in the OpenSim universe.
50There might even be several search systems in place, so supporting
51existing ones, and the ability to add more might be useful. Extantz
52should be the only thing registered to handle hop:// and other such URLs
53in whatever web browsers you are using. Though most viewers want to
54register themselves, so tends to be that which ever one you started up
55last, or first, gets that privilege. That's a whole can of worms, sane
56policy and code should help.
57
58It might be useful to have extantz be able to download viewers,
59including checking for updates and offering to download them. As well
60as updates to common things like viewer tag definition files.
61
62Extantz, unlike the LL viewer code base, will be designed for relogging.
63Once the viewer it starts quits (or crashes), extantz, which was still
64running, can pop again and let the user relog, or log to some other
65grid, or same grid as different a user, or even same grid as same user
66with a different viewer.
67
68Viewers can be made extantz aware, like meta-impy will be (since it's
69handing it's login screen functionality to extantz). A few more things
70make sense to be added in this case. For instance, you might want to
71have some or all of your LMs (LandMarks) be usable at the log in
72screen, so you can log directly to them. The user might want the choice
73when they HG (HyperGrid teleport) to actually start up a new viewer and
74just login to the other grid instead (if they already have an account
75there). While HGed to some new grid, the user might want to add that
76grid to the extantz grid manager at a simple click of a button, perhaps
77complete with an LM for their current position. The grid searching
78capabilities mentioned earlier might be needed while in world.
79Certainly the grid manager functions in meta-impy will be handled by
80extantz, even if in world.
81
82In order to display the login page of a grid, which is a web page, a web
83browser will be built into extantz. It could be used to display web
84pages within an extantz aware viewer. Though perhaps not for MOAP
85(Media On A Prim), unless extantz grows the ability to incorporate
86itself into the viewers 3D landscape as part of a prim. Which is a good
87idea, then meta-impy no longer needs a web browser. Though other things
88in the viewer are implemented as web pages, and LL are moving more stuff
89to the web.
90
91One of the things on the login screen is the menu option to start up the
92preferences window and change the viewers preferences. Viewers use XML
93files that not only store the preferences, but also a description of
94them. The preferences window and it's various parts are also stored as
95XML files. There is a bit missing that is in the viewer source code
96that ties all of this together. So it might not be possible to do this
97for all viewers. Extantz aware viewers can naturally provide the
98missing bits to Extantz, even if not running, or even pass that entire
99functionality to extantz, just like meta-impy will do.
100
101For the purposes of keeping resource usage low, it should be possible
102for the user to configure extantz to go away when it starts a viewer.
103Might be a good idea even for extantz aware viewers, that can start it
104up again if it's functionality is needed while in world. Note this "go
105away" means to stop running and free up any resources it was using;
106which is different from the "gets out of the way" it usually does, still
107running, just not on screen.
108
109
110The problem with the web.
111-------------------------
112
113At least that's the theory. In practice, a web browser takes up almost
114one third of the viewer, and is only used for three things. Login
115pages, simple built in browser window, and MOAP (Media On A Prim). For
116the first two full blown web browsers are massive overkill. MOAP is not
117supported by meta-impy yet anyway.
118
119WebKit is a pain to compile at the moment, for reasons I wont go into
120right now. At the opposite of the spectrum is dillo, which is not quite
121up to spec enough for login pages that have fancy stuff. There does not
122appear to be any middle ground. So right now, I'll work on using random
123web browsers as external windows. That will suffice for everything but
124MOAP, which I can leave until later. Just discovered netsurf, a little
125smaller than dillo, but perhaps better featured? Might be useful.
126
127The web is a bloated mess, so it's not surprising that a fully featured
128web browser component like WebKit is also a bloated mess.
129
130
131Design.
132-------
133
134A thin window on the left.
135
136Menus across the top.
137View tabs.
138 Grids Accounts Viewers Landmarks
139
140Grids tab is the grid manager, though you can also drill down / tree out
141the accounts list per grid.
142
143Accounts shows accounts, though can drill down to grid list per account.
144Also consider launching thin viewers, text only ones and such. The
145account view is almost a natural for extending into a IM style thingy.
146
147Viewers lists the installed viewers, can install more, and allows
148preferences editing. It can handle viewer installs, upgrades, even
149compiling them from source.
150
151Landmarks manages LMs from viewers, or log in spots, or SLURLs etc.
152
153A user configurable web browser can open up to fill the right of the
154screen.
155
156Might be good to allow Lua scripting. One way of dealing with viewer
157prefs perhaps? Certainly think about Lua for the UI, and a built in
158editor, etc. ala skang. All the fancy stuff like development and such
159should be kept in some sort of module, so as not to bloat the main
160proggy. See if it's possible to disable the Emerald/Phoenix/Firestorm
161LSL bridge when connecting to OpenSim. See if we can do it from Lua,
162with some sort of generic Lua system for munging things.
163
164Log file management features, including viewer stdout, check if only
165Linux viewers do that. Including chat logs.
166
167Dillo and uzbl can insert themselves into the windows of others. Should
168check that out. Netsurf is allegedly easy to port to things, might be
169able to port it to EFL.
170
diff --git a/ClientHamr/extantz/skin.txt b/ClientHamr/extantz/skin.txt
deleted file mode 100644
index d627bb4..0000000
--- a/ClientHamr/extantz/skin.txt
+++ /dev/null
@@ -1,37 +0,0 @@
1skang vs edje vs LL shit.
2
3
4EDJE
5Verbose, complex.
6Used to place and decorate widget parts.
7Can be used to place entire widgets through externals and swallows.
8Basic parts relative to each other.
9Signals and messages.
10Embryo scripts.
11Lua scripts.
12
13
14SKANG
15Tight, simple.
16Used to place widgets, and describe actions.
17Can include some really basic scripting.
18Widgets in a fixed position, but included stuff for relative placement in the TODO.
19Automated associations between widget name and variable (and method?) via introspection.
20Actions.
21Looks (could easily be extended to edje groups).
22Extensible.
23Can be used to pass values around.
24
25
26LL SHIT
27Verbose, even worse, XML, more crap than is needed.
28Menus.
29Windows with widgets relative to each other.
30 Basically nested rectangles.
31Manual association of widgets to methods.
32Can include tool tip string, enabled, visible, hover cursor, bounding rectangle?, mouse opaque?, tab groups, font (name, size, style, and alignment).
33 More stuff, typically hidden in the OO somewhere. sigh
34Generally uses fixed image and colour names, which skins overide.
35Skins can also overide the XML files.
36Translations provide override XML files that need only override the text bits.
37
diff --git a/ClientHamr/woMan/README b/ClientHamr/woMan/README
new file mode 100644
index 0000000..1b3bbe0
--- /dev/null
+++ b/ClientHamr/woMan/README
@@ -0,0 +1,148 @@
1WoMan is a virtual world account and viewer manager, mostly of the SL
2(Second Life) variety since that's my focus. Most SL style virtual
3world viewers can be invoked with options to start them logging on, and
4skipping the login screen. So this project aims to be that login
5screen, doing all the things that can be done from the meta-impy login
6screen, plus more. Once the user hits the login button, woMan figures
7out what parameters to pass to what viewer, then starts it up and gets
8out of the way. Following the ClientHamr philosophy of breaking the
9viewer up into modules that do simpler tasks, and do them well. So that
10means that meta-impy will eventually loose it's login screen, to be
11replaced by woMan.
12
13WoMan starts off looking like any other viewers login screen, showing
14the login page of the default, or last visited grid, a small menu at the
15top with the usual functions, and the usual login buttons at the bottom.
16Added to that will be a better grid manager, with proper user
17management, suitable for people with more than one account per grid.
18The user will have the ability to choose a virtual world viewer to be
19the default, and even to associate a particular viewer with a particular
20grid. This is useful, for instance, for grids that have their own
21custom viewers, but the user wants to use a more generic viewer for all
22the other grids. Or if the user wants to use one viewer for OpenSim
23grids, but another for LL (Linden Labs) grids. Coz perhaps their chosen
24viewer is not TPVP (Third Party Viewer Policy, an LL thing) compliant,
25and LL are just more anal than the rest of the universe.
26
27NOTE: since I started this, LL in their *cough* infinite wisdom *cough*,
28decided that support of OpenSIm was a Really Bad Thing, so their viewers
29are no longer capable of dealing with other grids. LL have even gone as
30far as try to get other viewers to not support other grids. As far as
31woMan is concerned, this just means that LL viewers, and viewers that
32drank the LL koolaid, are less functional. shrugs
33
34The grid manager will also include some sort of search capability, as is
35currently being discussed by various people in the OpenSim universe.
36There might even be several search systems in place, so supporting
37existing ones, and the ability to add more might be useful. WoMan
38should be the only thing registered to handle hop:// and other such URLs
39in whatever web browsers you are using. Though most viewers want to
40register themselves, so tends to be that which ever one you started up
41last, or first, gets that privilege. That's a whole can of worms, sane
42policy and code should help.
43
44It might be useful to have woMan be able to download viewers,
45including checking for updates and offering to download them. As well
46as updates to common things like viewer tag definition files.
47
48WoMan, unlike the LL viewer code base, will be designed for relogging.
49Once the viewer it starts quits (or crashes), WoMan, which was still
50running, can pop again and let the user relog, or log to some other
51grid, or same grid as different a user, or even same grid as same user
52with a different viewer.
53
54Viewers can be made woMan aware, like meta-impy will be (since it's
55handing it's login screen functionality to woMan). A few more things
56make sense to be added in this case. For instance, you might want to
57have some or all of your LMs (LandMarks) be usable at the log in
58screen, so you can log directly to them. The user might want the choice
59when they HG (HyperGrid teleport) to actually start up a new viewer and
60just login to the other grid instead (if they already have an account
61there). While HGed to some new grid, the user might want to add that
62grid to the woMan grid manager at a simple click of a button, perhaps
63complete with an LM for their current position. The grid searching
64capabilities mentioned earlier might be needed while in world.
65Certainly the grid manager functions in meta-impy will be handled by
66woMan, even if in world.
67
68In order to display the login page of a grid, which is a web page, a web
69browser will be built into woMan. It could be used to display web
70pages within an woMan aware viewer. Though perhaps not for MOAP
71(Media On A Prim), unless woMan grows the ability to incorporate
72itself into the viewers 3D landscape as part of a prim. Which is a good
73idea, then meta-impy no longer needs a web browser. Though other things
74in the viewer are implemented as web pages, and LL are moving more stuff
75to the web.
76
77One of the things on the login screen is the menu option to start up the
78preferences window and change the viewers preferences. Viewers use XML
79files that not only store the preferences, but also a description of
80them. The preferences window and it's various parts are also stored as
81XML files. There is a bit missing that is in the viewer source code
82that ties all of this together. So it might not be possible to do this
83for all viewers. WoMan aware viewers can naturally provide the
84missing bits to woMan, even if not running, or even pass that entire
85functionality to woMan, just like meta-impy will do.
86
87For the purposes of keeping resource usage low, it should be possible
88for the user to configure woMan to go away when it starts a viewer.
89Might be a good idea even for woMan aware viewers, that can start it
90up again if it's functionality is needed while in world. Note this "go
91away" means to stop running and free up any resources it was using;
92which is different from the "gets out of the way" it usually does, still
93running, just not on screen.
94
95
96The problem with the web.
97-------------------------
98
99At least that's the theory. In practice, a web browser takes up almost
100one third of the viewer, and is only used for three things. Login
101pages, simple built in browser window, and MOAP (Media On A Prim). For
102the first two full blown web browsers are massive overkill. MOAP is not
103supported by meta-impy yet anyway.
104
105WebKit is a pain to compile at the moment, for reasons I wont go into
106right now. At the opposite of the spectrum is dillo, which is not quite
107up to spec enough for login pages that have fancy stuff. There does not
108appear to be any middle ground. So right now, I'll work on using random
109web browsers as external windows. That will suffice for everything but
110MOAP, which I can leave until later. Just discovered netsurf, a little
111smaller than dillo, but perhaps better featured? Might be useful.
112
113The web is a bloated mess, so it's not surprising that a fully featured
114web browser component like WebKit is also a bloated mess.
115
116
117Design.
118-------
119
120A thin window on the left.
121
122Menus across the top.
123View tabs.
124 Grids Accounts Viewers Landmarks
125
126Grids tab is the grid manager, though you can also drill down / tree out
127the accounts list per grid.
128
129Accounts shows accounts, though can drill down to grid list per account.
130Also consider launching thin viewers, text only ones and such. The
131account view is almost a natural for extending into a IM style thingy.
132
133Viewers lists the installed viewers, can install more, and allows
134preferences editing. It can handle viewer installs, upgrades, even
135compiling them from source.
136
137Landmarks manages LMs from viewers, or log in spots, or SLURLs etc.
138
139A user configurable web browser can open up to fill the right of the
140screen.
141
142Log file management features, including viewer stdout, check if only
143Linux viewers do that. Including chat logs.
144
145Dillo and uzbl can insert themselves into the windows of others. Should
146check that out. Netsurf is allegedly easy to port to things, might be
147able to port it to EFL.
148