Re: [opensource-dev] Review Request: As a music fan, I want audio to fade in gently so my immersion is increased

2011-12-05 Thread Jonathan Yap 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/520/
---

(Updated Dec. 5, 2011, 2:07 a.m.)


Review request for Viewer.


Changes
---

Made changes per code review requests:

Took care of case where division by zero is possible
Removed early returns
Music does not play when the teleport progress bar is displayed

Also made a change so that the fade in timer during login is reset until 
STATE_STARTED is reached.  This helps fix not hearing a full fade in during 
login.


Description
---

Audio fading in has been added for when a music stream starts.  Audio fading 
out has been added for when there is a change in the music stream that is 
playing.

Two dead files have been eliminated.

An existing bug in how music was not being paused correctly has been fixed.

When you are teleporting you will hear the music stream from the place you are 
leaving.  This is a change in behavior; previously the music stream was stopped 
when the teleport progress bar was being displayed.

This code change affects several areas where music is started or stopped.  The 
new code has evolved significantly, so please look for things that might not 
"make sense."


This addresses bug STORM-591.
http://jira.secondlife.com/browse/STORM-591


Diffs (updated)
-

  doc/contributions.txt 8b455c1b7a5e 
  indra/newview/lloverlaybar.h 8b455c1b7a5e 
  indra/newview/lloverlaybar.cpp 8b455c1b7a5e 
  indra/newview/llpanelnearbymedia.h 8b455c1b7a5e 
  indra/newview/llpanelnearbymedia.cpp 8b455c1b7a5e 
  indra/newview/llvieweraudio.h 8b455c1b7a5e 
  indra/newview/llvieweraudio.cpp 8b455c1b7a5e 
  indra/newview/llviewermedia.cpp 8b455c1b7a5e 
  indra/newview/llviewerparcelmgr.cpp 8b455c1b7a5e 

Diff: http://codereview.secondlife.com/r/520/diff/diff


Testing
---

See the massive test plan in the jira.


Thanks,

Jonathan Yap

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Linden Lab's Google Calendars issue

2011-12-05 Thread Ricky 
It seems that as of some point in the last few months the publicly
exported Google Calendars from Linden Labs has been set to "Anyone
can: See only free/busy (hide details)" - meaning no-one out here can
actually know what's going on in the little blue boxes.  Here's one
that's exported on the wiki:
https://wiki.secondlife.com/wiki/Linden_Lab_Official:User_Groups#Calendar

Ricky
Cron Stardust
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-1713: Mouse pointer flickers when hovering over any active/clickable UI item

2011-12-05 Thread Oz Linden 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/521/
---

(Updated Dec. 5, 2011, 9:20 a.m.)


Review request for Viewer and Richard Nelson.


Changes
---

Richard - this has passed QA (it works), but I'd like your review please


Description
---

The fix for the flickering mouse cursor consists of 2 parts:

The first part changes LLView::childrenHandleHover() so that the cursor is only 
set if the control itself is blocking the mouse event and not at every 
hierarchy level in the control hierarchy. If the cursor would be set at each 
level, it would cause a flicker in case the different controls set a different 
cursor. This change actually resembles the algorithm used prior the start of 
the flickering.

The second part changes LLToolTip::handleHover() and specifically handles 
flickering of the cursor while hovering over the "i"-button of a hovertip. The 
general call to LLPanel::handleHover() was changed to be only called if the 
tooltip itself does not set the cursor itself. Logging the calls to 
LLWindowWin32::setCursor() revealed that if the "i"-button on a hovertop is 
hovered with the cursor said method is called twice with different cursors 
alternatively. Checking the call stack further revealed that one call is coming 
from LLToolTip::handleHover() and the other one from LLButton::handleHover(). 
Latter gets invoked if LLPanel::handleHover() is called. Since nothing is 
really done here except setting the cursor to UI_CURSOR_ARROW only ti get then 
set to UI_CURSOR_HAND if LLPanel::handleHover() returns, it doesn't make sense 
to do invoke that method unless the cursor is not changed in the tooltip 
itself. So LLPanel::handleHover() is only invoked if the tooltip does not set 
the cursor itself, so that child controls should take care.


This addresses bug STORM-1713.
http://jira.secondlife.com/browse/STORM-1713


