Age | Commit message (Collapse) | Author |
|
Sometimes an LLWindowListener request turns up a bad-LLView-path error,
begging the question: under such circumstances, what ARE the valid paths?
Introduce a query to answer that question.
|
|
Initial implementation of "LLWindow" operations "mouseDown" etc. would always
produce a warning in the response to the effect that the target LLView wasn't
frontmost. These warnings were spurious; conversation with Richard makes it
seem unlikely that the warning can be made real. Suppressing.
|
|
|
|
|
|
|
|
This is a generally-useful idiom, extending the sendReply() convenience
function -- it shouldn't remain buried in a single .cpp file.
|
|
Use it for LLWindowListener to safely report an LLView* which might be NULL.
|
|
|
|
|
|
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.
|