| Age | Commit message (Collapse) | Author |
|---|
|
Of course, preserve lang= localization from default skin.
Assume that localized steam/xui/*/strings.xml file without create_account_url key will
default to create_account_url key from steam/xui/en/strings.xml. That's how it
works in the default skin, anyway.
|
|
Splitting the 'add' from modifications unique to this skin facilitates code
review.
|
|
We have appropriate translations of the join.secondlife.com registration path,
but the Russian and Turkish [create_account_url] strings in strings.xml didn't
specify them. At Eli's request, added lang= params to these two.
|
|
The URL whose simple form is http://join.secondlife.com actually appears in a
number of places in the localized notifications.xml files. It's supposed to be
localized for the current viewer language -- and in strings.xml, it is. But
the same URL is restated a couple times in notifications.xml, sometimes
localized, sometimes not.
Add "create_account_url" to init_default_trans_args(), permitting us to embed
[create_account_url] anywhere in the skin files. Then replace all known
occurrences of that URL in notifications.xml files with [create_account_url].
|
|
We already have a "create_account_url" string in strings.xml, and in fact --
according to Eli -- the strings.xml values are "better" for non-English
languages. Unfortunately those "better" strings weren't being used. They were
tied to the FirstRun notification, which seems to have been disengaged.
Changed llpanellogin.cpp to look in strings.xml rather than panel_login.xml
when clicking the "Sign Up" link on the login panel.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Over the years we've skipped more and more of the tests in
llhttpclient_test.cpp (nee llhttpclient_tut.cpp) because they've relied on
particular behaviors from Internet sites not under our control.
We skipped a test that fetches llsd+xml from secondlife.com because
"secondlife.com is not reliable enough for unit tests."
We skipped a test that tries to observe a failure with "http://www.invalid"
because some local ISPs turn "no such domain" DNS errors into valid pages
offering the requester to buy the specified domain name.
Today we've had to skip tests attempting to contact "http://www.google.com"
for reasons we haven't yet diagnosed, but that probably have to do with
Google's IPv6 rollout.
Use local temp server test_llsdmessage_peer.py as the success destination,
eliminating DNS, Internet access and remote server behavior as failure modes.
Use idle localhost port for failure test.
Re-enable all skipped LLHTTPClient tests!
Re-enable on Windows!
In support of these tests, modify test_llsdmessage_peer.py:
Support HEAD as no-data variant of GET.
Change GET result dict to avoid resembling an error response -- confusing.
Make GET/POST return actual dict rather than undecorated string "success".
Because of that last, change llcapabilitylistener_test.cpp and
llsdmessage_test.cpp to extract "reply" key from response rather than
expecting response to be a string itself.
|
|
indra/test/llhttpclient_tut.cpp ==> indra/llmessage/tests/llhttpclient_test.cpp,
with corresponding CMakeLists.txt changes in their respective directories.
This first commit merely moves the test source file without changing it --
separating out moves from edits simplifies code review.
|
|
Today, 2012-06-06, LLHTTPClient::get("http://www.google.com/") has stopped
working. This is unrelated to viewer code changes: it crosses repo boundaries.
Skip the afflicted tests to get builds working until we can recast the tests
to avoid the flaky dependency.
|
|
The change from LLProcessLauncher to LLProcess introduces the possibility of a
NULL (default-constructed) LLProcessPtr. Add certain static LLProcess methods
accepting LLProcessPtr, forwarding to nonstatic method when non-NULL but doing
something reasonable with NULL. Use these methods in LLPLuginProcessParent.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The previous tip Windows APR package:
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-apr/rev/256201/arch/CYGWIN/installer/apr_suite-1.4.5-windows-20120509.tar.bz2
contained a libapr-1.dll that would not load on Windows XP. The code contained
static calls to Windows API functions not yet present in Windows XP.
The new Windows APR package has made those calls conditional, using
LoadLibrary() and GetProcAddress() calls.
The hope is that this new viewer build will behave identically on Windows
Vista or later -- but unlike its predecessor, will also launch on Windows XP.
|
|
|
|
|
|
|
|
|
