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
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Extantz is a front end to virtual world viewers, mostly of the SL
(Second Life) variety since that's my focus. Most SL style virtual
world viewers can be invoked with options to start them logging on, and
skipping the login screen. So this project aims to be that login
screen, doing all the things that can be done from the meta-impy login
screen, plus more. Once the user hits the login button, extantz figures
out what parameters to pass to what viewer, then starts it up and gets
out of the way. Following the ClientHamr philosophy of breaking the
viewer up into modules that do simpler tasks, and do them well. So that
means that meta-impy will eventually loose it's login screen, to be
replaced by extantz.
Extantz is a made up word. The challenge was to find a word beginning
with E, is as traditional with EFL (Enlightenment Foundation Library)
projects, that has not been done to death, and thus has some reasonable
chance to turn up in google searches. It also helps if it somehow or
other reflects what the project actually is. lol
Extant means "still existing, surviving", or the more archaic meaning,
from it's original Latin roots "standing out, be visible, exist".
Extent means "an area or volume, the range over which a thing extends"
among other things.
So I hope to invoke thoughts of a volume that exists and stands out. In
other words, virtual worlds. Meh, I'm not that artsy, it needed a name.
lol
Extantz starts off looking like any other viewers login screen, showing
the login page of the default, or last visited grid, a small menu at the
top with the usual functions, and the usual login buttons at the bottom.
Added to that will be a better grid manager, with proper user
management, suitable for people with more than one account per grid.
The user will have the ability to choose a virtual world viewer to be
the default, and even to associate a particular viewer with a particular
grid. This is useful, for instance, for grids that have their own
custom viewers, but the user wants to use a more generic viewer for all
the other grids. Or if the user wants to use one viewer for OpenSim
grids, but another for LL (Linden Labs) grids. Coz perhaps their chosen
viewer is not TPVP (Third Party Viewer Policy, an LL thing) compliant,
and LL are just more anal than the rest of the universe.
The grid manager will also include some sort of search capability, as is
currently being discussed by various people in the OpenSim universe.
There might even be several search systems in place, so supporting
existing ones, and the ability to add more might be useful. Extantz
should be the only thing registered to handle hop:// and other such URLs
in whatever web browsers you are using. Though most viewers want to
register themselves, so tends to be that which ever one you started up
last, or first, gets that privilege. That's a whole can of worms, sane
policy and code should help.
It might be useful to have extantz be able to download viewers,
including checking for updates and offering to download them. As well
as updates to common things like viewer tag definition files.
Extantz, unlike the LL viewer code base, will be designed for relogging.
Once the viewer it starts quits (or crashes), extantz, which was still
running, can pop again and let the user relog, or log to some other
grid, or same grid as different a user, or even same grid as same user
with a different viewer.
Viewers can be made extantz aware, like meta-impy will be (since it's
handing it's login screen functionality to extantz). A few more things
make sense to be added in this case. For instance, you might want to
have some or all of your LMs (LandMarks) be usable at the log in
screen, so you can log directly to them. The user might want the choice
when they HG (HyperGrid teleport) to actually start up a new viewer and
just login to the other grid instead (if they already have an account
there). While HGed to some new grid, the user might want to add that
grid to the extantz grid manager at a simple click of a button, perhaps
complete with an LM for their current position. The grid searching
capabilities mentioned earlier might be needed while in world.
Certainly the grid manager functions in meta-impy will be handled by
extantz, even if in world.
In order to display the login page of a grid, which is a web page, a web
browser will be built into extantz. It could be used to display web
pages within an extantz aware viewer. Though perhaps not for MOAP
(Media On A Prim), unless extantz grows the ability to incorporate
itself into the viewers 3D landscape as part of a prim. Which is a good
idea, then meta-impy no longer needs a web browser. Though other things
in the viewer are implemented as web pages, and LL are moving more stuff
to the web.
One of the things on the login screen is the menu option to start up the
preferences window and change the viewers preferences. Viewers use XML
files that not only store the preferences, but also a description of
them. The preferences window and it's various parts are also stored as
XML files. There is a bit missing that is in the viewer source code
that ties all of this together. So it might not be possible to do this
for all viewers. Extantz aware viewers can naturally provide the
missing bits to Extantz, even if not running, or even pass that entire
functionality to extantz, just like meta-impy will do.
For the purposes of keeping resource usage low, it should be possible
for the user to configure extantz to go away when it starts a viewer.
Might be a good idea even for extantz aware viewers, that can start it
up again if it's functionality is needed while in world. Note this "go
away" means to stop running and free up any resources it was using;
which is different from the "gets out of the way" it usually does, still
running, just not on screen.
The problem with the web.
-------------------------
At least that's the theory. In practice, a web browser takes up almost
one third of the viewer, and is only used for three things. Login
pages, simple built in browser window, and MOAP (Media On A Prim). For
the first two full blown web browsers are massive overkill. MOAP is not
supported by meta-impy yet anyway.
WebKit is a pain to compile at the moment, for reasons I wont go into
right now. At the opposite of the spectrum is dillo, which is not quite
up to spec enough for login pages that have fancy stuff. There does not
appear to be any middle ground. So right now, I'll work on using random
web browsers as external windows. That will suffice for everything but
MOAP, which I can leave until later. Just discovered netsurf, a little
smaller than dillo, but perhaps better featured? Might be useful.
The web is a bloated mess, so it's not surprising that a fully featured
web browser component like WebKit is also a bloated mess.
Design.
-------
A thin window on the left.
Menus across the top.
View tabs.
Grids Accounts Viewers Landmarks
Grids tab is the grid manager, though you can also drill down / tree out
the accounts list per grid.
Accounts shows accounts, though can drill down to grid list per account.
Also consider launching thin viewers, text only ones and such. The
account view is almost a natural for extending into a IM style thingy.
Viewers lists the installed viewers, can install more, and allows
preferences editing. It can handle viewer installs, upgrades, even
compiling them from source.
Landmarks manages LMs from viewers, or log in spots, or SLURLs etc.
A user configurable web browser can open up to fill the right of the
screen.
Might be good to allow Lua scripting. One way of dealing with viewer
prefs perhaps? Certainly think about Lua for the UI, and a built in
editor, etc. ala skang. All the fancy stuff like development and such
should be kept in some sort of module, so as not to bloat the main
proggy. See if it's possible to disable the Emerald/Phoenix/Firestorm
LSL bridge when connecting to OpenSim. See if we can do it from Lua,
with some sort of generic Lua system for munging things.
Log file management features, including viewer stdout, check if only
Linux viewers do that. Including chat logs.
Dillo and uzbl can insert themselves into the windows of others. Should
check that out.
|
