Instead of checking whether an add() parameter is exactly LLSD or LLSDMap,
check whether it's convertible to LLSD -- which handles those cases and more.
(cherry picked from commit fa168c11f64771dadc5df86d14ca2f07eba3b8ba)
Previously, LLEventAPI intentionally hid all but one of the many add()
overloads supported by its LLEventDispatcher base class. The reason was that
certain of the add() methods take an optional fourth parameter that's an
LLSD::Map describing the expected parameter structure, while others take a
fourth templated parameter that's an instance getter callable. This led to
ambiguity, especially when passed an LLSDMap instance that's convertible to
LLSD but isn't literally LLSD. At the time, it was simpler to constrain the
add() methods inherited from LLEventDispatcher.
But by adding new std::enable_if constraints to certain LLEventDispatcher
add() methods, we've resolved the ambiguities, so LLEventAPI subclasses can
now use any add() overload (as claimed on the relevant Confluence page).
LLEventDispatcher comments have always loftily claimed that an instance getter
callable may return either a pointer or a reference, doesn't matter. But it
does when trying to pass the getter's result to boost::fusion::push_back(): a
reference must be wrapped with std::ref() while a pointer cannot be.
std::ref(pointer) produces errors. Introduce LLEventDispatcher::invoker::
bindable() overloads to Do The Right Thing whether passed a pointer or a
reference.
(cherry picked from commit 743f487c2e123171c9fc6d5b84d768f1d856d569)
Originally the LLEventAPI mechanism was primarily used for VITA testing. In
that case it was okay for the viewer to crash with LL_ERRS if the test script
passed a bad request.
With puppetry, hopefully new LEAP scripts will be written to engage
LLEventAPIs in all sorts of interesting ways. Change error handling from
LL_ERRS to LL_WARNS. Furthermore, if the incoming request contains a "reply"
key, send back an error response to the requester.
Update lleventdispatcher_test.cpp accordingly.
(cherry picked from commit de0539fcbe815ceec2041ecc9981e3adf59f2806)
- Do not try initializing shaders if requirements are not met or if window does not exist
- Warn user before closing window. Situation is unexpected, there is chance of more issues, like a freeze or a crash on close()
- mHasMultitexture is a solid requirement, if it is not present, we won't be able to run