| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The logic in llcommandlineparser.cpp's setControlValueCB() callback function
for converting command-line switch argument values from string to the actual
type of the map-to settings variable had a couple special cases for boolean
and LLSD array. But for S32, U32 and F32, it simply used default LLSD
string-to-numeric conversion. LLSD's string-to-numeric conversion is a bit
lame: for non-numeric strings, it shrugs and returns 0.
Introduce onevalue() and badvalue() helper functions that, like certain errors
during command-line parsing, throw LLCLPError. Use them to streamline certain
redundancies in setControlValueCB(). Introduce convertTo<T>() helper function
that uses boost::lexical_cast() for slightly more stringent conversions. Add
cases for U32, S32 and F32 targets.
setControlValueCB() is actually called only by LLControlGroupCLP::notify(),
not during actual command-line parsing.
Make LLControlGroupCLP::notify() return bool. Make it catch LLCLPError, set
the error for getErrorMessage() and return false on that exception.
Package LLAppViewer::initConfiguration()'s response to initParseCommandLine()
returning false as a new handleCommandLineError() function; invoke it both
there and when LLControlGroupCLP::notify() returns false.
|
|
|
|
|
|
|
|
Previous CHOP-959 logic set a flag to remember that settings variable
RenderQualityPerformance was set (by --graphicslevel), so it could be applied
once LLViewerWindow is constructed. But on first viewer run, LLViewerWindow
constructor calls LLFeatureManager::applyRecommendedSettings(), which resets
that settings variable! So don't just set a flag, actually capture the
requested RenderQualityPerformance value for later.
|
|
|
|
|
|
|
|
viewer_manifest.py uses its base-class llmanifest.LLManifest.put_in_file()
method to create several different files in the install image being
marshalled. I based the logic to create settings_install.xml on that example.
Unfortunately I failed to notice that after every existing call, the script
also explicitly appended the newly-created file to self.file_list... which
only matters on Windows. file_list is fed to the NSIS installer.
Change put_in_file() method to implicitly append to self.file_list.
Change every existing viewer_manifest.py call to pass new put_in_file(src=)
param instead of explicitly appending to self.file_list.
|
|
|
|
|
|
The comment advises grepping for "Global" rather than specifically pointing to
llcontrol.cpp because that's NOT the only place that relies on the name
"Global"! Besides, by the time someone does want to change the name, still
other such dependencies could've crept in.
|
|
Initial change made LLControlVariable::mPersist an enum, but retained
bool/BOOL public API. setPersist(true) set one value, setPersist(false) set
another, forcePersist() set the third. Per code review, expose enum to public,
make setPersist() (and LLControlVariable constructor, and LLControlGroup::
declareControl(), and all the LLControlGroup::declareMumble() methods, and all
the unit-test dummy declareMumble() method bodies) accept that enum. Remove
forcePersist(). Fix calls to LLControlGroup::declareMumble() accordingly.
Also rename PERSIST_YES to PERSIST_NONDFT, also per code review.
|
|
|
|
the windows builds to recognize the value
|
|
|
|
|
|
|
|
|
|
LLControlGroup::loadFromFile() can of course detect which LLControlGroup
instance it's loading. We only want to log unrecognized settings variables in
LLControlGroup "Global". Settings for "Don't show me this again" notifications
are in group "Warnings".
|
|
|
|
Change LLControlVariable::mPersist from bool to tri-state enum. Its 'true'
value used to mean "persist only if changed from default;" third state now
means "persist regardless of value." Add forcePersist() method to set that.
Replace isSaveValueDefault() method -- used only by logic to determine whether
to save the variable -- with shouldSave() method to encapsulate ALL that logic
rather than only part of it. shouldSave() recognizes PERSIST_ALWAYS state.
When loading an unrecognized control variable from a user settings file, use
forcePersist() to ensure that we later save that variable again.
Tweak one of the unit tests to adjust for new semantics.
|
|
LLControlGroup::declareControl(), declareString() etc. etc. all used to return
BOOL -- which no one ever examines because it unconditionally returned TRUE.
Make it return the (possibly new) LLControlVariable* instead.
|
|
A small, fixed set of cmd_line.xml switches can't reasonably be mapped to
settings variables, mostly because they affect the settings machinery itself.
Other than those, every new cmd_line.xml switch should map-to a settings
variable. Validate that only the known set does not have map-to; validate that
map-to variable actually exists.
|
|
|
|
|
|
|
|
|
|
|
|
Route --url and --slurl command-line switches through a common settings
variable. Treat them uniformly now. (Previously, passing --url would notice a
grid-specific SLURL and preselect that grid; --slurl wouldn't. Now both do.)
|
|
I've never really understood the usefulness of displaying world-global
coordinates in the Help -> About box. It seems to me far more useful to know
where you are within the current region. If that proves problematic, we can
display both sets of coordinates -- but let's try it this way first.
|
|
The existing POSITION variable gives "global" position: that is, your region-
local coordinates plus the (somewhat arbitrary) global coordinates of the
region's corner within the whole world. That may be meaningful to people on
the mainland, hard to say, but it correlates with nothing else available from
the viewer. POSITION_LOCAL gives you region-local coordinates, which could be
used (for instance) to construct a SLURL.
|
|
The cmd_line.xml entries:
analyzeperformance
crashonstartup
debugsession
disablecrashlogger
logmetrics
logperformance
noquicktime
replaysession
all specify map-to settings.xml variables -- none of which existed! Introduce
such variables. Instead of detecting the presence of a particular switch in
the command-line parser, use the value of its corresponding settings variable.
|
|
Use map-to in cmd_line.xml to inform the command-line processor that the
target variable for --graphicslevel is RenderQualityPerformance.
That lets us eliminate clunky llappviewer.cpp switch from '0' to 0, etc.
Moreover, previous switch statement only accepted 0 - 3, whereas
LLFeatureManager::setGraphicsLevel() actually accepts 0 - 6. Introduce
LLFeatureManager::isValidGraphicsLevel() and use that to validate.
Replace switch statement in setGraphicsLevel() mapping int constants to string
literals with static vector of level names, using same data for mapping as for
validating level numbers.
|
|
|
|
UserLoginInfo block had <key>Value</key> without the required subsequent
element to provide any actual value. This confused at least the Python
LLSD reader.
|
|
It seems that certain build hosts have an (obsolete? broken?) install of
indra.util.llmanifest under the system Python. If we append the local repo
indra/lib/python to sys.path, viewer_manifest.py pulls in the broken
llmanifest. Prepend to sys.path instead to ensure we get the right one.
|
|
Also clarify comment for ELLPath in lldir.h: ELLPath int values are read from
settings_files.xml.
|
|
|
|
|
|
However, for backwards compatibility, continue to recognize and discard
--skip-gridargs switch.
|
|
|
|
Instead of generating viewer command-line switch overrides into
the Windows shortcut,
an arguments.txt file on Mac, or
a gridargs.dat file on Linux,
generate a platform-independent settings_install.xml file containing
'sourceid' key (if 'sourceid' found in TeamCity environment variables).
All command-line override switches previously found in the aforementioned
files have happily become moot.
|
|
|
|
|
|
|
|
|
|
https://bitbucket.org/lindenlab/viewer-development-materials
|
|
|
