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.
EXP-997 FIX -- Significant FPS degradation in 2.8.0 Beta on Mac equipped ATI video card
* Disabled VBO's on mac to avoid stalls in renderer
* Placed valid data into the padding between triangles in the vertex buffer to remove uninitialized craziness
* Removed invalid rendering checks causing GL errors in debug mode
Reviewed by davep
Nat Goodspeed