| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Introduce a custom coroutine/fiber scheduler to prioritize UI.
With approval from Maxim and Atlas, merging to project trunk.
|
|
|
|
|
|
|
|
|
|
Add test_flycam.lua to exercise the smaller intervals.
|
|
Thanks, Maxim.
|
|
|
|
Fix omission in login.savedLogins().
|
|
Also add Region.lua.
|
|
|
|
Rename 'UI' 'getParents' op to 'getTopMenus', add UI.lua function.
|
|
|
|
Also update the 'UI' help text to reflect its more general nature.
Mention 0-relative rank in the xxToolbarBtn operation help text.
|
|
|
|
Lua UI visibility api
|
|
|
|
The viewer's main thread's main fiber is responsible for coordinating just
about everything. With the default round_robin fiber scheduling algorithm,
launching too many additional fibers could starve the main fiber, resulting in
visible lag.
This custom scheduler tracks when it switches to and from the main fiber, and
at each context switch, how long it's been since the last time the main fiber
ran. If that exceeds a certain timeslice, it jumps the main fiber to the head
of the queue and resumes that instead of any other ready fiber.
|
|
|
|
|
|
Add 'LLPanelLogin' 'login', 'savedLogins' operations.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Lua api for adding new menu items to the Top menu
|
|
Add 'UI' 'getParents' op to list top-menu 'parent_menu' names.
|
|
|
|
Add UI.callables() and corresponding entry point.
|
|
|
|
|
|
|
|
We want to base lua-callables on lua-top-menu.
|
|
Leverage C++ overloads to allow use of generic function names disambiguated by
argument type.
This allows using templates for certain common operation sequences.
|
|
Lua api for Follow Camera control
|
|
This encapsulates the boilerplate associated with passing each distinct
parameter to its corresponding LLFollowCamMgr method.
|
|
|
|
|
|
see fe8c976 for more info
Co-authored-by: Andrey Lihatskiy <alihatskiy@productengine.com>
|
|
|
|
|
|
|
|
Allow `LLEventPump` listener access to its own `LLBoundListener`.
|
|
We used to allow "tweaking" the name. Don't.
|
|
`LLEventAPI` is specifically intended to allow a LEAP plugin, or a Lua script,
to access certain viewer functionality. Errors in external code like that
cannot be addressed during viewer development. Any code path that allows
external code in any form to crash the viewer opens up a potential abuse
vector, if a trusting user runs external code from an untrustworthy source.
`LLDispatchListener` reports exceptions back to its invoker, if the invoker
provides a "reply" `LLEventPump` name. Absent "reply", though,
`LLDispatchListener` is documented to let any such exception propagate. That
behavior may be okay for internal use, but in the case of the `LLEventAPI`
subclass, it veers into the abuse scenario described above.
Make `LLEventAPI` ensure that any exception propagating from `LLDispatchListener`
is caught and logged, but not propagated.
Also enrich error reporting for the "batch" `LLDispatchListener` operations.
|
|
Remove documented `LLEventPump` support for `LLEventTrackable`. That claimed
support was always a little bit magical/fragile. IF:
* a class included `LLEventTrackable` as a base class AND
* an instance of that class was managed by `boost::shared_ptr` AND
* you passed one of that class's methods and the `boost::shared_ptr`
specifically to `boost::bind()` AND
* the resulting `boost::bind()` object was passed into `LLEventPump::listen()`
THEN the promise was that on destruction of that object, that listener would
automatically be disconnected -- instead of leaving a dangling pointer bound
into the `LLEventPump`, causing a crash on the next `LLEventPump::post()` call.
The only existing code in the viewer code base that exercised `LLEventTrackable`
functionality was in test programs. When the viewer calls `LLEventPump::listen()`,
it typically stores the resulting connection object in an `LLTempBoundListener`
variable, which guarantees disconnection on destruction of that variable.
The fact that `LLEventTrackable` support is specific to `boost::bind()`, that it
silently fails to keep its promise with `std::bind()` or a lambda or any other
form of C++ callable, makes it untrustworthy for new code.
Note that the code base still uses `boost::signals2::trackable` for other
`boost::signals2::signal` instances not associated with `LLEventPump`. We are
not changing those at this time.
|
