A shocking number of LLSingleton subclasses had public constructors -- and in
several instances, were being explicitly instantiated independently of the
LLSingleton machinery. This breaks the new LLSingleton dependency-tracking
machinery. It seems only fair that if you say you want an LLSingleton, there
should only be ONE INSTANCE!
Introduce LLSINGLETON() and LLSINGLETON_EMPTY_CTOR() macros. These handle the
friend class LLSingleton<whatevah>;
and explicitly declare a private nullary constructor.
To try to enforce the LLSINGLETON() convention, introduce a new pure virtual
LLSingleton method you_must_use_LLSINGLETON_macro() which is, as you might
suspect, defined by the macro. If you declare an LLSingleton subclass without
using LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() in the class body, you can't
instantiate the subclass for lack of a you_must_use_LLSINGLETON_macro()
implementation -- which will hopefully remind the coder.
Trawl through ALL LLSingleton subclass definitions, sprinkling in
LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() as appropriate. Remove all explicit
constructor declarations, public or private, along with relevant 'friend class
LLSingleton<myself>' declarations. Where destructors are declared, move them
into private section as well. Where the constructor was inline but nontrivial,
move out of class body.
Fix several LLSingleton abuses revealed by making ctors/dtors private:
LLGlobalEconomy was both an LLSingleton and the base class for
LLRegionEconomy, a non-LLSingleton. (Therefore every LLRegionEconomy instance
contained another instance of the LLGlobalEconomy "singleton.") Extract
LLBaseEconomy; LLGlobalEconomy is now a trivial subclass of that.
LLRegionEconomy, as you might suspect, now derives from LLBaseEconomy.
LLToolGrab, an LLSingleton, was also explicitly instantiated by
LLToolCompGun's constructor. Extract LLToolGrabBase, explicitly instantiated,
with trivial subclass LLToolGrab, the LLSingleton instance.
(WARNING: LLToolGrabBase methods have an unnerving tendency to go after
LLToolGrab::getInstance(). I DO NOT KNOW what should be the relationship
between the instance in LLToolCompGun and the LLToolGrab singleton instance.)
LLGridManager declared a variant constructor accepting (const std::string&),
with the comment:
// initialize with an explicity grid file for testing.
As there is no evidence of this being called from anywhere, delete it.
LLChicletBar's constructor accepted an optional (const LLSD&). As the LLSD
parameter wasn't used, and as there is no evidence of it being passed from
anywhere, delete the parameter.
LLViewerWindow::shutdownViews() was checking LLNavigationBar::
instanceExists(), then deleting its getInstance() pointer -- leaving a
dangling LLSingleton instance pointer, a land mine if any subsequent code
should attempt to reference it. Use deleteSingleton() instead.
~LLAppViewer() was calling LLViewerEventRecorder::instance() and then
explicitly calling ~LLViewerEventRecorder() on that instance -- leaving the
LLSingleton instance pointer pointing to an allocated-but-destroyed instance.
Use deleteSingleton() instead.
removed complicated and unnecessary fast timer gapless handoff logic (it should be gapless anyway)
improved MemTrackable API, better separation of shadow and footprint
added memory usage stats to floater_stats.xml
attempted fix for gcc compile errors
can't use typeid() on a class that doesn't have a method
defined in a translation unit
fix is to force classes deriving from LLMemTrackable to
use their own static member named sMemStat
ensure that layout stack has updated its layout before manually resizing one of its elements
(which was causing the manual resize to be stomped on by the newly triggered layout update)
made layout stack animation occur even when layout stack not visible (inventory will appear in proper open/closed state)
LLView::setShape() now only calls handleReshape() when dimensions change
removed extraneous calls to LLLayoutStack::updateClass() so that it should be called only
once per frame now, allowing it to limit animation updates to layout stacks to one per frame.
fixed rendering glitches arising from reshaping LLFolderView while in the middle of its draw() method
floaters given specified positions will stay in that location
floaters that stack will treat that as a specified position
moving any floater will switch to relative positioning mode
cleaned up some XUI where widgets were relying on a default height of 10 pixels
Observations and broken stuff so far:
- LLSideTray is gone.
- LLBottomTray is gone.
- LLFloaterSnapshot was changed and gave lots of merge conflicts. Flickr upload will be broken.
- LLNearbyChat is derived from LLPanel now. That broke quite some stuff rearding autohiding and docking of chatbar.
- Profile floaters are gone and all web based now.
- Russian translation gave huge mere conflicts with the new russian xml files from LL. Unmergeable. I took the LL files.
- XUI files in general will need some love and testing.
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.
changed ordering of template loading relative to constructor setting of params
moved a lot of constructor-set params to template files
reviewed by Leslie
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.
* Removed numerous places in the code that called findChild across the inventory panel unnecessarily.
* Conglomerated uses of inbox and outbox inventory panels to the sidepanel class so the pointers can be cached and functionality like selection handling can be done more efficiently.
* Optimized LLView::childHasKeyboardFocus() to work backwards up from the focus object rather than searching for children that may or may not turn out to have focus.
Reviewed by Richard.
* Removed numerous places in the code that called findChild across the inventory panel unnecessarily.
* Conglomerated uses of inbox and outbox inventory panels to the sidepanel class so the pointers can be cached and functionality like selection handling can be done more efficiently.
* Optimized LLView::childHasKeyboardFocus() to work backwards up from the focus object rather than searching for children that may or may not turn out to have focus.
Reviewed by Richard.
made menu keyboard access only work when menus are visible
dummy widgets are now added with a parent view that is invisible
popupview can now be default-built
implemented childGetVisibleTab/PanelWithHelp using breadth-first-search iterator
moved tentative state from llview to lluictrl
changes llcallbackmap to use boost::function
implemented childGetVisibleTab/PanelWithHelp using breadth-first-search iterator
moved tentative state from llview to lluictrl
changes llcallbackmap to use boost::function
andreykproductengine