| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
build/edit floater was being dirtied at the wrong time.
|
|
the viewer.
|
|
toggling the phantom flag of a linkset through the Pathfinding Linksets floater.
|
|
the pathfinding linksets floater.
|
|
last commit. This should fix that issue.
|
|
|
|
pathfinding object into the avatar name cache so that each object can simply update its respective row in the scroll list rather than rebuilding from scratch after all names are loaded.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
builds as apparently they never worked there.
|
|
LLPathfindingObject::handleAvatarNameFetch being called after the corresponding LLPathfindingObject has been deleted.
|
|
|
|
|
|
|
|
persistent settings
|
|
|
|
|
|
|
|
I recently tried to wade through llhandle.h and got somewhat perplexed. Armed
with an explanation from Richard, I've added notes to the file to try to make
it a bit less mysterious.
|
|
|
|
|
|
Leaving llhandle.h in llui restricts the set of viewer project directories
which could potentially use it, and there's nothing whatsoever UI-specific
about it.
|
|
|
|
|
|
|
|
unlock keychain.
Only unlock and code sign if running under Team City.
|
|
for PATH-542. The viewer calculated rotation resulting from an object's angular velocity was being incorrectly reset when the corresponding object update was received. With this bugfix, the rotation resulting from the angular velocity is accumulated separately and is re-appplied when the object update resets the object's rotation.
|
|
Added them to correct place (Cmake config)
|
|
For as long as I've been paying attention to viewer logs, every run has always
stated -- in all-caps, no less! :
NOTE: ALL NOTIFICATIONS THAT OCCUR WILL GET ADDED TO IGNORE LIST FOR LATER RUNS.
I have always found that unsettling, having little desire to automatically
ignore notifications -- especially not whatever random set happens to manifest
during a particular run. However, over time I've learned that it seems to have
no actual impact. I've wondered (not too hard) what it actually *does* mean --
but generally I'm looking at a viewer log because I'm in hot pursuit of some
quite different problem.
Stumbling across the source for this message today in
LLViewerWindow::LLViewerWindow, I was shocked -- shocked! -- to find it was
being produced unconditionally! Therefore it has heretofore been utterly
meaningless log spam. It provided no additional information whatsoever to
anyone reading a log -- only that vague sense of unease.
Make this conditional on gSavedSettings.getBOOL("IgnoreAllNotifications"),
which would appear to be the original intent. Now its presence (or absence)
actually says something about internal conditions in the viewer.
|
|
Popup text used to end with the question:
Visit [[create_account_url] [SECOND_LIFE] web site] to create a new account?
presumably to set context for the buttons labeled "New Account..." and
"Continue". At Leo's request, remove the question and relabel the yes button
"Create Account...".
|
|
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.
|
|
|
|
rather than fixing them; changing llcommon to be statically linked avoids the symbol issues with llcommon.dll
|
|
|
|
|
