Previously we borrowed the sourceid= param value from create_account_url,
which we "happened to know" was overridden with the sourceid of interest. Now
that we have a settings variable that directly captures sourceid, though, much
more straightforward to use that.
The whole point of --skin steam was to override (specifically)
"create_account_url" in strings.xml, adding to each URL value a sourceid= URL
parameter. Now we can do that more simply with '--set sourceid blah'. Less
overhead, less maintenance, scales better to potential future sourceid values.
Remove the steam skin.
Calling LLTrans::setDefaultArg() after LLTransUtil::parseStrings() is almost
good enough -- but it fails to address the case in which one or more of the
default_trans_args strings (e.g. "create_account_url") embeds a reference to
the new substitution. So after the setDefaultArg() call, go back through
default_trans_args, refetching each string to perform the substitution and
updating it with a setDefaultArg() call of its own. All this is way too much
logic to replicate in both LLAppViewer::initConfiguration() and init(), so
break out new LLAppViewer::initStrings() method and call it from both places.
The steam/xui/*/strings.xml files are intended only to override a single
string (create_account_url). But until the strings.xml C++ code supports
fallback to the default skin, we must manually keep them synchronized except
for that one string.
Because create_account_url should vary between viewer languages and skins,
we've made an effort to ensure that create_account_url is used everywhere,
instead of directly embedding http://join.secondlife.com. Recent rev
6ee71714935f accidentally reinserted the link embedded in the "FirstRun"
notification for language 'zh'. Delete it again.
This allows the login-page server to respond to any sourceid= associated with
the create_account_url, which (we happen to know) varies by skin -- e.g. for
the Steam viewer.
Previous logic constructed a std::ostringstream, directly messing with '?' vs.
'&', ugly libcurl escape calls etc. Now we can deconstruct the LLGridManager::
getLoginPage() URL, supplement the params map as needed and then rebuild a new
URL using LLURI::buildHTTP().
The LLURI::buildHTTP() overloads that take an LLSD 'path' accept 'undefined',
LLSD::String and (LLSD::Array of LLSD::String). A sequence of path components
passed in an Array is constructed into a slash-separated path. There are unit
tests in lluri_test.cpp to exercise that case.
To my amazement, there were NO unit tests covering the case of an LLSD::String
path. The code for that case escaped and appended the entire passed string.
While that might be fine for a 'path' consisting of a single undecorated path
component, the available documentation does not forbid one from passing a path
containing slashes as well. But this had the dubious effect of replacing every
slash with %2F.
In particular, decomposing a URL string with one LLURI instance and
constructing another like it using LLURI::buildHTTP() was not symmetrical.
Having consulted with Richard, I made the string-path logic a bit more nuanced:
- The passed path string is split on slashes. Every path component is
individually escaped, then recombined with slashes into the final path.
- Duplicate slashes are eliminated.
- The presence or absence of a trailing slash in the original path string is
carefully respected.
Now that we've nailed down how it ought to behave -- added unit tests to
ensure that it DOES behave that way!!
MAINT-1444 complains that with all optional login-panel controls enabled, the
login panel is wider than 1024 pixels: at that width, the new "Start now"
button is pushed completely off the right edge of the window. Richard told me
how to tweak the layout so that the controls can squeeze together in an
overlapping way, enabling all controls to be visible even at 1024 width.
Nat Goodspeed