summaryrefslogtreecommitdiff
path: root/indra/newview/llpanellogin.cpp
AgeCommit message (Collapse)Author
2020-07-20Merge branch 'master' into DRTVWR-501-maintAndrey Lihatskiy
# Conflicts: # autobuild.xml # indra/newview/llimprocessing.cpp
2020-03-25SL-11216: Convert LLVersionInfo to an LLSingleton.Nat Goodspeed
This changeset is meant to exemplify how to convert a "namespace" class whose methods are static -- and whose data are module-static -- to an LLSingleton. LLVersionInfo has no initClass() or cleanupClass() methods, but the general idea is the same. * Derive the class from LLSingleton<T>: class LLSomeSingleton: public LLSingleton<LLSomeSingleton> { ... }; * Add LLSINGLETON(LLSomeSingleton); in the private section of the class. This usage implies a separate LLSomeSingleton::LLSomeSingleton() definition, as described in indra/llcommon/llsingleton.h. * Move module-scope data in the .cpp file to non-static class members. Change any sVariableName to mVariableName to avoid being outright misleading. * Make static class methods non-static. Remove '//static' comments from method definitions as needed. * For LLVersionInfo specifically, the 'const std::string&' return type was replaced with 'std::string'. Returning a reference to a static or a member, const or otherwise, is an anti-pattern: the interface constrains the implementation, prohibiting possibly later returning a temporary (an expression). * For LLVersionInfo specifically, 'const S32' return type was replaced with simple 'S32'. 'const' is just noise in that usage. * Simple member initialization (e.g. the original initializer expressions for static variables) can be done with member{ value } initializers (no examples here though). * Delete initClass() method. * LLSingleton's forté is of course lazy initialization. It might work to simply delete any calls to initClass(). But if there are side effects that must happen at that moment, replace LLSomeSingleton::initClass() with (void)LLSomeSingleton::instance(); * Most initClass() initialization can be done in the constructor, as would normally be the case. * Initialization that might cause a circular LLSingleton reference should be moved to initSingleton(). Override 'void initSingleton();' should be private. * For LLVersionInfo specifically, certain initialization that used to be lazily performed was made unconditional, due to its low cost. * For LLVersionInfo specifically, certain initialization involved calling methods that have become non-static. This was moved to initSingleton() because, in a constructor body, 'this' does not yet point to the enclosing class. * Delete cleanupClass() method. * There is already a generic LLSingletonBase::deleteAll() call in LLAppViewer::cleanup(). It might work to let this new LLSingleton be cleaned up with all the rest. But if there are side effects that must happen at that moment, replace LLSomeSingleton::cleanupClass() with LLSomeSingleton::deleteSingleton(). That said, much of the benefit of converting to LLSingleton is deleteAll()'s guarantee that cross-LLSingleton dependencies will be properly honored: we're trying to migrate the code base away from the present fragile manual cleanup sequence. * Most cleanupClass() cleanup can be done in the destructor, as would normally be the case. * Cleanup that might throw an exception should be moved to cleanupSingleton(). Override 'void cleanupSingleton();' should be private. * Within LLSomeSingleton methods, remove any existing LLSomeSingleton::methodName() qualification: simple methodName() is better. * In the rest of the code base, convert most LLSomeSingleton::methodName() references to LLSomeSingleton::instance().methodName(). (Prefer instance() to getInstance() because a reference does not admit the possibility of NULL.) * Of course, LLSomeSingleton::ENUM_VALUE can remain unchanged. In general, for many successive references to an LLSingleton instance, it can be useful to capture the instance() as in: auto& versionInfo{LLVersionInfo::instance()}; // ... versionInfo.getVersion() ... We did not do that here only to simplify the code review. The STRINGIZE(expression) macro encapsulates: std::ostringstream out; out << expression; return out.str(); We used that in a couple places. For LLVersionInfo specifically, lllogininstance_test.cpp used to dummy out a couple specific static methods. It's harder to dummy out LLSingleton::instance() references, so we add the real class to that test.
2020-02-03Merge branch 'DRTVWR-500' into DRTVWR-501Andrey Lihatskiy
2020-01-29SL-12590 SL-12608 Fixed wrong statesandreykproductengine
2020-01-20SL-12596 Fixed incorectly enabled checkbox and enabled login buttonandreykproductengine
2020-01-16SL-12556 Fixed another case of login button being activeandreykproductengine
2020-01-13SL-12555 Fixed Login failed with credencials after the first incorrect entryandreykproductengine
2020-01-13SL-12556 Fixed The ‘Log In’ button being active with empty fieldsandreykproductengine
2020-01-09SL-12533 Correct password drop and fixed 'dirty' conditionandreykproductengine
2020-01-09SL-12533 Switching between grids on login page does not always switch the ↵andreykproductengine
remembered user list
2020-01-03SL-9699 Do not disable 'remember me' checkboxandreykproductengine
2019-11-17SL-9699 Fixed processing of placeholderandreykproductengine
2019-11-15SL-9699 First login panel checkbox was misinterpretedandreykproductengine
2019-11-13SL-9699 Field should be populated as long as there is data, regardless of ↵andreykproductengine
'remember password'
2019-10-31SL-11913 Favorites not resetting properlyandreykproductengine
2019-08-09SL-9699 Login selectionandreykproductengine
2019-04-26Automated merge with file:///Users/nat/linden/viewer-gridselectNat Goodspeed
2019-04-25SL-11049: Notice explicit --grid command-line switch and honor it.Nat Goodspeed
LLPanelLogin's constructor checks both LLGridManager::getGrid() and LLStartUp::getStartSLURL(). But by the time we get there, we've blurred the distinction between explicit command-line arguments and defaults left over from a previous run. Of course, if the grid implied by getStartSLURL() is the same as the getGrid(), the distinction is irrelevant. But if they differ, up until now, getStartSLURL() has always "won" -- even when getGrid() was set by an explicit --grid switch whereas getStartSLURL() was only left over from a previous run. Notice that case and try to avoid overriding the explicitly-specified grid with the grid from the default SLURL.
2019-04-03SL-10685 LLPanelLogin crashandreykproductengine
2018-06-18MAINT-8751 Add a link to create an account to the viewer login screenmaxim_productengine
2018-04-20MAINT-8540 Eliminated a lot of xui related log warnings on startup and ↵andreykproductengine
opening preferences
2018-04-05MAINT-8488 FIXED Favourite location list on login screen is not updated ↵maxim_productengine
after pressing "Esc" key while in username field
2017-12-22MAINT-8120 Account that contains last name Resident cannot see his Favorites ↵Mnikolenko Productengine
on Login Screen
2017-12-21MAINT-8110 clear password field after failed login instead of showing fake dotsMnikolenko Productengine
2017-12-15MAINT-8098 FIXED The Viewer uses http: for the splash page even when ↵Mnikolenko Productengine
configured for https:
2017-09-29MAINT-7835 FIXED issue with resetting username after failed attempt to loginMnikolenko Productengine
2017-09-28MAINT-7835 Start location is not changed correctly via 'maps.secondlife.com' ↵Mnikolenko Productengine
link in some cases
2017-08-25MAINT-7739 Make LLOSInfo a Singletonandreykproductengine
2016-04-04merge with 4.0.3-releaseOz Linden
2016-03-17MergeRider Linden
2016-03-16merge changes for DRTVWR-417Oz Linden
2016-01-06MAINT-898 FIXED Viewer attempts to log in with no passwordMnikolenko ProductEngine
2015-11-10remove execute permission from many files that should not have itOz Linden
2015-09-29MAINT-5614: Cancel the fade timer for the progress screen when hidding progress.Rider Linden
2015-09-24MAINT-5614: Put the sInstance back the way it was for llpanelloginRider Linden
2015-09-22Reuse old login panel...Rider Linden
2015-09-15MAINT-5507: Remove llcurl, move constant values and untilities to llcorehttp libRider Linden
2015-08-25MergeRider Linden
2015-06-03Remove vestigial httpclient.h include from files that no longer need it.Rider Linden
2015-04-28increment viewer version to 3.7.29Mnikolenko ProductEngine
2015-04-28Merge viewer-release, become version 3.7.29Mnikolenko ProductEngine
2015-04-10restore the ll[io]fstream because we need them as wrappers on Windows for ↵Oz Linden
wide char paths; on other platforms they are now just typedefs to the std classes
2015-04-07replace llifstream and llofstream with std::ifstream and std::ofstream ↵Oz Linden
respectively
2015-04-07convert llifstream and llofstream to std::ifstream and std::ofstream ↵Oz Linden
respectively
2015-02-24merge changes for 3.7.25-releaseOz Linden
2015-02-24merge changes for MAINT-4790Oz Linden
2015-01-30MAINT-4853 FIXED Pressing the ENTER key when entering a location into the ↵Mnikolenko ProductEngine
Type a location field, doesn't log you in
2015-01-30MAINT-4853 FIXED Pressing the ENTER key when entering a location into the ↵Mnikolenko ProductEngine
Type a location field, doesn't log you in
2015-01-22MAINT-4790 WIP Previously selected login location is correctly shown now. ↵Mnikolenko ProductEngine
Font on the Log In button was changed back. Text offset was set for Locations combobox.
2015-01-14MAINT-4790 WIP code clean-upMnikolenko ProductEngine
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-21 12:14:19 +0000