Age | Commit message (Collapse) | Author |
|
Convert plain grid (e.g. "agni") to domain form (e.g. "util.agni.lindenlab.com").
Fix a typo in `savedLogins()`: "login_list", not "login.list".
login.lua now returns a table with two functions: `login.login()` and
`login.savedLogins()`.
Defend Lua caller against trying to engage login features too late in startup
sequence: in addition to waiting for "STATE_LOGIN_WAIT", produce an error if
`startup.state()` is beyond that state. Since by then `LLPanelLogin` is
destroyed, `leap.request("LLPanelLogin", ...)` would get no response, causing
the calling Lua script to hang until viewer shutdown.
|
|
'login' accepts optional 'username', 'slurl', 'grid'.
'savedLogins' returns the list of saved usernames in both display form and
internal form.
Make LLPanelLogin::getUserName() accept (const LLPointer<LLCredential>&).
There's a whole separate discussion pending as to whether const LLPointer<T>
should provide access to non-const T methods.
Similarly, make LLCredential::getIdentifier() a const method. These two
changes enable read-only access to credentials.
Make LLPanelLogin methods capture and reuse LLGridManager::instance() as
appropriate.
Add require/login.lua and test_login.lua.
|
|
|
|
We want to base lua-callables on lua-top-menu.
|
|
This encapsulates the boilerplate associated with passing each distinct
parameter to its corresponding LLFollowCamMgr method.
|
|
|
|
|
|
|
|
|
|
We couldn't discard the "p.s." fiber.run() call from LuaState::expr() until we
could count on fiber.lua's LL.atexit(fiber.run) call being executed after each
Lua script or chunk, and we couldn't count on that until we made
LLLUAmanager::runScriptFile() instantiate and destroy its LuaState on the C++
Lua-specific coroutine. Now that we've done that, use LL.atexit(fiber.run)
instead of the whole special-case "p.s." in LuaState::expr().
|
|
|
|
|
|
|
|
|
|
outfit items
|
|
|
|
|
|
|
|
|
|
|
|
Add "userQuit" operation to LLAppViewerListener to engage
LLAppViewer::userQuit(), which pops up "Are you sure?" prompt unless
suppressed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use ClassName(ctor args) for classes using util.classctor().
|
|
|
|
|
|
|
|
popup:tip() engages 'SystemMessageTip'.
|
|
|
|
|
|
Instead, make fiber.lua call LL.atexit(fiber.run) to schedule that final run()
call at ~LuaState() time using the generic mechanism.
Append an explicit fiber.run() call to a specific test in llluamanager_test.cpp
because the test code wants to interact with multiple Lua fibers *before* we
destroy the LuaState.
|
|
Make viewer_manifest.py copy them into the viewer install image.
Make the require() function look for them there.
|
|
|
|
|
|
The expression (payload or {}) is unnecessary, since that value will be
converted to LLSD -- and both Lua nil and empty table convert to
LLSD::isUndefined().
|
|
WIP: This is known not to work yet.
|
|
The nullary login() call (login with saved credentials) has been tested, but
the binary login(username, password) call is known not to work yet.
|
|
Add listviews(), viewinfo(), click(), doubleclick(), drag(), keypress() and
type().
WIP: These are ported from Python LEAP equivalents, but the Lua implementation
has only been partially tested.
|
|
The 'startup' table, the module's namespace, must be defined near the top
because its local waitfor:process() override references startup.
The byname table's metatable's __index() function wants to raise an error if
you try to access an undefined entry, but it referenced t[k] to check that,
producing infinite recursion. Use rawget(t, k) instead.
Also use new leap.WaitFor(args) syntax instead of leap.WaitFor:new(args).
|
|
The discussions we've read about Lua classes conventionally use
ClassName:new() as the constructor, and so far we've followed that convention.
But setting metaclass(ClassName).__call = ClassName.new permits Lua to respond
to calls of the form ClassName(ctor args) by implicitly calling
ClassName:new(ctor args).
Introduce util.classctor(). Calling util.classctor(ClassName) sets ClassName's
metaclass's __call to ClassName's constructor method. If the constructor method
is named something other than new(), pass ClassName.method as the second arg.
Use util.classctor() on each of our classes that defines a new() method.
Replace ClassName:new(args) calls with ClassName(args) calls throughout.
|
|
in addition to a list {'name1', 'name2', ...}.
|
|
|
|
|
|
There are two conventions for Lua function calls. You can call a function with
positional arguments as usual:
f(1, 2, 3)
Lua makes it easy to handle omitted positional arguments: their values are nil.
But as in C++, positional arguments get harder to read when there are many, or
when you want to omit arguments other than the last ones.
Alternatively, using Lua syntactic sugar, you can pass a single argument which
is a table containing the desired function arguments. For this you can use
table constructor syntax to effect keyword arguments:
f{a=1, b=2, c=3}
A call passing keyword arguments is more readable because you explicitly
associate the parameter name with each argument value. Moreover, it gracefully
handles the case of multiple optional arguments. The reader need not be
concerned about parameters *not* being passed.
Now you're coding a Lua module with a number of functions. Some have numerous
or complicated arguments; some do not. For simplicity, you code the simple
functions to accept positional arguments, the more complicated functions to
accept the single-table argument style.
But how the bleep is a consumer of your module supposed to remember which
calling style to use for a given function?
mapargs() blurs the distinction, accepting either style. Coding a function
like this (where '...' is literal code, not documentation ellipsis):
function f(...)
local args = mapargs({'a', 'b', 'c'}, ...)
-- now use args.a, args.b, args.c
end
supports calls like:
f(1, 2, 3)
f{1, 2, 3}
f{c=3, a=1, b=2}
f{1, 2, c=3}
f{c=3, 1, 2} -- unlike Python!
In every call above, args.a == 1, args.b == 2, args.c == 3.
Moreover, omitting arguments (or explicitly passing nil, positionally or by
keyword) works correctly.
test_mapargs.lua exercises these cases.
|
|
so the user need not reverse-engineer the code to figure out the output.
|
|
|