Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
|
|
+ remove unreachable code
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
viewer, third-party links open in user's browser
|
|
replace llinfos, lldebugs, etc with new LL_INFOS(), LL_DEBUGS(), etc.
|
|
|
|
|
|
|
|
* URL's are in place with the [GRID_LOWERCASE] used in the link to go to the
proper page based on the grid.
* Added "GRID_LOWERCASE" substitution for URL's since it is case sensitive
|
|
removed unused LLWeb functions for opening non-web media
moved logic inside floaters and away from auxiliary functions
|
|
changed browser id back to a string so it accepts malformed uuid strings
coming from webkit - "{uuid}" instead of "uuid"
|
|
search floater derives from floater_web_content
all web content now uses floater_web_content instead of media_browser
|
|
|
|
|
|
viewer web apps
|
|
Reviewed by Callum.
|
|
the other variant.
|
|
from javascript.
This includes a Mac build of llqtwebkit from the following sources:
revision aacdf69cbf5aa12d77c179296e31ef643ed1ef4a of http://qt.gitorious.org/+lindenqt/qt/lindenqt (currently head of the 'lindenqt' branch)
revision 81ab5ae326f0 of http://hg.secondlife.com/llqtwebkit (currently head of the default branch)
Reviewed by Callum.
|
|
|
|
embedded browser, regardless of the state of the "UseExternalBrowser" pref.
|
|
|
|
windows.
Added an optional "target" parameter" to LLWeb::loadURL and loadInternal.
Made LLViewerMediaImpl::handleMediaEvent pass the target attribute of clicked links through.
Set floater_media_browser.xml to allow multiple instances.
Added LLFloaterMediaBrowser::create() and made LLFloaterMediaBrowser assume the incoming tag is the window's target, not the URL.
Reviewed by Richard at http://codereview.lindenlab.com/2641050
|
|
monroe already did most of this, just moved dialog for confirming opening external browser to common code that calls out to external browser
so no way to skip notification unless the user opts out
|
|
|
|
|
|
|
|
reviewed by Callum
|
|
Url substitutions now support a [FIRST_LOGIN] parameter that returns
the value of gAgent.isFirstLogin(). This now gets passed to the Home
sidetray web site as a firstlogin query param.
|
|
This is instead of sending the Parcel ID (LLUUID), which it turns out
the server never sends to the viewer (LLParcel::getID() always returns
NULL).
|
|
The correct and general fix is to change English.lproj/language.txt.
This fix here is a more targeted and less risky fix at this stage
of the release cycle.
|
|
These IDs are sent as the following query parameters to the search
server: sid=, rid=, pid=, for the Session ID, Region ID, and Parcel ID
respectively.
For some reason, Parcel ID always seems to be NULL though. I'll file a
separate JIRA for that.
|
|
|
|
https://hg.aws.productengine.com/secondlife/viewer-2-0/
|
|
The search URL is now specified in app_settings/settings.xml (instead
of in floater_search.xml), and it is now defined more flexibly with
support for various substitution strings, such as [QUERY], [AUTH_KEY],
[MATURITY], [GODLIKE], etc.
I pulled the common substitution code out into a new static method,
LLWeb::expandURLSubstitutions(). This provides support for common
strings like [VERSION], [CHANNEL], [LANGUAGE], [OS], etc. The Help and
Home sidetray code has been updated to use this new function, to avoid
replicating this behavior 3 times.
I also cleaned up the app_settings/settings.xml file and removed the
old search keys of: SearchURLDefault, SearchURLQuery, and
SearchURLSuffix2.
|
|
--HG--
branch : product-engine
|
|
|
|
|
|
Apparently, pre-login notifications use LLAlertDialog, but post-login
notifications use LLToastAlertPanel. The latter is basically a copy
and paste of the former, with some local modifications. However, the
person who copy/pasted the code did not initialize the URLLoader
callback, so all notifications that tried to open a web page on a
button click after login were failing.
I've added comments that this code should be refactored, preferably as
a subclass of LLAlertDialog. In the meantime, I've tried to clean it
up a bit by not duplicating the nested URLLoader class (which would've
required further duplication to reimplement the exact same loader class
that LLAlertDialog uses). This let me then initialize the URLLoader
callback for LLToastAlertPanel, to fix this specific bug.
Again... arghhh!!
|
|
Viewer 2.0 (viewer-2.0.0-3). This provides support for clickable Urls
in text editors and textboxes, with right-click context menus,
tooltips, and alternate link labels. This includes alert boxes, the
login progress window, local chat and IM interfaces, etc. As well as
context menus for avatars and groups in list widgets. Includes fixes
for the following individual JIRAs:
DEV-8763 VWR-10636: Hyperlinks in alert dialogs should be selectable (clickable)!
DEV-38829 EXT-742: Remove LLLink class
DEV-35459 VWR-14679: SLURLs and teleport Links not parsed properly
DEV-19842 VWR-8773: Closing parenthesis ")" breaks urls
DEV-21577 VWR-9405: In-world SLURLs containing "(" or ")" are not treated as a hyperlink in chat
DEV-37652 SEC-435: Object Chat/IMs are untraceable (VWR-2388) Fix has left flaw
DEV-10353: URLs in chat log terminated incorrectly when newline in chat
DEV-2925: In chat history, use a teleport hyperlink as source name for object IMs
DEV-36192: Need a way to copy Avatar names and Group names
DEV-2926: Allow viewer hyperlinks to have different text than the actual url
DEV-27253: Add easy way to copy URLs from viewer chat
DEV-38274: Make About Second Life window use new Url hyperlinking features
DEV-39076: No url support in Text Editors
DEV-7476 VWR-2172: Add hyperlinks to chat console for easier access
DEV-7475: Add hyperlinks to notecards!
DEV-35375 EXT-128: HTTPS urls aren't loaded in the internal browser by click
Master JIRA issues: DEV-32819, DEV-323820, DEV-7474
Testing performed against QAR-1789
svn merge -r 131623:131889 svn+ssh://svn.lindenlab.com/svn/linden/branches/viewer/viewer-2.0.0-slurl-3
svn merge -r 131978:132515 svn+ssh://svn.lindenlab.com/svn/linden/branches/viewer/viewer-2.0.0-slurl-3
|
|
svn+ssh://svn.lindenlab.com/svn/linden/branches/moss/pluginapi_05-merge@129910
svn merge -r 129913:131718 svn+ssh://svn.lindenlab.com/svn/linden/branches/pluginapi/pluginapi_05
Some branch shenannigans in the pluginapi_05 branch caused this to become a two-part merge.
|