Code review with Alain turned up the fact that TemporaryDrilldownFunc, simple
to the point of naivety, doesn't address the case of its being copied. Making
it boost::noncopyable should turn any such usage into a compile error.
This is a significant refactoring of planned (but as yet unimplemented) work,
though in fact it's almost completely compatible with the only implemented
operation. The set() operation now requires op="set", where before that was
inferred because set() was the only possibility.
Whereas before LLViewerControlListener dispatched to different bound methods
on the "group" key, with four known "group" string values, it now dispatches
on the "op" key, supporting "set", "toggle", "get", "groups", "vars" -- the
last two exposing query functionality. LLControlGroup is actually derived from
LLInstanceTracker, keyed on string names, so we can look up instances using
LLControlGroup::getInstance(const std::string&), or enumerate all such names.
LLControlGroup similarly permits iterating over all defined LLControlVariables.
The static LLViewerControlListener instance has been wrapped in an unnamed
namespace and removed from llviewercontrollistener.h. The availability of the
API depends on LLEventPumps::obtain(), rather than normal C++ visibility.
These LLControlGroup methods were marked 'protected'. But they're important
for introspection: LLControlVariable::type() returns an eControlType;
understanding that value outside a C++ context requires typeEnumToString().
It's not worth bothering to tweak reply LLSD or attempt to send it if the
incoming request has no replyKey, in effect not requesting a reply. This
supports LLEventAPI operations for which the caller might or might not care
about a reply, invoked using either send() (fire and forget) or request()
(send request, wait for response). This logic should be central, instead of
having to perform that test in every caller that cares.
The major alternative would have been to treat missing replyKey as an error
(whether LL_ERRS or exception). But since there's already a mechanism by which
an LLEventAPI operation method can stipulate its replyKey as required, at this
level we can let it be optional.
Send mouseDown(), mouseUp(), mouseMove() through static mouseEvent() helper
function. Process new optional ["path"] param, validating corresponding LLView
and capturing certain information about it for caller. Synthesize (x, y) pos
if need be. Use LLView::TemporaryDrilldownFunc and llview::TargetEvent to
temporarily hijack normal LLView mouse-event propagation.
Define Response helper class to capture LLSD blob about the current request
and ensure it gets sent on return.
Instantiate LLWindowListener on LLViewerWindow instead of on LLWindow.
This permits LLWindowListener to use machinery from llui, e.g.
LLUI::resolvePath().
Document planned new ["path"], ["reply"] params to "keyDown", "keyUp",
"mouseDown", "mouseUp", "mouseMove" operations; document relationship between
["path"] and ["x"] and ["y"].
NEW PARAMS NOT YET IMPLEMENTED.
Instead of unconditionally calling LLView::pointInView(),
LLView::visibleAndContains() now consults a class-static boost::function
called sDrilldown -- which is initialized to LLView::pointInView().
Introduce LLView::TemporaryDrilldownFunc, instantiated with a callable whose
signature is compatible with LLView::pointInView(). This replaces sDrilldown,
but only for the life of the TemporaryDrilldownFunc object.
Introduce llview::TargetEvent, an object intended to serve as a
TemporaryDrilldownFunc callable. Construct it with a desired target LLView*
and pass it to TemporaryDrilldownFunc. When called with each candidate child
LLView*, instead of selecting the one containing the particular (x, y) point,
it selects the one that will lead to the ultimate desired target LLView*.
Add optional 'recur' param to LLView::childFromPoint(); default is current
one-level behavior. But when you pass recur=true, it should return the
frontmost visible leaf LLView containing the passed (x, y) point.
There are 5 remaining childrenHandleSomething() methods with nontrivial bodies
-- the rest all forward to one of those 5. Move them all to be physically
adjacent in the source file to make it easy to compare/maintain.
There were 13 different methods that were more or less clones of each other.
Consolidate those down to 5 variations on the basic method body, where each
variation has good (commented!) reason to differ.
Use helper methods to further simplify the remaining distinct method bodies.
Use BOOST_FOREACH() to improve readability of iterating over mChildList.
A couple of the lookup tables in llwindowlistener.cpp essentially duplicated
LLKeyboard::keyFromString() and maskFromString(). Remove those tables and use
LLKeyboard lookup methods instead.
Nat Goodspeed