Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
lleventcoro_test.cpp runs clean (as modified for new API), and all the rest
builds clean, but the resulting viewer is as yet untested.
|
|
Coroutines for group moderation.
|
|
|
|
|
|
ChatLoadGroupMaxMembers to mitigate slow group loading.
|
|
multiple times, allow group to graw by 1 (me) then the rest (prevent having group remaining hidden).
|
|
CHUI-440 (Nearby chat participant list does not clear after teleport when conversation floater is closed/minimized)
fixed
|
|
agents without waiting for server message (which often doesn't come...).
|
|
server
|
|
trigger the sending of the agent list.
|
|
|
|
|
|
|
|
/Users/Aimee/Documents/Work/Linden-Lab/Development/viewer/convert/viewer-identity-evolution
|
|
|
|
|
|
chat.
This is a workaround until a way to request the current voice channel moderation mode is implemented in the viewer.
Details:
* Added method to initialize Speaker manager's Voice moderate_mode once Agent's participant state is known.
* Once agent's voice participant is updated this method is called.
* This method initializes Voice moderate_mode only once.
This is necessary to process "Mute everyone" menu item calls properly.
Also renamed moderateVoiceOtherParticipants methods with moderateVoiceAllParticipants and related staff.
Reviewed by Aimee Walton at https://codereview.productengine.com/secondlife/r/448/
--HG--
branch : product-engine
|
|
|
|
chat is already in "moderate_mode" state.
Partial fix (until restart moderator's viewer)
* store "moderate_mode" session state
* if session is already in requested state participants un/mute individually.
Known Issue:
"moderate_mode" session state is set to false on startup. Thus if moderator join voice chat with disabled voice it has incorrect state.
In this case when he sends "Mute everyone" request first time it has effect only to himself. Other unmuted participants are not muted.
Next "Mute everyone" request works properly: one request per participant is sent.
Reviewed by Aimee Walton at https://codereview.productengine.com/secondlife/r/423/
--HG--
branch : product-engine
|
|
|
|
(???)" for the name.)
* Implementation notes:
** special item is cloned from VCP to be used in LLAvatarList to reflect an Avaline caller.
** LLAvatarList extended to create instances of Avaline Caller
** Participant list now determines type of adding session participant (Avatar/Avaline Caller) and selects a way item will be created in avatar list
* Implementation behavior:
** The problem is when Avaline caller ends a call it is removed from Voice Client session but
still exists in LLSpeakerMgr. Server does not send such information.
HUCK was implemented to notify subscribers that Avaline callers are not anymore in the voice call.
** For now Avaline Caller is removed from the LLSpeakerMgr List when it is removed from the Voice Client session.
This happens in two cases: if Avaline Caller ends call itself or if Resident ends group call.
** If Resident joins group call where Avaline caller already exists that caller will appear in Resident's viewer (VCP & Group IM window)
** The callers are displayed as "AvaLine Caller 1", "AvaLine Caller 2" etc.
* Known issues:
** LLNonAvatarCaller should be removed from VCP (for avaline p2p calls). Updated Avatar & Participant Lists can be used instead of it.
Separate ticket will be opened to refactor this code.
--HG--
branch : product-engine
|
|
|
|
|
|
Ugh. Update on Tofu's patch for this bug.
Reviewed by Richard
|
|
|
|
Changed callback signature to full_name instead of first_name,last_name
Eliminated all calls to legacy (non-signal/non-boost-bind) lookup mechanism
Change Pay dialog names to SLURL links
Tweaked layout of Pay Resident and Pay via Object floaters to make SLURLs fit
Consolidate name first + " " + last concatenation in LLCacheName::buildFullName()
Reviewed with Kelly
|
|
-- replaced functionality to remove speacker from the list via Event timer.
-- removed calling of LLSpeakerMgr::update from LLPanelGroupControlPanel::draw() (group text chat)
For now list is updated when it is need.
--HG--
branch : product-engine
|
|
voice for non-connected participant avatar from miniinspector)
- improved condition to check if avatar can be moderated.
- if not moderation panel (with "Disable Voice" button) is not shown at all.
--HG--
branch : product-engine
|
|
--HG--
branch : product-engine
|
|
voice control panel
-- changed behavior of 'mute/unmute everyone else' action to disable/enable voice chat and allow/disallow selected participant
Improvements to have more intellectual processing of several following requests is necessary
--HG--
branch : product-engine
|
|
voice control panel
-- code refactored: moderator actions are moved from UI to IM Speaker Manager (and just called from UI).
--HG--
branch : product-engine
|
|
group chat(See old communication floater))
--HG--
branch : product-engine
|
|
llspeakers.* from dying llfloateractivespeakers. *
Decresed number of llfloateractivespeakers.h includes to a minimum.
--HG--
branch : product-engine
|