Diffs
-

  doc/contributions.txt a4a5d827c7f5 
  indra/llui/lltooltip.cpp a4a5d827c7f5 
  indra/llui/llview.cpp a4a5d827c7f5 

Diff: http://codereview.secondlife.com/r/521/diff/diff


Testing
---

Testing was done by myself on Firestorm rev. 24073 
(http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/bcc95de39ca9) on 
Windows 7 and Lance Corrimal on Dolphin Viewer. Apparently the fix works 
without any side-effects


Thanks,

Ansariel Hiller

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-1713: Mouse pointer flickers when hovering over any active/clickable UI item

2011-12-05 Thread Richard Nelson 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/521/#review1108
---


Please do not associate the ability to set the mouse cursor with the fact that 
a view is mouse_opaque.  Mouse_opaque, a.k.a. blockMouseEvent is used as a 
shortcut that could easily be replaced by some complicated logic that always 
returns true.  It does not indicate the desire to update the mouse cursor.  The 
rule we use for mutating side effects (i.e. setting tooltip, changing mouse 
cursor, etc.) is that by default the leafmost view wins.  In this case, the 
proper fix is to store the current mouse cursor in your LLWindow* 
implementation and then only set it once a frame in LLWindow*::gatherInput()

- Richard Nelson


On Dec. 5, 2011, 9:20 a.m., Ansariel Hiller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/521/
> ---
> 
> (Updated Dec. 5, 2011, 9:20 a.m.)
> 
> 
> Review request for Viewer and Richard Nelson.
> 
> 
> Description
> ---
> 
> The fix for the flickering mouse cursor consists of 2 parts:
> 
> The first part changes LLView::childrenHandleHover() so that the cursor is 
> only set if the control itself is blocking the mouse event and not at every 
> hierarchy level in the control hierarchy. If the cursor would be set at each 
> level, it would cause a flicker in case the different controls set a 
> different cursor. This change actually resembles the algorithm used prior the 
> start of the flickering.
> 
> The second part changes LLToolTip::handleHover() and specifically handles 
> flickering of the cursor while hovering over the "i"-button of a hovertip. 
> The general call to LLPanel::handleHover() was changed to be only called if 
> the tooltip itself does not set the cursor itself. Logging the calls to 
> LLWindowWin32::setCursor() revealed that if the "i"-button on a hovertop is 
> hovered with the cursor said method is called twice with different cursors 
> alternatively. Checking the call stack further revealed that one call is 
> coming from LLToolTip::handleHover() and the other one from 
> LLButton::handleHover(). Latter gets invoked if LLPanel::handleHover() is 
> called. Since nothing is really done here except setting the cursor to 
> UI_CURSOR_ARROW only ti get then set to UI_CURSOR_HAND if 
> LLPanel::handleHover() returns, it doesn't make sense to do invoke that 
> method unless the cursor is not changed in the tooltip itself. So 
> LLPanel::handleHover() is only invoked if the tooltip does not set the cursor 
> itself, so that child controls should take care.
> 
> 
> This addresses bug STORM-1713.
> http://jira.secondlife.com/browse/STORM-1713
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt a4a5d827c7f5 
>   indra/llui/lltooltip.cpp a4a5d827c7f5 
>   indra/llui/llview.cpp a4a5d827c7f5 
> 
> Diff: http://codereview.secondlife.com/r/521/diff/diff
> 
> 
> Testing
> ---
> 
> Testing was done by myself on Firestorm rev. 24073 
> (http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/bcc95de39ca9) on 
> Windows 7 and Lance Corrimal on Dolphin Viewer. Apparently the fix works 
> without any side-effects
> 
> 
> Thanks,
> 
> Ansariel Hiller
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Linden Lab's Google Calendars issue

2011-12-05 Thread Kadah 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I noticed this too, it was within the last couple weeks.

