| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
The recursive logic always used to recur to the point where there were no
children -- where the next level of recursion returned NULL -- and then return
that NULL. Fix so when that lowest-level call returns NULL, we return one
level above that.
|
|
|
|
|
|
|
|
|
|
|
|
Generalize the notion of getting some chunk of "static" storage: introduce
LLInstanceTrackerBase::getStatic() template method. Define StaticData struct
containing the InstanceMap (or InstanceSet, for that specialization) along
with the S32 that caused the VS2010 linker so much grief. Completely eliminate
that S32 as an actual class-static member, qualifying all references with the
struct returned by getStatic().
In LLInstanceTrackerBase::getInstances(), use one std::map lookup instead of
three.
|
|
|
|
Apparently the outer class's LL_COMMON_API marker affects all outer class
members, but not nested classes. Making it explicit fixes Windows link errors.
|
|
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.
|
|
|
|
implementation.
|
|
|
|
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.
|
|
This is a generally-useful idiom, extending the sendReply() convenience
function -- it shouldn't remain buried in a single .cpp file.
|
|
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().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use it for LLWindowListener to safely report an LLView* which might be NULL.
|
|
|
|
|
|
|
|
|
|
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.
|
|
truncated
|
|
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.
|
|
|
|
|
|
|
|
|
|
reviewed by Stone
|
|
|
|
prim in latest Mesh build 239475
brought back some old logic for dispatching to child folder as drag and drop fallback
|
|
|
|
Added comment where sidebar block list is opened.
|
|
Made changes per RB feedback.
|
|
confirmation dialog wasn't suppressed.
Reason: Showing the confirmation dialog resets object selection,
thus there is nothing to derez.
Fix: Save selection until user answers in the confirmation dialog.
I didn't investigate why the bug occurred only for distant object
(must be some internal LLSelectMgr magic).
|
|
|
|
|
|
Addressing review feedback.
|
|
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.
|
