| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