On 12/5/2011 9:09 AM, Ricky wrote:
> It seems that as of some point in the last few months the publicly 
> exported Google Calendars from Linden Labs has been set to "Anyone 
> can: See only free/busy (hide details)" - meaning no-one out here
> can actually know what's going on in the little blue boxes.  Here's
> one that's exported on the wiki: 
> https://wiki.secondlife.com/wiki/Linden_Lab_Official:User_Groups#Calendar
>
>  Ricky Cron Stardust 
> ___ Policies and
> (un)subscribe information available here: 
> http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the
> policies before posting to keep unmoderated posting privileges
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO3RtLAAoJEIdLfPRu7qE2OgoIAMt9U30AvLm67KyzAVFFyFzf
mtxq6LDPlvPLwplQWbnFUGPrjkBrQ6wknNBjJ9myWCJh+4BeZc3O2CnFxz3hen4I
S/y9LXW10ytX2+xGUcn74K2g8V4zjq73EO0s/Jn3HZZVhZ0v/R5r5N5zNnTbzh0F
BllKMXpB4vt7OrudLcsipHXvKw25pLq37YOGm8KnlydIxA/XZqNdmeTTNTtr+N3q
p14lpT/CYEZ2G3/iE5PRcqlTp8qAoq83Zy4g6dCeqf5GFfTCqAtr9o4Wq+6aB8kl
x3Z3GkYRkLk338ELOKx6C/6P9A3v/Hy3l9AxW5hXqNhRIBjK8KPiEJSx/vuosQw=
=LPXV
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-1713: Mouse pointer flickers when hovering over any active/clickable UI item

2011-12-05 Thread Richard Nelson 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/521/#review1110
---



indra/llui/lltooltip.cpp


let's keep the old code and make the cursor something that is set many 
times, but only propagated to the OS once per frame, like in gatherInput() or 
LLViewerWindow::draw();





indra/llui/llview.cpp


I know this is reverting to older behavior, but the older behavior is wrong 
in tying the ability to set cursors to the mouse_opaque attribute.  


- Richard Nelson


On Dec. 5, 2011, 9:20 a.m., Ansariel Hiller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/521/
> ---
> 
> (Updated Dec. 5, 2011, 9:20 a.m.)
> 
> 
> Review request for Viewer and Richard Nelson.
> 
> 
> Description
> ---
> 
> The fix for the flickering mouse cursor consists of 2 parts:
> 
> The first part changes LLView::childrenHandleHover() so that the cursor is 
> only set if the control itself is blocking the mouse event and not at every 
> hierarchy level in the control hierarchy. If the cursor would be set at each 
> level, it would cause a flicker in case the different controls set a 
> different cursor. This change actually resembles the algorithm used prior the 
> start of the flickering.
> 
> The second part changes LLToolTip::handleHover() and specifically handles 
> flickering of the cursor while hovering over the "i"-button of a hovertip. 
> The general call to LLPanel::handleHover() was changed to be only called if 
> the tooltip itself does not set the cursor itself. Logging the calls to 
> LLWindowWin32::setCursor() revealed that if the "i"-button on a hovertop is 
> hovered with the cursor said method is called twice with different cursors 
> alternatively. Checking the call stack further revealed that one call is 
> coming from LLToolTip::handleHover() and the other one from 
> LLButton::handleHover(). Latter gets invoked if LLPanel::handleHover() is 
> called. Since nothing is really done here except setting the cursor to 
> UI_CURSOR_ARROW only ti get then set to UI_CURSOR_HAND if 
> LLPanel::handleHover() returns, it doesn't make sense to do invoke that 
> method unless the cursor is not changed in the tooltip itself. So 
> LLPanel::handleHover() is only invoked if the tooltip does not set the cursor 
> itself, so that child controls should take care.
> 
> 
> This addresses bug STORM-1713.
> http://jira.secondlife.com/browse/STORM-1713
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt a4a5d827c7f5 
>   indra/llui/lltooltip.cpp a4a5d827c7f5 
>   indra/llui/llview.cpp a4a5d827c7f5 
> 
> Diff: http://codereview.secondlife.com/r/521/diff/diff
> 
> 
> Testing
> ---
> 
> Testing was done by myself on Firestorm rev. 24073 
> (http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/bcc95de39ca9) on 
> Windows 7 and Lance Corrimal on Dolphin Viewer. Apparently the fix works 
> without any side-effects
> 
> 
> Thanks,
> 
> Ansariel Hiller
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-1713: Mouse pointer flickers when hovering over any active/clickable UI item

2011-12-05 Thread Richard Nelson 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/521/#review1114
---

