Skip to content
Snippets Groups Projects
  1. Jul 04, 2021
  2. 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
  3. Nov 10, 2015
  4. Aug 09, 2013
  5. Apr 24, 2013
  6. Apr 15, 2013
  7. Mar 29, 2013
  8. Mar 14, 2013
  9. Feb 28, 2013
  10. Dec 15, 2012
  11. May 16, 2012
  12. Mar 06, 2012
  13. Feb 08, 2012
  14. Jan 31, 2012
  15. Jan 30, 2012
  16. Jan 19, 2012
  17. Jan 18, 2012
  18. Jan 16, 2012
  19. Dec 12, 2011
  20. Oct 18, 2011
  21. Sep 27, 2011
  22. Sep 20, 2011
  23. Jun 22, 2011
    • Leslie Linden's avatar
      EXP-890 FIX -- Resizing inbox or outbox to minimum size while open does not... · 4267014b
      Leslie Linden authored
      EXP-890 FIX -- Resizing inbox or outbox to minimum size while open does not show present items when hte box is next opened
      EXP-897 FIX -- Black box shown in UI when shrinking Inbox down in size
      
      * Layout panel now supports "expanded_min_dim" parameter which allows a different min
        size to be specified when the layout panel is collapsed vs expanded.
      * Inbox and Outbox expanded_min_dim attributes are now set to be larger than min dim
        so they can not be collapsed all the way when they are expanded.
      4267014b
  24. May 25, 2011
  25. Dec 10, 2010
    • Richard Linden's avatar
      WIP XUI HTTP Auth dialog · 8044661b
      Richard Linden authored
      refactored LLWindowShade into seperate file
      improved layout of dialog
      improved dialog resizing logic
      Tab and Enter keys now work as expected in windowshade form
      added "modal" capability to window shade
      added HTTP Auth notifications to MOAP
      8044661b
  26. Nov 23, 2010
  27. Oct 21, 2010
  28. Oct 13, 2010
  29. Sep 21, 2010
  30. Sep 06, 2010
    • Andrew Dyukov's avatar
      VWR-22690 FIXED Implemented save/load of bottomtray button order. · a30bc718
      Andrew Dyukov authored
      - Added methods responsible for saving and loading order of buttons to bottomtray. Order is saved after each drag'n'drop to
      ensure user's customization of bottomtray is not lost because of crash.
      
      - Added additional argument to layoutstack movePanel() method which tells it to move panel to the beginning of mPanels vector
      without requiring a pointer to panel before which it should be inserted.
      
      Reviewed by Vadim Savchuk.
      a30bc718
    • Andrew Dyukov's avatar
      VWR-20705 VWR-20706 FIXED Implemented drag'n'drop of buttons in bottomtray. · e04dabd2
      Andrew Dyukov authored
      - Though visually user drags buttons, layout panels are really moved. To move one panel before other, new method movePanelBeforeOther() was added to layout stack.
      
      - When drag'n'drop is finished, order of panels in layout stack mToolbarStack is changed, and also order vectors are updated in bottomtray.These are vectors mButtonsProcessOrder and mButtonsOrder. mButtonsOrder was introduced in this changeset to store order of all bottomtray buttons that may change place via drag'n'drop and should save and load it between sessions. mButtonsProcessOrder is not enough for it because it contains only buttons that may be hidden(and for example Speak button is not included in it).
      
      - To pass mouse events from buttons to bottomtray, new class LLBottomtrayButton was added (and new widget bottomtray_button for it).
      
      Reviewed by Vadim Savchuk.
      e04dabd2
  31. Aug 26, 2010
  32. Aug 25, 2010
  33. Aug 24, 2010
  34. Aug 13, 2010
  35. Feb 25, 2010
  36. Feb 24, 2010
  37. Feb 02, 2010
Loading