| Age | Commit message (Collapse) | Author |
|---|
|
On Windows, unlike on Mac or Linux, boost::ptr_map<> started insisting on this
concept of clonability. In other words, it wants to own a unique instance of
the pointee; if you copy a value_type -- even to dereference an iterator! --
it wants to construct a whole new instance of the mapped_type. That's nuts. A
std::map<..., boost::shared_ptr<>> has the property I want (the mapped_type
goes away when the entry is erased), plus it's willing to pass around the
shared_ptr to the same instance of the mapped_type. This change also permits
simplifying a couple awkward kludges I'd already had to make to accommodate
ptr_map's idiosyncracies.
|
|
A free function or static method accepting(const LLSD&) was being intercepted
by the free-function-with-arbitrary-parameters overload instead of the
original Callable overload. Added an overload that specifically redirects that
case.
Documented limit of ~6 arbitrary parameters for directly-called functions (5
for methods). Beyond that many, you have to write a Callable wrapper function
and unpack the parameters from the LLSD by hand.
|
|
Until now, LLEventAPI has only been able to register functions specifically
accepting(const LLSD&). Typically you add a wrapper method to your LLEventAPI
subclass, register that, have it extract desired params from the incoming LLSD
and then call the actual function of interest.
With help from Alain, added new LLEventAPI::add() methods capable of
registering functions/methods with arbitrary parameter signatures. The code
uses boost::fusion magic to implicitly match incoming LLSD arguments to the
function's formal parameter list, bypassing the need for an explicit helper
method.
New add() methods caused an ambiguity with a previous convenience overload.
Removed that overload and fixed the one existing usage.
Replaced LLEventDispatcher::get() with try_call() -- it's no longer easy to
return a Callable for caller to call directly. But the one known use of that
feature simply used it to avoid fatal LL_ERRS on unknown function-name string,
hence the try_call() approach actually addresses that case more directly.
Added indra/common/lleventdispatcher_test.cpp to exercise new functionality.
|
|
|
|
Add LLEventDispatcher::getDispatchKey() to retrieve a previously-
inaccessible value.
|
|
for all registered operations. (untested)
Introduce LLEventDispatcher::getMetadata(name) query so you can discover, for
a given named operation, its query string and required parameters. (untested)
Introduce LLEventDispatcher::add() convenience methods allowing you to omit
description strings. Fix LLLoginInstance (which uses a non-LLEventAPI
LLEventDispatcher) back to description-less add() calls.
However, filter LLEventDispatcher::add() methods inherited by LLEventAPI so
that an LLEventAPI subclass *must* provide a description string.
|
|
with an event API. In addition to the LLEventPump name on which to listen,
LLEventAPI accepts a documentation string for event API introspection.
Give every LLEventDispatcher::add() overload a new documentation string
parameter for event API introspection.
Convert every existing event API to new conventions, introducing suitable
documentation strings for the API and each of its operations.
|
|
--HG--
branch : avatar-pipeline
|
|
existing event calls to use state as "offline" or "online", with "change"
indicating the reason for this status event. Changed disconnect() to send
state "offline", change "disconnect" -- instead of replaying last auth
failure. Changed unit tests accordingly.
Changed LLLoginInstance::handleLoginEvent() to use LLEventDispatcher to route
calls to handleLoginFailure() et al.
Added LLEventDispatcher::get() to allow retrieving Callable by name and
testing for empty().
|
|
|
|
up to viewer-2.0.0-3
|
|
LLEventPump name
|
|
|
|
methods. Introduce LLAppViewerListener based on LLDispatchListener,
instantiate a static one in llappviewer.cpp. Initial implementation only
supports ["op"] == "requestQuit".
|
|
LLEventDispatcher and LLDispatchListener classes. See LLAresListener for
example usage.
|