Ship it!


I approve, thanks!  I'm guessing we will end up testing this on all 3 platforms 
during the merge process, so hopefully all goes well.

- Richard Nelson


On Dec. 5, 2011, 2:43 p.m., Ansariel Hiller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/521/
> ---
> 
> (Updated Dec. 5, 2011, 2:43 p.m.)
> 
> 
> Review request for Viewer and Richard Nelson.
> 
> 
> Description
> ---
> 
> The fix for the flickering mouse cursor consists of 2 parts:
> 
> The first part changes LLView::childrenHandleHover() so that the cursor is 
> only set if the control itself is blocking the mouse event and not at every 
> hierarchy level in the control hierarchy. If the cursor would be set at each 
> level, it would cause a flicker in case the different controls set a 
> different cursor. This change actually resembles the algorithm used prior the 
> start of the flickering.
> 
> The second part changes LLToolTip::handleHover() and specifically handles 
> flickering of the cursor while hovering over the "i"-button of a hovertip. 
> The general call to LLPanel::handleHover() was changed to be only called if 
> the tooltip itself does not set the cursor itself. Logging the calls to 
> LLWindowWin32::setCursor() revealed that if the "i"-button on a hovertop is 
> hovered with the cursor said method is called twice with different cursors 
> alternatively. Checking the call stack further revealed that one call is 
> coming from LLToolTip::handleHover() and the other one from 
> LLButton::handleHover(). Latter gets invoked if LLPanel::handleHover() is 
> called. Since nothing is really done here except setting the cursor to 
> UI_CURSOR_ARROW only ti get then set to UI_CURSOR_HAND if 
> LLPanel::handleHover() returns, it doesn't make sense to do invoke that 
> method unless the cursor is not changed in the tooltip itself. So 
> LLPanel::handleHover() is only invoked if the tooltip does not set the cursor 
> itself, so that child controls should take care.
> 
> 
> This addresses bug STORM-1713.
> http://jira.secondlife.com/browse/STORM-1713
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt a984f7ffeb4b 
>   indra/llwindow/llwindow.h a984f7ffeb4b 
>   indra/llwindow/llwindow.cpp a984f7ffeb4b 
>   indra/llwindow/llwindowheadless.h a984f7ffeb4b 
>   indra/llwindow/llwindowmacosx.h a984f7ffeb4b 
>   indra/llwindow/llwindowmacosx.cpp a984f7ffeb4b 
>   indra/llwindow/llwindowmesaheadless.h a984f7ffeb4b 
>   indra/llwindow/llwindowsdl.h a984f7ffeb4b 
>   indra/llwindow/llwindowsdl.cpp a984f7ffeb4b 
>   indra/llwindow/llwindowwin32.h a984f7ffeb4b 
>   indra/llwindow/llwindowwin32.cpp a984f7ffeb4b 
> 
> Diff: http://codereview.secondlife.com/r/521/diff/diff
> 
> 
> Testing
> ---
> 
> Testing was done by myself on Firestorm rev. 24073 
> (http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/bcc95de39ca9) on 
> Windows 7 and Lance Corrimal on Dolphin Viewer. Apparently the fix works 
> without any side-effects
> 
> 
> Thanks,
> 
> Ansariel Hiller
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Review Request: VWR-17587: Added "Fly/Land on holding up/down" option under Move preferences

2011-12-05 Thread Kadah Coba 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/523/
---

Review request for Viewer.


Description
---

Quick patch to add back the long missing AutomaticFly aka "Fly/Land on holding 
up/down". The setting still existed but only has a debug setting with no 
exposure under preferences. This change only added a check box for it under 
Move preferences.

Repo: https://bitbucket.org/Kadah_Coba/vwr-17587
Changeset: https://bitbucket.org/Kadah_Coba/vwr-17587/changeset/2e717f07efbe


This addresses bug VWR-17587.
http://jira.secondlife.com/browse/VWR-17587


Diffs
-

  indra/newview/skins/default/xui/en/panel_preferences_move.xml a984f7ffeb4b 

Diff: http://codereview.secondlife.com/r/523/diff/diff


Testing
---

Patch was tested on Second Life 3.2.4.245931 and is diff against 3.2.5.


Thanks,

Kadah Coba

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges