Age | Commit message (Collapse) | Author |
|
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
|
|
|
|
from group or friend.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
instead of fetching a name
|
|
|
|
|
|
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.
|
|
|
|
build.sh LogScan greps for "error:" (among other things) so removing the colon
from the test name "syntax_error" should help.
|
|
|
|
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.
|
|
window as well
|
|
notifications simultaneously when he accept/decline friendship offer
|