Skip to content
Snippets Groups Projects
  1. Sep 10, 2019
  2. Jul 10, 2017
  3. Jul 05, 2017
  4. Sep 15, 2016
    • Nat Goodspeed's avatar
      MAINT-5232: Normalize LLSingleton subclasses. · d2c3c2f9
      Nat Goodspeed authored
      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.
      d2c3c2f9
  5. Nov 10, 2015
  6. Jul 30, 2013
  7. Mar 29, 2013
  8. Mar 27, 2013
  9. Mar 14, 2013
  10. Mar 15, 2012
  11. Sep 15, 2011
  12. Oct 13, 2010
  13. Sep 21, 2010
  14. Aug 13, 2010
  15. Nov 25, 2009
  16. Oct 03, 2009
  17. Aug 24, 2009
    • Richard Nelson's avatar
      merge -r 130399-131510 skinning-21 -> viewer-2.0.0-3 · 138bf113
      Richard Nelson authored
      DEV-11254 DEV-11254 DEV-2003: DEV-21567 DEV-37301 EXT-104 EXT-138 EXT-217 EXT-256 EXT-259 EXT-259 EXT-328 EXT-348 EXT-386 EXT-399 EXT-403 EXT-460 EXT-492 EXT-492 EXT-531 EXT-537 EXT-684
      
      improved text editor (handles multiple fonts simultaneously as well as inline widgets)
      138bf113
  18. Aug 14, 2009
  19. Aug 13, 2009
  20. Jul 10, 2009
  21. Jul 06, 2009
    • James Cook's avatar
      Merge skinning-14 to viewer-2, including refactoring many floaters to register... · 52aeaa32
      James Cook authored
      Merge skinning-14 to viewer-2, including refactoring many floaters to register them with LLFloaterReg, support for introspection of ParamBlock based UI widgets to dump XML schema, splitting llfolderview.cpp into three separate files to unravel dependencies and skeleton for for LLListView widget.  Resolved conflicts in these files:
      lldraghandle.h, lluictrl.h, llchiclet.cpp, llfolderview.h/cpp, lliinventorybridge.cpp, llpanelpicks.cpp, llviewermenu.cpp, floater_mute.xml, floater_preferences.xml, notifications.xml, panel_preferences_audio.xml, panel_preferences_graphics1.xml, panel_region_general.xml
      svn merge -r124961:126284 svn+ssh://svn.lindenlab.com/svn/linden/branches/skinning/skinning-14
      52aeaa32
  22. Jun 21, 2009
  23. May 08, 2009
  24. Jan 07, 2009
  25. Jun 25, 2008
  26. Apr 03, 2008
    • Steven Bennetts's avatar
      1.19.1 Viewer merge: QAR_367, QAR-374, QAR-408, QAR-426 · b5936a4b
      Steven Bennetts authored
      QAR_367 (RC1) - merge Branch_1-19-1-Viewer -r 81609 : 81993 -> release
      QAR-374 (RC2) - merge Branch_1-19-1-Viewer -r 81993 : 82589 -> release
      QAR-408 (RC3) - merge Branch_1-19-1-Viewer -r 82589 : 83128 -> release
      QAR-426 (rc4) - merge Branch_1-19-1-Viewer -r 83125 : 83719 -> release
      (Actual merge: release@83793 Branch_1-19-1-Viewer-merge@83953 -> release)
      b5936a4b
  27. Apr 01, 2008
  28. Feb 19, 2008
  29. Oct 04, 2007
  30. Jun 21, 2007
  31. Jan 10, 2007
  32. Jan 02, 2007
Loading