| Age | Commit message (Collapse) | Author |
|---|
|
changes to common libraries from the server codebase:
* Additional error checking in http handlers.
* Uniform log spam for http errors.
* Switch to using constants for http heads and status codes.
* Fixed bugs in incorrectly checking if parsing LLSD xml resulted in an error.
* Reduced spam regarding LLSD parsing errors in the default completedRaw http handler. It should not longer be necessary to short-circuit completedRaw to avoid spam.
* Ported over a few bug fixes from the server code.
* Switch mode http status codes to use S32 instead of U32.
* Ported LLSD::asStringRef from server code; avoids copying strings all over the place.
* Ported server change to LLSD::asBinary; this always returns a reference now instead of copying the entire binary blob.
* Ported server pretty notation format (and pretty binary format) to llsd serialization.
* The new LLCurl::Responder API no longer has two error handlers to choose from. Overriding the following methods have been deprecated:
** error - use httpFailure
** errorWithContent - use httpFailure
** result - use httpSuccess
** completed - use httpCompleted
** completedHeader - no longer necessary; call getResponseHeaders() from a completion method to obtain these headers.
* In order to 'catch' a completed http request, override one of these methods:
** httpSuccess - Called for any 2xx status code.
** httpFailure - Called for any non-2xx status code.
** httpComplete - Called for all status codes. Default implementation is to call either httpSuccess or httpFailure.
* It is recommended to keep these methods protected/private in order to avoid triggering of these methods without using a 'push' method (see below).
* Uniform error handling should followed whenever possible by calling a variant of this during httpFailure:
** llwarns << dumpResponse() << llendl;
* Be sure to include LOG_CLASS(your_class_name) in your class in order for the log entry to give more context.
* In order to 'push' a result into the responder, you should no longer call error, errorWithContent, result, or completed.
* Nor should you directly call httpSuccess/Failure/Completed (unless passing a message up to a parent class).
* Instead, you can set the internal content of a responder and trigger a corresponding method using the following methods:
** successResult - Sets results and calls httpSuccess
** failureResult - Sets results and calls httpFailure
** completedResult - Sets results and calls httpCompleted
* To obtain information about a the response from a reponder method, use the following getters:
** getStatus - HTTP status code
** getReason - Reason string
** getContent - Content (Parsed body LLSD)
** getResponseHeaders - Response Headers (LLSD map)
** getHTTPMethod - HTTP method of the request
** getURL - URL of the request
* It is still possible to override completeRaw if you want to manipulate data directly out of LLPumpIO.
* See indra/llmessage/llcurl.h for more information.
|
|
The tricky thing about this fix is that the "Log In" button used to be in the
same layout_panel as the username and password fields. Now it's not, so the
fact that it's the default button for its layout_panel doesn't matter because
that layout_panel doesn't have focus. Richard pointed out that we can make the
commit action for the username and password fields initiate login -- as long
as neither field implicitly runs its commit action when it loses focus!
|
|
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.
|
|
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().
|
|
|
|
persistent settings
|
|
Login-panel logic distinguishes "system grid" from "non-system grid." With
Oz's recent changes for pathfinding, now only agni and aditi are "system
grids;" anything else configured into grids.xml is a "non-system grid." The
difference is that when you select a "non-system grid" on the grid selector,
we turn off the "lost password?" link and the "create account" button -- since
how can we help with either if we don't recognize the grid? This logic already
existed, but only turned off the create-account button, leaving the new title
"CREATE YOUR ACCOUNT" over an empty corner of the login panel. Turn that off too.
|
|
Some viewer-development code had been moved, and so wasn't patched with my
panel_login layout changes; verified each of my llpanellogin.cpp commits
against new tip rev. Reformatted panel_login.xml in the spirit of the
preferred indentation scheme but with my layout changes.
|
|
|
|
The "Start at:" combo box and the grid-selector box can be turned on and off
with checkboxes on the Preferences floater. Break the bottom-left layout_panel
on panel_login into several different layout_panels so when these UI elements
disappear, other controls move left to fill the holes. Similarly, when you
turn on either or both of the UI elements in question, the remaining controls
in that general bottom-left area move right to accommodate.
Tweak C++ and non-English panel_login.xml overrides to reflect widgets'
containment in new layout_panel elements.
Discard obsolete "mode_selection_text" and "mode_combo" translations from non-
English panel_login.xml overrides.
|
|
This includes replacing the small "Sign up" link with a "CREATE YOUR ACCOUNT:
Start now" button, requiring a small tweak to the C++ code to Do The Right
Thing when the button (vs. the link) is clicked.
|
|
|
|
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.
|
|
|
|
|
|
names are disabled.
* Fixed LLAvatarName::getLegacyName() to work when display names are disabled
(it used to return ' ', i.e. empty first and last name separated with a space).
* Added some debugging messages.
|
|
|
|
removed all references to basic mode
|
|
|
|
change modes and restart while logged in"
|
|
|
|
added mode switching button to status bars for advanced and basic mode, changed
login combo box to use menu instead
|
|
to donwload the v2.7.2 Beta
Backed out changeset: 3a391669629d
|
|
|
|
|
|
|
|
bundle:E:\code\viewer-experience+c:\users\richard\appdata\local\temp\thg.t3awyz\ssh__richard@hg.lindenlab.com_richard_viewer-experience-merge_2xcevh.hg
|
|
|
|
Misc improvements to make the login page load properly.
|
|
mesh-development and viewer-beta.
|
|
typed like "firstname.lastname" or "firstname_lastname" or user name consists of a single word.
Restoring the fix for STORM-842 (changeset ccfd9a2e3b3c) lost during merging (changeset 5618715b7b2d).
|
|
false impression that it does nothing
combo box now changes back to previous label when selecting don't quit
|
|
|
|
|
|
|
|
add confirmation dialog to mode change
|
|
typed like "firstname.lastname" or "firstname_lastname" or user name consists of a single word.
|
|
|
|
|
|
instead of per-machine.
- Made changes in code of floater preferences and panel login that were required because of turning the setting per-account.
- Added new method to LLFloaterPreference that looks for current user's record in saved favorites file and removes it.
|
|
chopper)
|
|
|
|
|
|
that used it. Rev by Brad
|
|
waiting to cut you. Rev. by Brad
|
|
showing them on login screen.
- Changed the way SLURLs are cached a little, because previous one introduced problems with theit order.
- Also allowed saving of favorites to disk even if not all of them received SLURL info - this is done to avoid favorites not saving when there is at least one "dead" landmark among them.
- "Username" field on login screen is now not a lineeditor, but combobox (to enable autocompletion), but without button (Esbee asked for this in ticket for security reasons, and perhaps for visual consistency).
- Elements of this combobox are names of users whose favorites we have saved in file.
- Contents of "Start at:" combobox are changed depending on changes in "Username"- if username is present in favorites file, favorites for this user are added there.
- New callback was added to LLCombobox and used in this fix, because present ones weren't enough to easily track changes in text entry.
|
|
"Start at" combobox on login screen was implemented.
Implementation details:
- File is saved on exit from viewer and not immediately on changes as was written in spec. It is done to make this file consistent with favorites order: order of favorites is saved on exit,
so if favorites info is saved in other moment earlier, crashing viewer or other unexpected way of finishing its work (i.e. via Windows task bar) would cause inconsistence between favorites order
saved per account and one from this new file.
- File is saved in user_settings\stored_favorites.xml.
- If you uncheck the option in Preferences and press OK, the file gets immediately deleted (according to spec).
Issues that require further changes:
- Currently only favorites of last logged in user are shown in login screen. Showing favorites of multiple users will be implemented later when design for it is approved by Esbee.
- Preference is now global for all users, because design states it may be changed before login, and we don't have account info at the moment. But it doesn't seem to be a good idea, so changes in design are needed.
- Currently the way of retrieving SLURLs needs optimization in a separate ticket.
More detailed design approved by Esbee is needed to develop it further, perhaps in new tickets.
|
|
|
|
|
