| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
viewer2009@lists.
|
|
objects/avatars - this is expected.
Effect from DaveP long ago, hover code by me long ago, just changing the default setting.
|
|
|
|
(ad70c07b05b6 was 'Reduced "Medium" font size, which is a temporary fix until menu font can be defined specifically. http://jira.secondlife.com/browse/EXT-1315')
This change was too all-around impactful just for the sake of the menu font - it made medium and small font sizes indistinguishable, leading to lots of invisible mismatches as long as this hack persisted...
|
|
As suspected a morph mask issue. Apparently we were setting success to false
if the user specifies a pant or shrit texture without an alpha channel.
Result: bad morph masks.
Patch begins to clean up the isMorphMaskValid issue, as well as fixing this
error.
Code reviewed by Vir
|
|
|
|
Oh well, this should still be better.
|
|
|
|
I've added a hyperlink to the "You just entered a region using a
different server version" notification. Users can click over this link
to view the release notes for that server version.
This notification recently started turning up in the local chat log,
so the above solution works in that case as well as if it remained as
a popup notification panel.
|
|
|
|
--HG--
branch : texture-pipeline
|
|
|
|
Apparently, pre-login notifications use LLAlertDialog, but post-login
notifications use LLToastAlertPanel. The latter is basically a copy
and paste of the former, with some local modifications. However, the
person who copy/pasted the code did not initialize the URLLoader
callback, so all notifications that tried to open a web page on a
button click after login were failing.
I've added comments that this code should be refactored, preferably as
a subclass of LLAlertDialog. In the meantime, I've tried to clean it
up a bit by not duplicating the nested URLLoader class (which would've
required further duplication to reimplement the exact same loader class
that LLAlertDialog uses). This let me then initialize the URLLoader
callback for LLToastAlertPanel, to fix this specific bug.
Again... arghhh!!
|
|
min->llmin, max->llmax
|
|
|
|
Reviewed by Mani
|
|
|
|
New attribute header_image_expanded supplies background image.
Reviewed with Leyla (last commit too)
|
|
EXT-2276 Advanced water settings floater sliders spaced too tight
|
|
When the amount of the texture that's being drawn by the plugin shrinks in either width or height, reallocate the texture (which clears it).
|
|
configured in XUI XML
Font and color can be set in accordion_tab.xml
|
|
|
|
|
|
|
|
|
|
Media focus is still tracked separately from LLSelectMgr (which was a change made during a refactor a while ago), but LLViewerMediaFocus now keeps LLSelectMgr updated with the current media focus when it changes.
Added a special case for media focus to LLSelectMgr::deselectAllIfTooFar(), since it was making the focus ring not show up when media focus was on distant media.
|
|
Otherwise it discards a typed line in progress.
|
|
|
|
Normally LL_ERRS in a developer build of the viewer pops up an OS message box
with the text of the LL_ERRS log message, requiring user intervention to
proceed. This isn't good for unattended testing, especially on Parabuild
machines. Running the viewer with '--set QAModeTermCode n' for some
0 < n < 256 will, on LL_ERRS, cause the viewer to terminate immediately with
_exit(n).
|
|
|
|
See Communications Spec for design. Arrow keys still move you if text chat field
is empty. Also fixed ctrl-up/ctrl-down for recently chatted lines.
Reviewed with Richard.
|
|
|
|
|
|
reviewed by James
|
|
|
|
|
|
texture and color picker cleanup
|
|
|
|
http://jira.secondlife.com/browse/EXT-2138
|
|
|
|
|
|
working)
--HG--
branch : product-engine
|
|
|
|
|
|
http://jira.secondlife.com/browse/EXT-2172
|
|
|
|
items) on Sell Land floater
|
|
navigate/interact or controls "permission"
Review #27
Back when media controls (an unfortunately much-overloaded word) was called media permission (also an overloaded word), we granted "permission" for interact/navigate or controls "display" if the requestor agent had modify permissions. This decision doesn't seem to make sense, because it is a common use case to want to "disable" controls (or perhaps interaction/navigate) even for the user who created the object (i.e. who has modify permissions). This removes that check.
NOTE that this check is also made on the server, but in that case modify permissions *grants* the right to navigate in that case. Although the code is very similar, the viewer version is trying to address a use case story, whereas the other is trying to prevent a griefing vector.
|
