From lee.ponzu at gmail.com Thu Dec 1 07:51:33 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Thu, 1 Dec 2011 07:51:33 -0800 Subject: [opensource-dev] Should these be Jira'd? Message-ID: Viewer startup blindness What happens: Worst in a dark room. Start the viewer. White screen, ouch it hurts my eyes, but then it goes black. Then it is WHITE again. Damn. Finally, stuff starts to appear, but there is still a lot of WHITE. What should happen: Not sure. UX experts must know. But maybe start black and stay black where possible, or at least some subdued shade. Dark in a bright room is not so bad. Bright in a dark room is a killer. Hiding controls On my Mac, command-shift-U hides the user interface controls. It also zoomz in, which is distracting and also defeats the purpose of making more screen visible. What I expect. Controls disappear, nothing else changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111201/353e7971/attachment.htm From lee.ponzu at gmail.com Thu Dec 1 07:55:03 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Thu, 1 Dec 2011 07:55:03 -0800 Subject: [opensource-dev] Review Request: As a music fan, I want audio to fade in gently so my immersion is increased In-Reply-To: <20111123135929.26657.21835@domU-12-31-38-00-90-68.compute-1.internal> References: <20111123135929.26657.21835@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: An audio glitch I hate... Listening music in SL, I often turn the SL volume down quite a bit. When I exit SL, the music stream continues for a few seconds as SL closes, but AT FULL VOLUME. it wakes up the dog. Ponzu On Wed, Nov 23, 2011 at 5:59 AM, Jonathan Yap wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/520/ > Review request for Viewer. > By Jonathan Yap. > 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." > > Testing > > See the massive test plan in the jira. > > *Bugs: * STORM-591 > Diffs > > - 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) > > View Diff > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111201/deeca324/attachment.htm From oz at lindenlab.com Thu Dec 1 08:52:25 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 01 Dec 2011 11:52:25 -0500 Subject: [opensource-dev] Should these be Jira'd? In-Reply-To: References: Message-ID: <4ED7B0C9.8050502@lindenlab.com> On 2011-12-01 10:51, Lee ponzu wrote: > Viewer startup blindness > > What happens: Worst in a dark room. Start the viewer. White screen, > ouch it hurts my eyes, but then it goes black. Then it is WHITE > again. Damn. Finally, stuff starts to appear, but there is still a > lot of WHITE. > > What should happen: Not sure. UX experts must know. But maybe start > black and stay black where possible, or at least some subdued shade. > Dark in a bright room is not so bad. Bright in a dark room is a killer. I can't see this becoming a high priority item, but submit away. I suggest that you not use the term 'blindness'. > Hiding controls > > On my Mac, command-shift-U hides the user interface controls. It also > zoomz in, which is distracting and also defeats the purpose of making > more screen visible. > > What I expect. Controls disappear, nothing else changes. I have not used that feature much, but I agree that the current behavior isn't right, so create the issue. From oz at lindenlab.com Thu Dec 1 08:53:50 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 01 Dec 2011 11:53:50 -0500 Subject: [opensource-dev] codereview site upgraded Message-ID: <4ED7B11E.7030107@lindenlab.com> I've upgraded codereview.secondlife.com to version 1.6.3 of ReviewBoard. Let me know if this causes any problems... From oz at lindenlab.com Thu Dec 1 10:20:45 2011 From: oz at lindenlab.com (Oz Linden) Date: Thu, 01 Dec 2011 18:20:45 -0000 Subject: [opensource-dev] Review Request: storm-1686: add the "Neck" and "Avatar Center" attach points to the Torso choices in context menus Message-ID: <20111201182045.9985.87818@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/522/ ----------------------------------------------------------- Review request for Viewer. Description ------- The original change for adding these new points put them in a new group, which was then not also implemented in the code. The simplest way to add them to the context menus (both when right clicking on either the avatar or an in-world object) is to put them in the Torso group. This addresses bug storm-1686. http://jira.secondlife.com/browse/storm-1686 Diffs ----- indra/newview/character/avatar_lad.xml a984f7ffeb4b Diff: http://codereview.secondlife.com/r/522/diff/diff Testing ------- Put things on and took them off again using the context menus. Thanks, Oz Linden -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111201/d60a3f47/attachment.htm From sllists at boroon.dasgupta.ch Thu Dec 1 13:00:39 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 01 Dec 2011 21:00:39 -0000 Subject: [opensource-dev] Review Request: storm-1686: add the "Neck" and "Avatar Center" attach points to the Torso choices in context menus In-Reply-To: <20111201182045.9985.87818@domU-12-31-38-00-90-68.compute-1.internal> References: <20111201182045.9985.87818@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111201210039.9987.99224@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/522/#review1103 ----------------------------------------------------------- Ship it! The torso group makes semantically sense for these two new points, anyway, I think. - Boroondas Gupte On Dec. 1, 2011, 10:20 a.m., Oz Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/522/ > ----------------------------------------------------------- > > (Updated Dec. 1, 2011, 10:20 a.m.) > > > Review request for Viewer. > > > Description > ------- > > The original change for adding these new points put them in a new group, which was then not also implemented in the code. The simplest way to add them to the context menus (both when right clicking on either the avatar or an in-world object) is to put them in the Torso group. > > > This addresses bug storm-1686. > http://jira.secondlife.com/browse/storm-1686 > > > Diffs > ----- > > indra/newview/character/avatar_lad.xml a984f7ffeb4b > > Diff: http://codereview.secondlife.com/r/522/diff/diff > > > Testing > ------- > > Put things on and took them off again using the context menus. > > > Thanks, > > Oz Linden > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111201/d8a23e96/attachment.htm From callum at lindenlab.com Thu Dec 1 15:58:03 2011 From: callum at lindenlab.com (Callum Prentice) Date: Thu, 01 Dec 2011 23:58:03 -0000 Subject: [opensource-dev] Review Request: As a music fan, I want audio to fade in gently so my immersion is increased In-Reply-To: <20111123135929.26657.21835@domU-12-31-38-00-90-68.compute-1.internal> References: <20111123135929.26657.21835@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111201235803.10172.38399@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/520/#review1104 ----------------------------------------------------------- Ship it! Looks good. Nice job overall bringing the pieces together and excellent test plan. indra/newview/llvieweraudio.cpp Minor point - maybe a warning where you define the fade in/out times that they should not be zero, even for testing. - Callum Prentice On Nov. 23, 2011, 5:59 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/520/ > ----------------------------------------------------------- > > (Updated Nov. 23, 2011, 5:59 a.m.) > > > Review request for Viewer. > > > 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 > ----- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111201/03935d2f/attachment.htm From callum at lindenlab.com Thu Dec 1 16:03:53 2011 From: callum at lindenlab.com (Callum Prentice) Date: Fri, 02 Dec 2011 00:03:53 -0000 Subject: [opensource-dev] Review Request: As a music fan, I want audio to fade in gently so my immersion is increased In-Reply-To: <20111123135929.26657.21835@domU-12-31-38-00-90-68.compute-1.internal> References: <20111123135929.26657.21835@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111202000353.9985.339@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/520/#review1105 ----------------------------------------------------------- Ship it! Ship It! - Callum Prentice On Nov. 23, 2011, 5:59 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/520/ > ----------------------------------------------------------- > > (Updated Nov. 23, 2011, 5:59 a.m.) > > > Review request for Viewer. > > > 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 > ----- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111202/95eff7eb/attachment.htm From jhwelch at gmail.com Fri Dec 2 02:36:24 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 02 Dec 2011 10:36:24 -0000 Subject: [opensource-dev] Review Request: As a music fan, I want audio to fade in gently so my immersion is increased In-Reply-To: <20111201235803.10172.38399@domU-12-31-38-00-90-68.compute-1.internal> References: <20111201235803.10172.38399@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111202103624.10292.9611@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 1, 2011, 3:58 p.m., Callum Prentice wrote: > > indra/newview/llvieweraudio.cpp, line 213 > > > > > > Minor point - maybe a warning where you define the fade in/out times that they should not be zero, even for testing. Good catch! In code that is now removed I was not letting this value go below zero. I've added a bit of code to prevent it from dropping below 0.01 as a preventative measure against future changes or TPVs who pick this up and add back the two debug settings. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/520/#review1104 ----------------------------------------------------------- On Nov. 23, 2011, 5:59 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/520/ > ----------------------------------------------------------- > > (Updated Nov. 23, 2011, 5:59 a.m.) > > > Review request for Viewer. > > > 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 > ----- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111202/9fe3d094/attachment-0001.htm From soft at lindenlab.com Fri Dec 2 03:16:30 2011 From: soft at lindenlab.com (Brian McGroarty) Date: Fri, 2 Dec 2011 03:16:30 -0800 Subject: [opensource-dev] Anyone played with the Mac Network Link Conditioner? Message-ID: In a former life as a game developer, we'd run networked games through a Linux box, configured to simulate various forms of network degradation. It was a nuisance to set up, but it always turned up some opportunities for small changes that improved players' experiences. An ex-Linden pointed out this tool for OS X, which accomplishes the same thing without a separate machine, and which is very simple to use. I didn't know about, and I don't know if our QA guys use something similar. Has anyone on this list seen and played with it? http://mattgemmell.com/2011/07/25/network-link-conditioner-in-lion/ http://osxdaily.com/2011/08/10/simulate-internet-connectivity-bandwidth-speeds-network-link-conditioner/ We don't officially support wifi networks. But if anyone turns up something that consistently fails with the lossy wifi profiles, IMHO it's still worth attention. Any failures this would turn up would probably affect overseas users as well. Don't burn any calories trying the Edge or 3G settings, unless it's out of morbid curiosity. :) -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111202/b40963c7/attachment.htm From jhwelch at gmail.com Fri Dec 2 07:52:28 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 02 Dec 2011 15:52:28 -0000 Subject: [opensource-dev] Review Request: As a music fan, I want audio to fade in gently so my immersion is increased In-Reply-To: <20111123153211.26661.89016@domU-12-31-38-00-90-68.compute-1.internal> References: <20111123153211.26661.89016@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111202155228.10050.34423@domU-12-31-38-00-90-68.compute-1.internal> > On Nov. 23, 2011, 7:32 a.m., Oz Linden wrote: > > indra/newview/llpanelnearbymedia.cpp, lines 811-812 > > > > > > Please fix (and in the else below) to match the coding standard; add the braces. > > https://wiki.secondlife.com/wiki/Coding_Standard#Braces Done. > On Nov. 23, 2011, 7:32 a.m., Oz Linden wrote: > > indra/newview/llvieweraudio.cpp, lines 77-106 > > > > > > I think this would be clearer if it were written as a switch statement without the early returns. Done. > On Nov. 23, 2011, 7:32 a.m., Oz Linden wrote: > > indra/newview/llvieweraudio.cpp, line 123 > > > > > > If you add an 'else' here, you can replace all the early returns in this method with assignments to a 'bool fadeIsFinished = false;' variable and return that at the bottom. Done, but not by adding an else. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/520/#review1088 ----------------------------------------------------------- On Nov. 23, 2011, 5:59 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/520/ > ----------------------------------------------------------- > > (Updated Nov. 23, 2011, 5:59 a.m.) > > > Review request for Viewer. > > > 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 > ----- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111202/70e8255d/attachment-0001.htm From jhwelch at gmail.com Fri Dec 2 07:55:44 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 02 Dec 2011 15:55:44 -0000 Subject: [opensource-dev] Review Request: As a music fan, I want audio to fade in gently so my immersion is increased In-Reply-To: <20111123135929.26657.21835@domU-12-31-38-00-90-68.compute-1.internal> References: <20111123135929.26657.21835@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111202155544.9984.78894@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/520/ ----------------------------------------------------------- (Updated Dec. 2, 2011, 7:55 a.m.) Review request for Viewer. Changes ------- New diff based on requested code review changes. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111202/21d8e981/attachment.htm From oz at lindenlab.com Fri Dec 2 11:04:36 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 02 Dec 2011 14:04:36 -0500 Subject: [opensource-dev] LLSingleton class question. In-Reply-To: <20111119234805.396e2df0@laptop> References: <20111119234805.396e2df0@laptop> Message-ID: <4ED92144.4020600@lindenlab.com> On 2011-11-19 23:48, lists.secondlife.com at trap.wereanimal.net wrote: > Hi all. > > In the LLSingleton header, there is a comment: > > // Reference version of getInstance() > // Preferred over getInstance() as it disallows checking for NULL > > My question is, is there a difference between > MyClass::instance()->someFunction(); and > MyClass::getInstance()->someFunction(); ? > > If not, is there a preference of using one over the other? > > Linden Lab viewer code has about 35% ::instance use vs. > 65% ::getInstance use. instance() is preferred, but newer, and we haven't spent the time to convert all existing code. From jhwelch at gmail.com Mon Dec 5 02:07:38 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 05 Dec 2011 10:07:38 -0000 Subject: [opensource-dev] Review Request: As a music fan, I want audio to fade in gently so my immersion is increased In-Reply-To: <20111202155544.9984.78894@domU-12-31-38-00-90-68.compute-1.internal> References: <20111202155544.9984.78894@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111205100738.14775.52642@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111205/d82528b9/attachment.htm From kf6kjg at gmail.com Mon Dec 5 09:09:55 2011 From: kf6kjg at gmail.com (Ricky) Date: Mon, 5 Dec 2011 09:09:55 -0800 Subject: [opensource-dev] Linden Lab's Google Calendars issue Message-ID: 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 From oz at lindenlab.com Mon Dec 5 09:20:42 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 05 Dec 2011 17:20:42 -0000 Subject: [opensource-dev] Review Request: STORM-1713: Mouse pointer flickers when hovering over any active/clickable UI item In-Reply-To: <20111123182210.25300.20097@domU-12-31-38-00-90-68.compute-1.internal> References: <20111123182210.25300.20097@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111205172042.14769.89641@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111205/bfcd029b/attachment.htm From richard at lindenlab.com Mon Dec 5 10:46:05 2011 From: richard at lindenlab.com (Richard Nelson) Date: Mon, 05 Dec 2011 18:46:05 -0000 Subject: [opensource-dev] Review Request: STORM-1713: Mouse pointer flickers when hovering over any active/clickable UI item In-Reply-To: <20111205172042.14769.89641@domU-12-31-38-00-90-68.compute-1.internal> References: <20111205172042.14769.89641@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111205184605.15504.99842@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111205/a60eb2c5/attachment-0001.htm From kadah.coba at gmail.com Mon Dec 5 11:28:11 2011 From: kadah.coba at gmail.com (Kadah) Date: Mon, 05 Dec 2011 11:28:11 -0800 Subject: [opensource-dev] Linden Lab's Google Calendars issue In-Reply-To: References: Message-ID: <4EDD1B4B.8090108@gmail.com> -----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----- From richard at lindenlab.com Mon Dec 5 13:26:15 2011 From: richard at lindenlab.com (Richard Nelson) Date: Mon, 05 Dec 2011 21:26:15 -0000 Subject: [opensource-dev] Review Request: STORM-1713: Mouse pointer flickers when hovering over any active/clickable UI item In-Reply-To: <20111205172042.14769.89641@domU-12-31-38-00-90-68.compute-1.internal> References: <20111205172042.14769.89641@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111205212615.14775.89957@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111205/a9c9ded0/attachment.htm From richard at lindenlab.com Mon Dec 5 14:50:30 2011 From: richard at lindenlab.com (Richard Nelson) Date: Mon, 05 Dec 2011 22:50:30 -0000 Subject: [opensource-dev] Review Request: STORM-1713: Mouse pointer flickers when hovering over any active/clickable UI item In-Reply-To: <20111205224354.14771.4779@domU-12-31-38-00-90-68.compute-1.internal> References: <20111205224354.14771.4779@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111205225030.19329.71504@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111205/a1025614/attachment.htm From kadah.coba at gmail.com Mon Dec 5 15:01:39 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Mon, 05 Dec 2011 23:01:39 -0000 Subject: [opensource-dev] Review Request: VWR-17587: Added "Fly/Land on holding up/down" option under Move preferences Message-ID: <20111205230139.14773.41710@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111205/df9fd26a/attachment-0001.htm From jhwelch at gmail.com Tue Dec 6 08:47:03 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Tue, 06 Dec 2011 16:47:03 -0000 Subject: [opensource-dev] Review Request: STORM-1653 Group notices sent by muted residents are still displayed In-Reply-To: <20111123160538.26660.75261@domU-12-31-38-00-90-68.compute-1.internal> References: <20111123160538.26660.75261@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111206164703.18209.10862@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/508/ ----------------------------------------------------------- (Updated Dec. 6, 2011, 8:47 a.m.) Review request for Viewer. Changes ------- Added affected name to warning message. Description ------- When I mute a resident, group notices from that resident are still being displayed to me. This addresses bug STORM-1653. http://jira.secondlife.com/browse/STORM-1653 Diffs (updated) ----- doc/contributions.txt c42575f2cde8 indra/newview/llviewermessage.cpp c42575f2cde8 Diff: http://codereview.secondlife.com/r/508/diff/diff Testing ------- See test plan in jira. Even with an empty name cache I still get an AgentID back. It is not clear to me if I might not when there is a cache miss and the backend systems servicing the name to ID request are heavily loaded. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111206/f3aa804f/attachment.htm From partners at scifipc.com Tue Dec 6 18:00:47 2011 From: partners at scifipc.com (Science Fiction Computer - SCi-Fi PC) Date: Wed, 7 Dec 2011 12:00:47 +1000 Subject: [opensource-dev] Global Illumination Removed from the Future SL Viewer? In-Reply-To: <4EA80A5A.3000709@lindenlab.com> References: <4EA80A5A.3000709@lindenlab.com> Message-ID: Why is Global Illumination not being included as a feature of future SL viewer releases? Wouldn't such forward looking graphical enhancements (no matter how buggy) help attract forward-looking user interest in the SL platform? Reference Source: https://jira.secondlife.com/browse/SH-2613?focusedCommentId=300703 DMC Jurassic / Zsigmond 'Sci Fi & Science Fiction' regions, Second Life. _______________________________________________ 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 From oz at lindenlab.com Wed Dec 7 08:10:52 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 07 Dec 2011 11:10:52 -0500 Subject: [opensource-dev] Global Illumination Removed from the Future SL Viewer? In-Reply-To: References: <4EA80A5A.3000709@lindenlab.com> Message-ID: <4EDF900C.9040609@lindenlab.com> On 2011-12-06 21:00, Science Fiction Computer - SCi-Fi PC wrote: > Wouldn't such forward looking graphical enhancements (no matter how buggy) > help attract forward-looking user interest in the SL platform? It's not a good idea for us to leave in half-finished features that tempt users to try them and make the viewer less reliable. While we might attract a very small number of enthusiasts who don't care that the viewer crashes, we'll just confuse and alienate a much much larger number of normal users who don't know what it is, don't care, and suffer from the added complexity of the viewer code and consequent instability. The viewer is open source - the enthusiasts are more than welcome (indeed, encouraged) to build bleeding-edge experimental features in third party viewers. I stand ready to advocate for integrating those that prove themselves. (by the way - please don't hijack a thread by replying to an unrelated message when posting to the list) From Ima.Mechanique at blueyonder.co.uk Thu Dec 8 02:45:06 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Thu, 08 Dec 2011 10:45:06 -0000 Subject: [opensource-dev] Review Request: Allow scripts to be saved/loaded to/from files. In-Reply-To: <20111123011710.24390.87222@domU-12-31-38-00-90-68.compute-1.internal> References: <20111123011710.24390.87222@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111208104506.14769.61922@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/516/ ----------------------------------------------------------- (Updated Dec. 8, 2011, 2:45 a.m.) Review request for Viewer. Changes ------- This is, hopefully, the final diff. It brings together the UI additions for Linux, Mac, and Windows. As discussed in IRC and here I've removed the TAB replacement code, as this is wider problem which needs to be addressed separately. Description ------- Changes to allow opened script window to save/load to/from files on the users computer. This addresses bug https://jira.secondlife.com/browse/storm-1708. http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/storm-1708 Diffs (updated) ----- doc/contributions.txt a1319d553db9 indra/llui/lltexteditor.h a1319d553db9 indra/llui/lltexteditor.cpp a1319d553db9 indra/newview/llfilepicker.h a1319d553db9 indra/newview/llfilepicker.cpp a1319d553db9 indra/newview/llfloaternamedesc.h a1319d553db9 indra/newview/llfloaternamedesc.cpp a1319d553db9 indra/newview/llpreviewscript.h a1319d553db9 indra/newview/llpreviewscript.cpp a1319d553db9 indra/newview/llviewerfloaterreg.cpp a1319d553db9 indra/newview/skins/default/xui/en/panel_script_ed.xml a1319d553db9 indra/newview/skins/default/xui/en/strings.xml a1319d553db9 Diff: http://codereview.secondlife.com/r/516/diff/diff Testing ------- Successfully opened and saved scripts from/to local files. Thanks, Ima Mechanique -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111208/26b612a1/attachment.htm From oz at lindenlab.com Thu Dec 8 11:08:01 2011 From: oz at lindenlab.com (Oz Linden) Date: Thu, 08 Dec 2011 19:08:01 -0000 Subject: [opensource-dev] Review Request: Allow scripts to be saved/loaded to/from files. In-Reply-To: <20111208104506.14769.61922@domU-12-31-38-00-90-68.compute-1.internal> References: <20111208104506.14769.61922@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111208190801.14775.74898@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/516/#review1115 ----------------------------------------------------------- Just a few minor comments - looks very good. indra/newview/llfloaternamedesc.cpp for future reference, I'd prefer to see this as if/then/else with only one return, but this instance is so small that I don't feel too strongly about it. indra/newview/llpreviewscript.cpp Don't leave commented-out code in. indra/newview/llpreviewscript.cpp a comment here about why would be good ("user chose Cancel" ?) indra/newview/llpreviewscript.cpp user chose cancel? indra/newview/skins/default/xui/en/strings.xml fix indentation - Oz Linden On Dec. 8, 2011, 2:45 a.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/516/ > ----------------------------------------------------------- > > (Updated Dec. 8, 2011, 2:45 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Changes to allow opened script window to save/load to/from files on the users computer. > > > This addresses bug https://jira.secondlife.com/browse/storm-1708. > http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/storm-1708 > > > Diffs > ----- > > doc/contributions.txt a1319d553db9 > indra/llui/lltexteditor.h a1319d553db9 > indra/llui/lltexteditor.cpp a1319d553db9 > indra/newview/llfilepicker.h a1319d553db9 > indra/newview/llfilepicker.cpp a1319d553db9 > indra/newview/llfloaternamedesc.h a1319d553db9 > indra/newview/llfloaternamedesc.cpp a1319d553db9 > indra/newview/llpreviewscript.h a1319d553db9 > indra/newview/llpreviewscript.cpp a1319d553db9 > indra/newview/llviewerfloaterreg.cpp a1319d553db9 > indra/newview/skins/default/xui/en/panel_script_ed.xml a1319d553db9 > indra/newview/skins/default/xui/en/strings.xml a1319d553db9 > > Diff: http://codereview.secondlife.com/r/516/diff/diff > > > Testing > ------- > > Successfully opened and saved scripts from/to local files. > > > Thanks, > > Ima Mechanique > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111208/c184076f/attachment-0001.htm From oz at lindenlab.com Thu Dec 8 11:09:16 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 08 Dec 2011 14:09:16 -0500 Subject: [opensource-dev] codereview site upgraded In-Reply-To: <4ED7B11E.7030107@lindenlab.com> References: <4ED7B11E.7030107@lindenlab.com> Message-ID: <4EE10B5C.7030607@lindenlab.com> On 2011-12-01 11:53, Oz Linden (Scott Lawrence) wrote: > I've upgraded codereview.secondlife.com to version 1.6.3 of > ReviewBoard. Let me know if this causes any problems... > Incidentally, this version adds a nice feature - issue tracking. When commenting on an issue, the reviewer has the option of checking an 'Open an issue' checkbox: ../../../_images/comment-box.png The review display then provides a list of the open issues, and quick buttons for the author to indicate that they've been dealt with (either 'Fixed' or 'Drop' - using the later should be accompanied by a comment about why it was not fixed). By default, every comment creates an issue, so if as a reviewer you are just adding commentary but don't think that any action is required, then uncheck that box. For the complete docs on this feature see http://www.reviewboard.org/docs/manual/1.6/users/reviews/issue-tracking/#issue-tracking -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111208/f86f1454/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: comment-box.png Type: image/png Size: 6745 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111208/f86f1454/attachment.png From Lance.Corrimal at eregion.de Thu Dec 8 13:09:47 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 08 Dec 2011 21:09:47 -0000 Subject: [opensource-dev] Review Request: STORM-1713: Mouse pointer flickers when hovering over any active/clickable UI item In-Reply-To: <20111205224354.14771.4779@domU-12-31-38-00-90-68.compute-1.internal> References: <20111205224354.14771.4779@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111208210947.14768.32430@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/521/#review1116 ----------------------------------------------------------- I'm finding that in a viewer with the r2 version of this patch the mouse pointer flickers through at least three different states in rapid succeession when you hover it over your opened inventory and your inventory is still loading. I'm pretty sure it didn't do that with the previous version. - Lance Corrimal 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111208/c5746a7d/attachment.htm From Lance.Corrimal at eregion.de Thu Dec 8 13:17:29 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 08 Dec 2011 21:17:29 -0000 Subject: [opensource-dev] Review Request: STORM-1713: Mouse pointer flickers when hovering over any active/clickable UI item In-Reply-To: <20111208210947.14768.32430@domU-12-31-38-00-90-68.compute-1.internal> References: <20111208210947.14768.32430@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111208211729.14769.60953@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 8, 2011, 1:09 p.m., Lance Corrimal wrote: > > I'm finding that in a viewer with the r2 version of this patch the mouse pointer flickers through at least three different states in rapid succeession when you hover it over your opened inventory and your inventory is still loading. > > I'm pretty sure it didn't do that with the previous version. on a viewer with the older patch the mouse pointer flickers too in this situation, but by far not as pronounced. - Lance ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/521/#review1116 ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111208/a9153b2e/attachment.htm From Ima.Mechanique at blueyonder.co.uk Fri Dec 9 01:54:13 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Fri, 09 Dec 2011 09:54:13 -0000 Subject: [opensource-dev] Review Request: Allow scripts to be saved/loaded to/from files. In-Reply-To: <20111208190801.14775.74898@domU-12-31-38-00-90-68.compute-1.internal> References: <20111208190801.14775.74898@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111209095413.18209.99504@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 8, 2011, 11:08 a.m., Oz Linden wrote: > > indra/newview/llpreviewscript.cpp, lines 1111-1120 > > > > > > Don't leave commented-out code in. Damn. I'd already done this as a final clean up pass, then forgot to commit it DOH! - Ima ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/516/#review1115 ----------------------------------------------------------- On Dec. 8, 2011, 2:45 a.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/516/ > ----------------------------------------------------------- > > (Updated Dec. 8, 2011, 2:45 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Changes to allow opened script window to save/load to/from files on the users computer. > > > This addresses bug https://jira.secondlife.com/browse/storm-1708. > http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/storm-1708 > > > Diffs > ----- > > doc/contributions.txt a1319d553db9 > indra/llui/lltexteditor.h a1319d553db9 > indra/llui/lltexteditor.cpp a1319d553db9 > indra/newview/llfilepicker.h a1319d553db9 > indra/newview/llfilepicker.cpp a1319d553db9 > indra/newview/llfloaternamedesc.h a1319d553db9 > indra/newview/llfloaternamedesc.cpp a1319d553db9 > indra/newview/llpreviewscript.h a1319d553db9 > indra/newview/llpreviewscript.cpp a1319d553db9 > indra/newview/llviewerfloaterreg.cpp a1319d553db9 > indra/newview/skins/default/xui/en/panel_script_ed.xml a1319d553db9 > indra/newview/skins/default/xui/en/strings.xml a1319d553db9 > > Diff: http://codereview.secondlife.com/r/516/diff/diff > > > Testing > ------- > > Successfully opened and saved scripts from/to local files. > > > Thanks, > > Ima Mechanique > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111209/afeec273/attachment-0001.htm From Ima.Mechanique at blueyonder.co.uk Fri Dec 9 02:11:16 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Fri, 09 Dec 2011 10:11:16 -0000 Subject: [opensource-dev] Review Request: Allow scripts to be saved/loaded to/from files. In-Reply-To: <20111208190801.14775.74898@domU-12-31-38-00-90-68.compute-1.internal> References: <20111208190801.14775.74898@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111209101116.14846.89116@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 8, 2011, 11:08 a.m., Oz Linden wrote: > > indra/newview/skins/default/xui/en/strings.xml, line 430 > > > > > > fix indentation Unfortunately, I had to fix this manually, as VC10 is not using a tab here as it should. Consequently, on saving my plain text editor removed all the trailing white space, so you have more clean-up than expected ;-) - Ima ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/516/#review1115 ----------------------------------------------------------- On Dec. 8, 2011, 2:45 a.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/516/ > ----------------------------------------------------------- > > (Updated Dec. 8, 2011, 2:45 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Changes to allow opened script window to save/load to/from files on the users computer. > > > This addresses bug https://jira.secondlife.com/browse/storm-1708. > http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/storm-1708 > > > Diffs > ----- > > doc/contributions.txt a1319d553db9 > indra/llui/lltexteditor.h a1319d553db9 > indra/llui/lltexteditor.cpp a1319d553db9 > indra/newview/llfilepicker.h a1319d553db9 > indra/newview/llfilepicker.cpp a1319d553db9 > indra/newview/llfloaternamedesc.h a1319d553db9 > indra/newview/llfloaternamedesc.cpp a1319d553db9 > indra/newview/llpreviewscript.h a1319d553db9 > indra/newview/llpreviewscript.cpp a1319d553db9 > indra/newview/llviewerfloaterreg.cpp a1319d553db9 > indra/newview/skins/default/xui/en/panel_script_ed.xml a1319d553db9 > indra/newview/skins/default/xui/en/strings.xml a1319d553db9 > > Diff: http://codereview.secondlife.com/r/516/diff/diff > > > Testing > ------- > > Successfully opened and saved scripts from/to local files. > > > Thanks, > > Ima Mechanique > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111209/77752b3b/attachment.htm From Ima.Mechanique at blueyonder.co.uk Fri Dec 9 02:12:17 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Fri, 09 Dec 2011 10:12:17 -0000 Subject: [opensource-dev] Review Request: Allow scripts to be saved/loaded to/from files. In-Reply-To: <20111208104506.14769.61922@domU-12-31-38-00-90-68.compute-1.internal> References: <20111208104506.14769.61922@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111209101217.14846.18122@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/516/ ----------------------------------------------------------- (Updated Dec. 9, 2011, 2:12 a.m.) Review request for Viewer. Changes ------- Updated diff to incorporate Oz's comments. Description ------- Changes to allow opened script window to save/load to/from files on the users computer. This addresses bug https://jira.secondlife.com/browse/storm-1708. http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/storm-1708 Diffs (updated) ----- doc/contributions.txt a1319d553db9 indra/llui/lltexteditor.h a1319d553db9 indra/llui/lltexteditor.cpp a1319d553db9 indra/newview/llfilepicker.h a1319d553db9 indra/newview/llfilepicker.cpp a1319d553db9 indra/newview/llfloaternamedesc.h a1319d553db9 indra/newview/llfloaternamedesc.cpp a1319d553db9 indra/newview/llpreviewscript.h a1319d553db9 indra/newview/llpreviewscript.cpp a1319d553db9 indra/newview/llviewerfloaterreg.cpp a1319d553db9 indra/newview/skins/default/xui/en/panel_script_ed.xml a1319d553db9 indra/newview/skins/default/xui/en/strings.xml a1319d553db9 Diff: http://codereview.secondlife.com/r/516/diff/diff Testing ------- Successfully opened and saved scripts from/to local files. Thanks, Ima Mechanique -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111209/cd479599/attachment.htm From oz at lindenlab.com Fri Dec 9 06:13:58 2011 From: oz at lindenlab.com (Oz Linden) Date: Fri, 09 Dec 2011 14:13:58 -0000 Subject: [opensource-dev] Review Request: STORM-1653 Group notices sent by muted residents are still displayed In-Reply-To: <20111206164703.18209.10862@domU-12-31-38-00-90-68.compute-1.internal> References: <20111206164703.18209.10862@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111209141358.19329.13677@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/508/#review1121 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Dec. 6, 2011, 8:47 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/508/ > ----------------------------------------------------------- > > (Updated Dec. 6, 2011, 8:47 a.m.) > > > Review request for Viewer. > > > Description > ------- > > When I mute a resident, group notices from that resident are still being displayed to me. > > > This addresses bug STORM-1653. > http://jira.secondlife.com/browse/STORM-1653 > > > Diffs > ----- > > doc/contributions.txt c42575f2cde8 > indra/newview/llviewermessage.cpp c42575f2cde8 > > Diff: http://codereview.secondlife.com/r/508/diff/diff > > > Testing > ------- > > See test plan in jira. > > Even with an empty name cache I still get an AgentID back. It is not clear to me if I might not when there is a cache miss and the backend systems servicing the name to ID request are heavily loaded. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111209/d66784b8/attachment.htm From robertltux at gmail.com Sat Dec 10 09:57:27 2011 From: robertltux at gmail.com (Robert Martin) Date: Sat, 10 Dec 2011 12:57:27 -0500 Subject: [opensource-dev] "Standard Human Mesh Avatar"??? Message-ID: Does anybody have (and would like to share) a Normal Human Mesh Avatar?? As part of playing with MakeHuman i would like to be able to use it to make Mesh Avatars but i need to sort out the right workflow. things that are currently NOT DOCUMENTED 1 what should be the maximum number of vertexes in the model for it to work 2 how do i go about rigging the avatar?? 3 will the normal 1024X textures work or can they be bigger?? Bu naq v unir gevrq gb Tbbtyr Vg fb WSTV vf abg na nafjre gur jvxv vf svpgvbany (be qbrf abg nafjre gur dhrfgvba) fb EGSZ vf nyfb n abanafjre (fvapr gur xnzn fhgen qbrf abg pbire guvf) {rot13} -- Robert L Martin From moriz.gupte at gmail.com Sat Dec 10 10:18:31 2011 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Sat, 10 Dec 2011 11:18:31 -0700 Subject: [opensource-dev] "Standard Human Mesh Avatar"??? In-Reply-To: References: Message-ID: Hey there may be something here http://blog.machinimatrix.org/avatar-workbench/ On Sat, Dec 10, 2011 at 10:57 AM, Robert Martin wrote: > Does anybody have (and would like to share) a Normal Human Mesh Avatar?? > > As part of playing with MakeHuman i would like to be able to use it to > make Mesh Avatars but i need to sort out the right workflow. > > things that are currently NOT DOCUMENTED > 1 what should be the maximum number of vertexes in the model for it to work > 2 how do i go about rigging the avatar?? > 3 will the normal 1024X textures work or can they be bigger?? > > Bu naq v unir gevrq gb Tbbtyr Vg fb WSTV vf abg na nafjre gur jvxv vf > svpgvbany (be qbrf abg nafjre gur dhrfgvba) fb EGSZ vf nyfb n > abanafjre (fvapr gur xnzn fhgen qbrf abg pbire guvf) {rot13} > > -- > Robert L Martin > _______________________________________________ > 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 > -- 'Consider how the lilies grow. They do not labor or spin.' *Rameshsharma Ramloll* PhD, *Research Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: 208-282-5333 Blog , LinkedIn , Play2Train -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111210/d8fc522f/attachment.htm From robertltux at gmail.com Sat Dec 10 10:34:53 2011 From: robertltux at gmail.com (Robert Martin) Date: Sat, 10 Dec 2011 13:34:53 -0500 Subject: [opensource-dev] "Standard Human Mesh Avatar"??? In-Reply-To: References: Message-ID: On Sat, Dec 10, 2011 at 1:18 PM, Moriz Gupte wrote: > Hey there may be something here > http://blog.machinimatrix.org/avatar-workbench/ > > On Sat, Dec 10, 2011 at 10:57 AM, Robert Martin > wrote: >> >> Does anybody have (and would like to share) a Normal Human Mesh Avatar?? >> >> As part of playing with MakeHuman i would like to be able to use it to >> make Mesh Avatars but i need to sort out the right workflow. >> >> things that are currently NOT DOCUMENTED >> 1 what should be the maximum number of vertexes in the model for it to >> work >> 2 how do i go about rigging the avatar?? >> 3 will the normal 1024X textures work or can they be bigger?? >> >> Bu naq v unir gevrq gb Tbbtyr Vg fb WSTV vf abg na nafjre gur jvxv vf >> svpgvbany (be qbrf abg nafjre gur dhrfgvba) fb EGSZ vf nyfb n >> abanafjre (fvapr gur xnzn fhgen qbrf abg pbire guvf) {rot13} >> >> -- >> Robert L Martin >> >> _______________________________________________ >> 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 > > > > even if the site functioned at all i don't think i has what im looking for -- Robert L Martin From dahliatrimble at gmail.com Sat Dec 10 11:56:21 2011 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sat, 10 Dec 2011 11:56:21 -0800 Subject: [opensource-dev] "Standard Human Mesh Avatar"??? In-Reply-To: References: Message-ID: The MakeHuman mesh is probably far too complex (vertex count) to allow reasonable real-time performance for many users with less than the best graphics cards. There's probably other meshes available on other 3d content sites which are better designed for real-time animation. On Sat, Dec 10, 2011 at 9:57 AM, Robert Martin wrote: > Does anybody have (and would like to share) a Normal Human Mesh Avatar?? > > As part of playing with MakeHuman i would like to be able to use it to > make Mesh Avatars but i need to sort out the right workflow. > > things that are currently NOT DOCUMENTED > 1 what should be the maximum number of vertexes in the model for it to work > 2 how do i go about rigging the avatar?? > 3 will the normal 1024X textures work or can they be bigger?? > > Bu naq v unir gevrq gb Tbbtyr Vg fb WSTV vf abg na nafjre gur jvxv vf > svpgvbany (be qbrf abg nafjre gur dhrfgvba) fb EGSZ vf nyfb n > abanafjre (fvapr gur xnzn fhgen qbrf abg pbire guvf) {rot13} > > -- > Robert L Martin > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111210/c0dc5431/attachment.htm From jhwelch at gmail.com Mon Dec 12 06:00:05 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 12 Dec 2011 14:00:05 -0000 Subject: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool. Message-ID: <20111212140005.5996.56515@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/524/ ----------------------------------------------------------- Review request for Viewer. Description ------- Ad-hoc IMs and voice call sessions are established even though you have muted the initiator. The result is that others in the ad-hoc session start writing back to what is usually some provocative message from the initiator and you end up seeing these messages. It has been reported that many IM tabs are also created sometimes. This addresses bug STORM-1731. http://jira.secondlife.com/browse/STORM-1731 Diffs ----- doc/contributions.txt f9a1f62ac997 indra/newview/llimview.cpp f9a1f62ac997 Diff: http://codereview.secondlife.com/r/524/diff/diff Testing ------- See test plan in jira. Testing Not Done: regression testing to see if these code changes have broken muting for other circumstances. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111212/4b59650a/attachment.htm From jhwelch at gmail.com Mon Dec 12 06:00:19 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 12 Dec 2011 14:00:19 -0000 Subject: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool. In-Reply-To: <20111212140005.5996.56515@domU-12-31-38-00-90-68.compute-1.internal> References: <20111212140005.5996.56515@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111212140019.4944.57434@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/524/ ----------------------------------------------------------- (Updated Dec. 12, 2011, 6 a.m.) Review request for Viewer. Description ------- Ad-hoc IMs and voice call sessions are established even though you have muted the initiator. The result is that others in the ad-hoc session start writing back to what is usually some provocative message from the initiator and you end up seeing these messages. It has been reported that many IM tabs are also created sometimes. This addresses bug STORM-1731. http://jira.secondlife.com/browse/STORM-1731 Diffs ----- doc/contributions.txt f9a1f62ac997 indra/newview/llimview.cpp f9a1f62ac997 Diff: http://codereview.secondlife.com/r/524/diff/diff Testing ------- See test plan in jira. Testing Not Done: regression testing to see if these code changes have broken muting for other circumstances. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111212/6e0b666d/attachment.htm From robertltux at gmail.com Mon Dec 12 06:40:26 2011 From: robertltux at gmail.com (Robert Martin) Date: Mon, 12 Dec 2011 09:40:26 -0500 Subject: [opensource-dev] "Standard Human Mesh Avatar"??? In-Reply-To: References: Message-ID: On Sat, Dec 10, 2011 at 2:56 PM, Dahlia Trimble wrote: > The MakeHuman mesh is probably far too complex (vertex count) to allow > reasonable real-time ?performance for many users with less than the best > graphics cards. There's probably other meshes available on other 3d content > sites which are better designed for real-time animation. the trick with MakeHuman is it can be used to generate multiple meshes it would be understood that it would need to be downsampled (to below XK vertexes) before it could be used on the grid. The big question would be What is the recommended Maximum Vertex count?? (define X please) -- Robert L Martin From oz at lindenlab.com Mon Dec 12 06:42:39 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 12 Dec 2011 14:42:39 -0000 Subject: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool. In-Reply-To: <20111212140019.4944.57434@domU-12-31-38-00-90-68.compute-1.internal> References: <20111212140019.4944.57434@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111212144239.4939.69802@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/524/#review1122 ----------------------------------------------------------- indra/newview/llimview.cpp Warning level should be used for potential code or protocol problems. This would be better at Info level. indra/newview/llimview.cpp Doesn't it make more sense to put the isMuted check in an outer test, and then the more specific additional checks for voice in the inner check? Also, why is isLinden a special case for voice but not for other sessions? indra/newview/llimview.cpp Info level - Oz Linden On Dec. 12, 2011, 6 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/524/ > ----------------------------------------------------------- > > (Updated Dec. 12, 2011, 6 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Ad-hoc IMs and voice call sessions are established even though you have muted the initiator. The result is that others in the ad-hoc session start writing back to what is usually some provocative message from the initiator and you end up seeing these messages. It has been reported that many IM tabs are also created sometimes. > > > This addresses bug STORM-1731. > http://jira.secondlife.com/browse/STORM-1731 > > > Diffs > ----- > > doc/contributions.txt f9a1f62ac997 > indra/newview/llimview.cpp f9a1f62ac997 > > Diff: http://codereview.secondlife.com/r/524/diff/diff > > > Testing > ------- > > See test plan in jira. > > Testing Not Done: regression testing to see if these code changes have broken muting for other circumstances. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111212/05d421bc/attachment-0001.htm From mike.chase at alternatemetaverse.com Mon Dec 12 07:53:45 2011 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Mon, 12 Dec 2011 10:53:45 -0500 Subject: [opensource-dev] "Standard Human Mesh Avatar"??? In-Reply-To: References: Message-ID: <1323705225.2541.11.camel@mdickson-ws> On Mon, 2011-12-12 at 09:40 -0500, Robert Martin wrote: > On Sat, Dec 10, 2011 at 2:56 PM, Dahlia Trimble wrote: > > The MakeHuman mesh is probably far too complex (vertex count) to allow > > reasonable real-time performance for many users with less than the best > > graphics cards. There's probably other meshes available on other 3d content > > sites which are better designed for real-time animation. > > the trick with MakeHuman is it can be used to generate multiple meshes > it would be understood that it would need to be downsampled (to below > XK vertexes) before it could be used on the grid. The big question > would be What is the recommended Maximum Vertex count?? (define X > please) > You could always dump the avatar mesh from the viewer (in the develop menu I believe) and pull it into blender to get an idea of what your dealing with. Mike > > From jhwelch at gmail.com Mon Dec 12 08:21:57 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 12 Dec 2011 16:21:57 -0000 Subject: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool. In-Reply-To: <20111212144239.4939.69802@domU-12-31-38-00-90-68.compute-1.internal> References: <20111212144239.4939.69802@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111212162157.5177.50897@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 12, 2011, 6:42 a.m., Oz Linden wrote: > > indra/newview/llimview.cpp, lines 2730-2744 > > > > > > Doesn't it make more sense to put the isMuted check in an outer test, and then the more specific additional checks for voice in the inner check? > > > > Also, why is isLinden a special case for voice but not for other sessions? > > Having the tests in this order is what is needed. There are two cases here: dealing with a muted session initiator has to take precendence over a muted non-initiator avatar in an existing session. Not having the test for a linden was someone's oversight which I have corrected. There are a few other instances of this check not being performed properly. If you think fixing these now is within the scope of this jira please let me know. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/524/#review1122 ----------------------------------------------------------- On Dec. 12, 2011, 6 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/524/ > ----------------------------------------------------------- > > (Updated Dec. 12, 2011, 6 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Ad-hoc IMs and voice call sessions are established even though you have muted the initiator. The result is that others in the ad-hoc session start writing back to what is usually some provocative message from the initiator and you end up seeing these messages. It has been reported that many IM tabs are also created sometimes. > > > This addresses bug STORM-1731. > http://jira.secondlife.com/browse/STORM-1731 > > > Diffs > ----- > > doc/contributions.txt f9a1f62ac997 > indra/newview/llimview.cpp f9a1f62ac997 > > Diff: http://codereview.secondlife.com/r/524/diff/diff > > > Testing > ------- > > See test plan in jira. > > Testing Not Done: regression testing to see if these code changes have broken muting for other circumstances. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111212/583c7340/attachment.htm From danielravennest at gmail.com Mon Dec 12 09:24:04 2011 From: danielravennest at gmail.com (Daniel) Date: Mon, 12 Dec 2011 11:24:04 -0600 Subject: [opensource-dev] Standard Human Mesh Avatar In-Reply-To: References: Message-ID: <4EE638B4.9000100@gmail.com> There is no single number you can define for all cases. During the mesh beta one Linden staffer noted the mesh cost formulae were made assuming 300K triangles for the entire scene being rendered would allow low end PCs to run at adequate frame rates. Note I said "triangles", which is what graphics cards process, not vertexes. High end machines can handle a lot more. Crytek (designer of the Crysis games) recommends level designers keep to under 3 million triangles per frame, versus whatever PC hardware they recommend for those games. How much work the SL viewer does with each triangle depends on graphics settings, but generally a given hardware will process X triangles per second, and so frame rate will tend to go inversely with scene complexity. The existing default SL avatar is about 8000 triangles, each sculpt map can add 2000, and each prim can add 100 to 2000 or so depending on type. So an avatar wearing a lot of detailed attachments can add up to a lot of theoretical triangles. I say theoretical because the SL viewer applies "Levels of Detail" (LOD) on the theory that objects at longer distance would end up with geometry which is less than one pixel on the monitor. This is unnecessary processing, so the viewer applies simplification of what it renders at various distances. For prims and the standard avatar the LOD levels are built in. For sculpts it discards alternate rows and columns of the map texture, and for mesh you explicitly define the LOD geometry at the time of upload. LOD levels kick in at specified multiples of the object size vs camera distance. So if you design a mesh avatar as a single object, the levels will switch at multiples of the full body size. If you design it as separate body parts, the switches will happen per part, so generally at closer distance. The final consideration is what environment will the avatar be used in. One made for fashion photography, where only one will be in view, and frame rate does not matter, can be a very detailed. One made for SL role playing games, where speed matters, or for visiting popular clubs, where lots of other attachment- heavy avatars will be in view, should stick to lower detail. For the latter cases I would suggest staying under double the default avatar (ie to < 16K triangles), on the assumption that the default avatar when hidden by an alpha texture subtracts 8K from the rendering task, and an extra 8K total is not a large impact given whatever else the avatar has in attachments. Levels of detail by default go down by a factor of 4 per level in the upload window. You are free to upload whatever geometry you want for each level to maintain decent looks for your avatar, but that is a reasonable guideline for how aggressively to simplify each LOD. Message: 3 Date: Mon, 12 Dec 2011 09:40:26 -0500 From: Robert Martin > the trick with MakeHuman is it can be used to generate multiple meshes > it would be understood that it would need to be downsampled (to below > XK vertexes) before it could be used on the grid. The big question > would be What is the recommended Maximum Vertex count?? (define X > please) > From moriz.gupte at gmail.com Mon Dec 12 09:25:11 2011 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Mon, 12 Dec 2011 10:25:11 -0700 Subject: [opensource-dev] "Standard Human Mesh Avatar"??? In-Reply-To: <1323705225.2541.11.camel@mdickson-ws> References: <1323705225.2541.11.camel@mdickson-ws> Message-ID: Or to save some time, get the blender files from the link I provided earlier ... and examine the mesh files in blender R On Mon, Dec 12, 2011 at 8:53 AM, Mike Chase < mike.chase at alternatemetaverse.com> wrote: > On Mon, 2011-12-12 at 09:40 -0500, Robert Martin wrote: > > On Sat, Dec 10, 2011 at 2:56 PM, Dahlia Trimble > wrote: > > > The MakeHuman mesh is probably far too complex (vertex count) to allow > > > reasonable real-time performance for many users with less than the > best > > > graphics cards. There's probably other meshes available on other 3d > content > > > sites which are better designed for real-time animation. > > > > the trick with MakeHuman is it can be used to generate multiple meshes > > it would be understood that it would need to be downsampled (to below > > XK vertexes) before it could be used on the grid. The big question > > would be What is the recommended Maximum Vertex count?? (define X > > please) > > > > You could always dump the avatar mesh from the viewer (in the develop > menu I believe) and pull it into blender to get an idea of what your > dealing with. > > Mike > > > > > > > > _______________________________________________ > 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 > -- 'Consider how the lilies grow. They do not labor or spin.' *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: 208-240-0040 Blog , LinkedIn , DeepSemaphore LLC , Google+ profile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111212/f447c6ad/attachment-0001.htm From mike.chase at alternatemetaverse.com Mon Dec 12 11:07:25 2011 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Mon, 12 Dec 2011 14:07:25 -0500 Subject: [opensource-dev] "Standard Human Mesh Avatar"??? In-Reply-To: References: <1323705225.2541.11.camel@mdickson-ws> Message-ID: <1323716845.2541.12.camel@mdickson-ws> On Mon, 2011-12-12 at 10:25 -0700, Moriz Gupte wrote: > Or to save some time, get the blender files from the link I provided > earlier ... and examine the mesh files in blender > R Yep, Gaia's project is very relevant. It include 2 meshes, the SL one and a Makehuman mesh as well as an SL compatible rig. Mike > > On Mon, Dec 12, 2011 at 8:53 AM, Mike Chase > wrote: > On Mon, 2011-12-12 at 09:40 -0500, Robert Martin wrote: > > On Sat, Dec 10, 2011 at 2:56 PM, Dahlia Trimble > wrote: > > > The MakeHuman mesh is probably far too complex (vertex > count) to allow > > > reasonable real-time performance for many users with less > than the best > > > graphics cards. There's probably other meshes available on > other 3d content > > > sites which are better designed for real-time animation. > > > > the trick with MakeHuman is it can be used to generate > multiple meshes > > it would be understood that it would need to be downsampled > (to below > > XK vertexes) before it could be used on the grid. The big > question > > would be What is the recommended Maximum Vertex count?? > (define X > > please) > > > > > You could always dump the avatar mesh from the viewer (in the > develop > menu I believe) and pull it into blender to get an idea of > what your > dealing with. > > Mike > > > > > > > > _______________________________________________ > 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 > > > > > > -- > 'Consider how the lilies grow. They do not labor or spin.' > Rameshsharma Ramloll PhD, CEO CTO DeepSemaphore LLC, > Affiliate Research Associate Professor, Idaho State University, > Pocatello, ID 83209 Tel: 208-240-0040 > Blog, LinkedIn, DeepSemaphore LLC, Google+ profile > > From oz at lindenlab.com Mon Dec 12 11:11:13 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 12 Dec 2011 19:11:13 -0000 Subject: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool. In-Reply-To: <20111212144239.4939.69802@domU-12-31-38-00-90-68.compute-1.internal> References: <20111212144239.4939.69802@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111212191113.4938.80739@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 12, 2011, 6:42 a.m., Oz Linden wrote: > > indra/newview/llimview.cpp, lines 2730-2744 > > > > > > Doesn't it make more sense to put the isMuted check in an outer test, and then the more specific additional checks for voice in the inner check? > > > > Also, why is isLinden a special case for voice but not for other sessions? > > > > Jonathan Yap wrote: > Having the tests in this order is what is needed. There are two cases here: dealing with a muted session initiator has to take precendence over a muted non-initiator avatar in an existing session. > > Not having the test for a linden was someone's oversight which I have corrected. There are a few other instances of this check not being performed properly. If you think fixing these now is within the scope of this jira please let me know. I'm prepared to believe there's a difference here I don't see, but why isn't this: //ignore invites from muted residents if (LLMuteList::getInstance()->isMuted(caller_id) && !is_linden) { if (voice_invite && "VoiceInviteQuestionDefault" == question_type) { llinfos << "Rejecting voice call from initiating muted resident " << caller_name << llendl; LLIncomingCallDialog::processCallResponse(1, payload); } return; } - Oz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/524/#review1122 ----------------------------------------------------------- On Dec. 12, 2011, 6 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/524/ > ----------------------------------------------------------- > > (Updated Dec. 12, 2011, 6 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Ad-hoc IMs and voice call sessions are established even though you have muted the initiator. The result is that others in the ad-hoc session start writing back to what is usually some provocative message from the initiator and you end up seeing these messages. It has been reported that many IM tabs are also created sometimes. > > > This addresses bug STORM-1731. > http://jira.secondlife.com/browse/STORM-1731 > > > Diffs > ----- > > doc/contributions.txt f9a1f62ac997 > indra/newview/llimview.cpp f9a1f62ac997 > > Diff: http://codereview.secondlife.com/r/524/diff/diff > > > Testing > ------- > > See test plan in jira. > > Testing Not Done: regression testing to see if these code changes have broken muting for other circumstances. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111212/b38e303c/attachment.htm From jhwelch at gmail.com Mon Dec 12 11:35:49 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 12 Dec 2011 19:35:49 -0000 Subject: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool. In-Reply-To: <20111212144239.4939.69802@domU-12-31-38-00-90-68.compute-1.internal> References: <20111212144239.4939.69802@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111212193549.5230.85566@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 12, 2011, 6:42 a.m., Oz Linden wrote: > > indra/newview/llimview.cpp, lines 2730-2744 > > > > > > Doesn't it make more sense to put the isMuted check in an outer test, and then the more specific additional checks for voice in the inner check? > > > > Also, why is isLinden a special case for voice but not for other sessions? > > > > Jonathan Yap wrote: > Having the tests in this order is what is needed. There are two cases here: dealing with a muted session initiator has to take precendence over a muted non-initiator avatar in an existing session. > > Not having the test for a linden was someone's oversight which I have corrected. There are a few other instances of this check not being performed properly. If you think fixing these now is within the scope of this jira please let me know. > > Oz Linden wrote: > I'm prepared to believe there's a difference here I don't see, but why isn't this: > > //ignore invites from muted residents > if (LLMuteList::getInstance()->isMuted(caller_id) && !is_linden) > { > if (voice_invite && "VoiceInviteQuestionDefault" == question_type) > { > llinfos << "Rejecting voice call from initiating muted resident " << caller_name << llendl; > LLIncomingCallDialog::processCallResponse(1, payload); > } > return; > } > I'm sorry, you are totally correct. I was rushing trying to get these changes done quickly so you could have them for your test build and was still thinking of the logic changes I made elsewhere for the non-voice part of this fix. I've adjusted the code per what you have above. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/524/#review1122 ----------------------------------------------------------- On Dec. 12, 2011, 6 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/524/ > ----------------------------------------------------------- > > (Updated Dec. 12, 2011, 6 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Ad-hoc IMs and voice call sessions are established even though you have muted the initiator. The result is that others in the ad-hoc session start writing back to what is usually some provocative message from the initiator and you end up seeing these messages. It has been reported that many IM tabs are also created sometimes. > > > This addresses bug STORM-1731. > http://jira.secondlife.com/browse/STORM-1731 > > > Diffs > ----- > > doc/contributions.txt f9a1f62ac997 > indra/newview/llimview.cpp f9a1f62ac997 > > Diff: http://codereview.secondlife.com/r/524/diff/diff > > > Testing > ------- > > See test plan in jira. > > Testing Not Done: regression testing to see if these code changes have broken muting for other circumstances. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111212/fed875a6/attachment-0001.htm From robertltux at gmail.com Mon Dec 12 11:39:03 2011 From: robertltux at gmail.com (Robert Martin) Date: Mon, 12 Dec 2011 14:39:03 -0500 Subject: [opensource-dev] "Standard Human Mesh Avatar"??? In-Reply-To: <1323716845.2541.12.camel@mdickson-ws> References: <1323705225.2541.11.camel@mdickson-ws> <1323716845.2541.12.camel@mdickson-ws> Message-ID: On Mon, Dec 12, 2011 at 2:07 PM, Mike Chase wrote: > On Mon, 2011-12-12 at 10:25 -0700, Moriz Gupte wrote: >> Or to save some time, get the blender files from the link I provided >> earlier ... and examine the mesh files in blender >> R > > Yep, Gaia's project is very relevant. It include 2 meshes, the SL one > and a Makehuman mesh as well as an SL compatible rig. > okay which would help if I COULD ACCESS THE SITE. Does anybody have a copy on another server?? -- Robert L Martin From jhwelch at gmail.com Mon Dec 12 11:54:55 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 12 Dec 2011 19:54:55 -0000 Subject: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool. In-Reply-To: <20111212140019.4944.57434@domU-12-31-38-00-90-68.compute-1.internal> References: <20111212140019.4944.57434@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111212195455.5998.60362@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/524/ ----------------------------------------------------------- (Updated Dec. 12, 2011, 11:54 a.m.) Review request for Viewer. Changes ------- Updated diff with revised if-muted logic per RB requst. Description ------- Ad-hoc IMs and voice call sessions are established even though you have muted the initiator. The result is that others in the ad-hoc session start writing back to what is usually some provocative message from the initiator and you end up seeing these messages. It has been reported that many IM tabs are also created sometimes. This addresses bug STORM-1731. http://jira.secondlife.com/browse/STORM-1731 Diffs (updated) ----- doc/contributions.txt f9a1f62ac997 indra/newview/llimview.cpp f9a1f62ac997 Diff: http://codereview.secondlife.com/r/524/diff/diff Testing ------- See test plan in jira. Testing Not Done: regression testing to see if these code changes have broken muting for other circumstances. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111212/9f6fe378/attachment.htm From oz at lindenlab.com Tue Dec 13 07:11:12 2011 From: oz at lindenlab.com (Oz Linden) Date: Tue, 13 Dec 2011 15:11:12 -0000 Subject: [opensource-dev] Review Request: storm-1729: leading spaces on cpu identifier Message-ID: <20111213151112.4944.27492@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/525/ ----------------------------------------------------------- Review request for Viewer. Description ------- I really can't figure out where those spaces could have come from, but I stripped them in the low level routine that creates the string This addresses bug storm-1729. http://jira.secondlife.com/browse/storm-1729 Diffs ----- indra/llcommon/llsys.cpp 3f2162768b29 Diff: http://codereview.secondlife.com/r/525/diff/diff Testing ------- Thanks, Oz Linden -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111213/7dd836f6/attachment.htm From oz at lindenlab.com Tue Dec 13 14:05:45 2011 From: oz at lindenlab.com (Oz Linden) Date: Tue, 13 Dec 2011 22:05:45 -0000 Subject: [opensource-dev] Review Request: STORM-1653 Group notices sent by muted residents are still displayed In-Reply-To: <20111206164703.18209.10862@domU-12-31-38-00-90-68.compute-1.internal> References: <20111206164703.18209.10862@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111213220545.5177.46151@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/508/#review1126 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Dec. 6, 2011, 8:47 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/508/ > ----------------------------------------------------------- > > (Updated Dec. 6, 2011, 8:47 a.m.) > > > Review request for Viewer. > > > Description > ------- > > When I mute a resident, group notices from that resident are still being displayed to me. > > > This addresses bug STORM-1653. > http://jira.secondlife.com/browse/STORM-1653 > > > Diffs > ----- > > doc/contributions.txt c42575f2cde8 > indra/newview/llviewermessage.cpp c42575f2cde8 > > Diff: http://codereview.secondlife.com/r/508/diff/diff > > > Testing > ------- > > See test plan in jira. > > Even with an empty name cache I still get an AgentID back. It is not clear to me if I might not when there is a cache miss and the backend systems servicing the name to ID request are heavily loaded. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111213/7d75d80c/attachment.htm From oz at lindenlab.com Wed Dec 14 13:05:46 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 14 Dec 2011 16:05:46 -0500 Subject: [opensource-dev] Doxygen viewer code browsing.... Message-ID: <4EE90FAA.4010307@lindenlab.com> I've put up current viewer-development output from Doxygen at http://lecs.opensource.secondlife.com/doxygen/index.html and put a pointer or two to it on the wiki. For now, this is manually updated (automating that is on my to-do list), but I'll try to keep it reasonably up to date. From jhwelch at gmail.com Sat Dec 17 10:34:28 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Sat, 17 Dec 2011 18:34:28 -0000 Subject: [opensource-dev] Review Request: STORM-653 As a user i would like to be able to see the available number of attachments and remaining free slots. Message-ID: <20111217183428.8434.61110@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/527/ ----------------------------------------------------------- Review request for Viewer. Description ------- This change alters the Attachments accordion title to include the number of attachment slots available. This addresses bug STORM-653. http://jira.secondlife.com/browse/STORM-653 Diffs ----- doc/contributions.txt 34d957a19aa4 indra/newview/llcofwearables.h 34d957a19aa4 indra/newview/llcofwearables.cpp 34d957a19aa4 indra/newview/skins/default/xui/en/panel_cof_wearables.xml 34d957a19aa4 indra/newview/skins/default/xui/en/strings.xml 34d957a19aa4 Diff: http://codereview.secondlife.com/r/527/diff/diff Testing ------- See test plan in jira Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111217/a6e76bae/attachment.htm From jhwelch at gmail.com Sun Dec 18 07:36:23 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Sun, 18 Dec 2011 15:36:23 -0000 Subject: [opensource-dev] Review Request: STORM-1737 panel_edit_skin.xml uses confusing historical terminology Message-ID: <20111218153623.14052.28230@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/528/ ----------------------------------------------------------- Review request for Viewer. Description ------- In the appearance editor / skin editor the three textures are still labeled as "Lower Tattoos", "Head Tattoos" and "Upper Tattoos". Changes to how tattoos are processed has made these names misleading. They should be labeled Head, Upper body, and Lower body. This addresses bug STORM-1737. http://jira.secondlife.com/browse/STORM-1737 Diffs ----- doc/contributions.txt 3f2162768b29 indra/newview/llpaneleditwearable.cpp 3f2162768b29 indra/newview/skins/default/xui/en/panel_edit_skin.xml 3f2162768b29 Diff: http://codereview.secondlife.com/r/528/diff/diff Testing ------- See test plan in jira. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111218/7b996439/attachment.htm From nickyperian at yahoo.com Sun Dec 18 07:49:55 2011 From: nickyperian at yahoo.com (Nicky Perian) Date: Sun, 18 Dec 2011 15:49:55 -0000 Subject: [opensource-dev] Review Request: STORM-1737 panel_edit_skin.xml uses confusing historical terminology In-Reply-To: <20111218153623.14052.28230@domU-12-31-38-00-90-68.compute-1.internal> References: <20111218153623.14052.28230@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111218154955.14086.36036@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/528/#review1128 ----------------------------------------------------------- Ship it! Ship It! - Nicky Perian On Dec. 18, 2011, 7:36 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/528/ > ----------------------------------------------------------- > > (Updated Dec. 18, 2011, 7:36 a.m.) > > > Review request for Viewer. > > > Description > ------- > > In the appearance editor / skin editor the three textures are still labeled as "Lower Tattoos", "Head Tattoos" and "Upper Tattoos". Changes to how tattoos are processed has made these names misleading. They should be labeled Head, Upper body, and Lower body. > > > This addresses bug STORM-1737. > http://jira.secondlife.com/browse/STORM-1737 > > > Diffs > ----- > > doc/contributions.txt 3f2162768b29 > indra/newview/llpaneleditwearable.cpp 3f2162768b29 > indra/newview/skins/default/xui/en/panel_edit_skin.xml 3f2162768b29 > > Diff: http://codereview.secondlife.com/r/528/diff/diff > > > Testing > ------- > > See test plan in jira. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111218/b785d378/attachment.htm From oz at lindenlab.com Mon Dec 19 07:30:42 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 19 Dec 2011 15:30:42 -0000 Subject: [opensource-dev] Review Request: STORM-1737 panel_edit_skin.xml uses confusing historical terminology In-Reply-To: <20111218153623.14052.28230@domU-12-31-38-00-90-68.compute-1.internal> References: <20111218153623.14052.28230@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111219153042.14079.48814@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/528/#review1129 ----------------------------------------------------------- Ship it! Ship It! - Oz Linden On Dec. 18, 2011, 7:36 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/528/ > ----------------------------------------------------------- > > (Updated Dec. 18, 2011, 7:36 a.m.) > > > Review request for Viewer. > > > Description > ------- > > In the appearance editor / skin editor the three textures are still labeled as "Lower Tattoos", "Head Tattoos" and "Upper Tattoos". Changes to how tattoos are processed has made these names misleading. They should be labeled Head, Upper body, and Lower body. > > > This addresses bug STORM-1737. > http://jira.secondlife.com/browse/STORM-1737 > > > Diffs > ----- > > doc/contributions.txt 3f2162768b29 > indra/newview/llpaneleditwearable.cpp 3f2162768b29 > indra/newview/skins/default/xui/en/panel_edit_skin.xml 3f2162768b29 > > Diff: http://codereview.secondlife.com/r/528/diff/diff > > > Testing > ------- > > See test plan in jira. > > > Thanks, > > Jonathan Yap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111219/722366c0/attachment.htm From oz at lindenlab.com Tue Dec 20 07:36:45 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 20 Dec 2011 10:36:45 -0500 Subject: [opensource-dev] Limited availability next week... Message-ID: <4EF0AB8D.4040505@lindenlab.com> We've been given some extra holiday time off between Christmas and New Years, so I will only be occasionally checking in from December 23 through Jan 2: all open source meetings during that time are cancelled. This year has been a good one for open source contributions, and I think that next will be much better. Thank you again for all that you do, and enjoy the holidays. From mike.chase at alternatemetaverse.com Tue Dec 20 08:19:34 2011 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Tue, 20 Dec 2011 11:19:34 -0500 Subject: [opensource-dev] Gstreamer issue.. how to debug? In-Reply-To: <4EF0AB8D.4040505@lindenlab.com> References: <4EF0AB8D.4040505@lindenlab.com> Message-ID: <1324397974.2561.5.camel@mdickson-ws> So this past weekend Fedora pushed out a bunch of updates which I installed. I wish they wouldn't do this but they seem to release stuff in huge batches. Anyway since then SLPlugin fails to play audio streams. Video seems to be ok. Is there any doco on how to debug issues with SLPlugin? I tried running the client with a window open. It *looks* like its starting the stream but nothing. Running the same thing with Singularity I get an error about no HTTP source plugin. If I run gst-launch-0.10 playbin uri=http://96.44.147.34:7078 This works fine. I'm sort of at a loss and miss my streaming music in SL. I'm pretty sure the update broke something but it seems to be localized to SLPlugin (I can play audio streams fine in other apps). I just need a hint on how to narrow down what might be borked. Thanks!! Mike On Tue, 2011-12-20 at 10:36 -0500, Oz Linden (Scott Lawrence) wrote: > We've been given some extra holiday time off between Christmas and New > Years, so I will only be occasionally checking in from December 23 > through Jan 2: all open source meetings during that time are cancelled. > > This year has been a good one for open source contributions, and I think > that next will be much better. Thank you again for all that you do, and > enjoy the holidays. > > _______________________________________________ > 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 From jaeger_Reg at hotmail.com Tue Dec 20 22:49:51 2011 From: jaeger_Reg at hotmail.com (Tankmaster Finesmith) Date: Wed, 21 Dec 2011 06:49:51 -0000 Subject: [opensource-dev] Review Request: STORM-1738 - Add autocorrect macros to text editors Message-ID: <20111221064951.14048.32830@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/529/ ----------------------------------------------------------- Review request for Viewer. Description ------- This patch adds the autocorrect macro functionality found in Firestorm to V3. This addresses bug STORM-1738. http://jira.secondlife.com/browse/STORM-1738 Diffs ----- indra/llui/lllineeditor.h be852d6fb6ed indra/llui/lllineeditor.cpp be852d6fb6ed indra/newview/CMakeLists.txt be852d6fb6ed indra/newview/app_settings/settings.xml be852d6fb6ed indra/newview/app_settings/settings_autocorrect.xml PRE-CREATION indra/newview/llautocorrect.h PRE-CREATION indra/newview/llautocorrect.cpp PRE-CREATION indra/newview/llautocorrectfloater.h PRE-CREATION indra/newview/llautocorrectfloater.cpp PRE-CREATION indra/newview/llfloaterpreference.cpp be852d6fb6ed indra/newview/llviewerfloaterreg.cpp be852d6fb6ed indra/newview/skins/default/xui/en/floater_autocorrect.xml PRE-CREATION indra/newview/skins/default/xui/en/notifications.xml be852d6fb6ed indra/newview/skins/default/xui/en/panel_preferences_chat.xml be852d6fb6ed Diff: http://codereview.secondlife.com/r/529/diff/diff Testing ------- tested floater opening, options to enable/disable, and for words on the autocorrect list to automatically change from the word typed in and outputted the word listed in the settings_autocorrect.xml Thanks, Tankmaster Finesmith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111221/a7a5eda2/attachment.htm From iseki at solar-system.tuis.ac.jp Thu Dec 22 10:17:41 2011 From: iseki at solar-system.tuis.ac.jp (Fumi.Iseki) Date: Fri, 23 Dec 2011 03:17:41 +0900 Subject: [opensource-dev] Real Time Animation with Kinect Message-ID: <4EF37445.3000305@solar-system.tuis.ac.jp> Hi, We are now developing SLKinect2(beta) that sends Animation Data to SecondLife/OpenSim Viewer on network in real-time. It is possible that synchronization of Animation on the network using Animation Relay Server If you interest it, please see http://youtu.be/KhqbGAWqvLI Thanks. >> Hi responders, >> >> Thank you for the attention. >> >> We released the system as open source. >> Please see our wiki, if you are interested. >> http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?SLKinect >> >> Thanks. >> -- Fumikazu Iseki Tokyo Univ. of Info. Sci. mailto:iseki at solar-system.tuis.ac.jp http://www.nsl.tuis.ac.jp/ From moriz.gupte at gmail.com Thu Dec 22 10:38:23 2011 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Thu, 22 Dec 2011 11:38:23 -0700 Subject: [opensource-dev] Real Time Animation with Kinect In-Reply-To: <4EF37445.3000305@solar-system.tuis.ac.jp> References: <4EF37445.3000305@solar-system.tuis.ac.jp> Message-ID: Thanks for sharing. Hopes Linden Lab looks at your work seriously. I am quite impressed by the responsiveness suggested in your demo clip. On Thu, Dec 22, 2011 at 11:17 AM, Fumi.Iseki wrote: > Hi, > > We are now developing SLKinect2(beta) that sends Animation Data to > SecondLife/OpenSim > Viewer on network in real-time. > It is possible that synchronization of Animation on the network using > Animation Relay Server > > If you interest it, please see http://youtu.be/KhqbGAWqvLI > > Thanks. > > > >> Hi responders, > >> > >> Thank you for the attention. > >> > >> We released the system as open source. > >> Please see our wiki, if you are interested. > >> http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?SLKinect > >> > >> Thanks. > >> > > -- > Fumikazu Iseki > Tokyo Univ. of Info. Sci. > mailto:iseki at solar-system.tuis.ac.jp > http://www.nsl.tuis.ac.jp/ > > _______________________________________________ > 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 > -- 'Consider how the lilies grow. They do not labor or spin.' *Rameshsharma Ramloll* PhD, *Research Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: 208-282-5333 Blog , LinkedIn , Play2Train -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111222/862fb33d/attachment.htm From CronoCloud at mchsi.com Thu Dec 22 16:30:33 2011 From: CronoCloud at mchsi.com (Ron Rogers Jr.) Date: Thu, 22 Dec 2011 18:30:33 -0600 Subject: [opensource-dev] Gstreamer issue.. how to debug? In-Reply-To: <1324397974.2561.5.camel@mdickson-ws> References: <4EF0AB8D.4040505@lindenlab.com> <1324397974.2561.5.camel@mdickson-ws> Message-ID: <20111222183033.12a5bb9e.CronoCloud@mchsi.com> On Tue, 20 Dec 2011 11:19:34 -0500 Mike Chase wrote: > So this past weekend Fedora pushed out a bunch of updates which I > installed. I wish they wouldn't do this but they seem to release > stuff in huge batches. Anyway since then SLPlugin fails to play > audio streams. Fedora 16? I'm running Fedora 16 64 bit and streaming worked okay for me yesterday. I'll be in-world tonight so I'll double check. The only thing I can think for you to do is double check you have those i686 gstreamers installed just in case some Fedora update accidentally removed one. If they're still there try reinstalling them. I once had to reinstall the i686 nvidia libs to get SL working after an update. CronoCloud -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111222/24726d31/attachment.pgp From mike.chase at alternatemetaverse.com Thu Dec 22 16:33:17 2011 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Thu, 22 Dec 2011 19:33:17 -0500 Subject: [opensource-dev] Gstreamer issue.. how to debug? In-Reply-To: <20111222183033.12a5bb9e.CronoCloud@mchsi.com> References: <4EF0AB8D.4040505@lindenlab.com> <1324397974.2561.5.camel@mdickson-ws> <20111222183033.12a5bb9e.CronoCloud@mchsi.com> Message-ID: <1324600397.2561.9.camel@mdickson-ws> On Thu, 2011-12-22 at 18:30 -0600, Ron Rogers Jr. wrote: > On Tue, 20 Dec 2011 11:19:34 -0500 > Mike Chase wrote: > > > So this past weekend Fedora pushed out a bunch of updates which I > > installed. I wish they wouldn't do this but they seem to release > > stuff in huge batches. Anyway since then SLPlugin fails to play > > audio streams. > > Fedora 16? I'm running Fedora 16 64 bit and streaming worked okay for > me yesterday. I'll be in-world tonight so I'll double check. The > only thing I can think for you to do is double check you have those > i686 gstreamers installed just in case some Fedora update > accidentally removed one. If they're still there try reinstalling > them. I once had to reinstall the i686 nvidia libs to get SL working > after an update. Yep, I've installed Imprudence 64bit and it works fine. So something about the update clobbered or moved a dependency that used to be in place. Now I just have to figure out which one. Mike > CronoCloud > _______________________________________________ > 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 From armin.weatherwax at googlemail.com Fri Dec 23 08:26:37 2011 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Fri, 23 Dec 2011 17:26:37 +0100 Subject: [opensource-dev] Gstreamer issue.. how to debug? In-Reply-To: <1324397974.2561.5.camel@mdickson-ws> References: <4EF0AB8D.4040505@lindenlab.com> <1324397974.2561.5.camel@mdickson-ws> Message-ID: <201112231726.38057.Armin.Weatherwax@googlemail.com> Am Tuesday 20 December 2011 17:19:34 schrieb Mike Chase: > If I run > > gst-launch-0.10 playbin uri=http://96.44.147.34:7078 > > This works fine. ? From the replies I see you are running a 64bit Linux - so your systems gst-launch-0.10 is a 64bit executable and loads 64bit libraries. For that it has no diagnostic value for debugging a 32bit executable (SLPlugin) which tries to load 32bit libraries. The best thing you can do is to closely watch debug messages about unresolved symbols to find out which 32bit gstreamer parts, plugins, dependencies are missing (e.g. usual suspects are libhttpsoup and libgnomevfs, however there are probably more missing). If you are anyway compiling the viewer yourself, probably its easier and faster to compile a 64bit viewer. If you want I can make a patch for using the Imprundence/Kokua prebuilt 64bit libraries, and point you to 2 patches of Nicky Dasmijn which fix the viewer code for 64bit. Armin From jhwelch at gmail.com Fri Dec 23 09:15:15 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 23 Dec 2011 17:15:15 -0000 Subject: [opensource-dev] Review Request: STORM-1790 Provide a Develop sub-menu to change the default logging level Message-ID: <20111223171515.14052.6716@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/530/ ----------------------------------------------------------- Review request for Viewer. Description ------- Provide a 1) login screen Debug and 2) Develop sub-menu to change the default logging level This addresses bug STORM-1790. http://jira.secondlife.com/browse/STORM-1790 Diffs ----- doc/contributions.txt 3a521e980fbf indra/llcommon/llerror.cpp 3a521e980fbf indra/llcommon/llerrorcontrol.h 3a521e980fbf indra/newview/llviewermenu.cpp 3a521e980fbf indra/newview/skins/default/xui/en/menu_login.xml 3a521e980fbf indra/newview/skins/default/xui/en/menu_viewer.xml 3a521e980fbf Diff: http://codereview.secondlife.com/r/530/diff/diff Testing ------- Opened debug log on screen and adjusted setting via the menu. Noted that logging adjusted to what the level was set to, at least for Debug (which also is All), Info, Warning, and None. I did not test Error, which probably is a bit of a moot point, as it is supposed to cause a crash. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111223/ab3781f1/attachment.htm From Lance.Corrimal at eregion.de Sun Dec 25 00:48:16 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 25 Dec 2011 09:48:16 +0100 Subject: [opensource-dev] space navigator 3d on linux with viewer 3? Message-ID: <201112250948.16328.Lance.Corrimal@eregion.de> Hi all, I see a *lot* of jiras about space navigator 3d support not working in recent viewers... ... is there anyone working on that? Do i have to do more than plug it in to make it work with the latest viewers? bye LC From kf6kjg at gmail.com Sun Dec 25 09:46:35 2011 From: kf6kjg at gmail.com (Ricky) Date: Sun, 25 Dec 2011 09:46:35 -0800 Subject: [opensource-dev] space navigator 3d on linux with viewer 3? In-Reply-To: <201112250948.16328.Lance.Corrimal@eregion.de> References: <201112250948.16328.Lance.Corrimal@eregion.de> Message-ID: I just bought one (the SE edition) for my dad for use in SL. Of course I tested it immediately upon arrival! :P It worked just fine on my Mac, will be testing on Ubuntu and Windows XP shortly - after my dad gets it. I used something recent from the build server: probably a 3.2.6.somethingorother. Ricky Cron Stardust On Sun, Dec 25, 2011 at 12:48 AM, Lance Corrimal wrote: > Hi all, > > I see a *lot* of jiras about space navigator 3d support not working in > recent viewers... > ... is there anyone working on that? > Do i have to do more than plug it in to make it work with the latest > viewers? > > > bye > LC > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111225/b1ace9fa/attachment.htm From Lance.Corrimal at eregion.de Sun Dec 25 10:22:41 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 25 Dec 2011 19:22:41 +0100 Subject: [opensource-dev] space navigator 3d on linux with viewer 3? In-Reply-To: References: <201112250948.16328.Lance.Corrimal@eregion.de> Message-ID: <201112251922.41661.Lance.Corrimal@eregion.de> Got it to work just fine... all you need to do is *NOT* install the linux driver from the 3dconnexion website, and create a few udev and hal rules. Am Sonntag 25 Dezember 2011 schrieb Ricky: > I just bought one (the SE edition) for my dad for use in SL. Of > course I tested it immediately upon arrival! :P It worked just > fine on my Mac, will be testing on Ubuntu and Windows XP shortly - > after my dad gets it. > > I used something recent from the build server: probably a > 3.2.6.somethingorother. > > Ricky > Cron Stardust > > On Sun, Dec 25, 2011 at 12:48 AM, Lance Corrimal > > wrote: > > Hi all, > > > > I see a *lot* of jiras about space navigator 3d support not > > working in recent viewers... > > ... is there anyone working on that? > > Do i have to do more than plug it in to make it work with the > > latest viewers? > > > > > > bye > > LC > > > > _______________________________________________ > > 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 From adeonwriter at live.com Sun Dec 25 11:41:14 2011 From: adeonwriter at live.com (Adeon Writer) Date: Sun, 25 Dec 2011 14:41:14 -0500 Subject: [opensource-dev] space navigator 3d on linux with viewer 3? In-Reply-To: <201112251922.41661.Lance.Corrimal@eregion.de> References: <201112250948.16328.Lance.Corrimal@eregion.de> <201112251922.41661.Lance.Corrimal@eregion.de> Message-ID: For what it's worth, I can also say it works fine for me on all current V3 branches on Vista. Adeon From sllists at boroon.dasgupta.ch Sun Dec 25 14:20:42 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 25 Dec 2011 23:20:42 +0100 Subject: [opensource-dev] space navigator 3d on linux with viewer 3? In-Reply-To: <201112251922.41661.Lance.Corrimal@eregion.de> References: <201112250948.16328.Lance.Corrimal@eregion.de> <201112251922.41661.Lance.Corrimal@eregion.de> Message-ID: <4EF7A1BA.5080008@boroon.dasgupta.ch> On 12/25/2011 07:22 PM, Lance Corrimal wrote: > Got it to work just fine... all you need to do is *NOT* install the > linux driver from the 3dconnexion website, and create a few udev and > hal rules. For those wondering how to do that, it's documented on the wiki . :-) (The udev rules there should work for other 3DConnexion n-DoF-devices, too, but might not have been tested on anything else than the SpaceNavigator.) > Am Sonntag 25 Dezember 2011 schrieb Ricky: >> I just bought one (the SE edition) for my dad for use in SL. Of >> course I tested it immediately upon arrival! :P It worked just >> fine on my Mac, will be testing on Ubuntu and Windows XP shortly - >> after my dad gets it. >> >> I used something recent from the build server: probably a >> 3.2.6.somethingorother. AFAIK, the 'edition' doesn't really matter for what application or operating system software works with SpaceNavigator, as it's all the same hardware, anyway, just different licenses on how you might use it. >> On Sun, Dec 25, 2011 at 12:48 AM, Lance Corrimal >> >> wrote: >>> Hi all, >>> >>> I see a *lot* of jiras about space navigator 3d support not >>> working in recent viewers... >>> ... is there anyone working on that? >>> Do i have to do more than plug it in to make it work with the >>> latest viewers? Looks like you've figured it out by yourself. :-) If anything's missing or wrong on the wiki page linked above, please edit or comment there. Cheers, and a merry Christmas Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111225/53eb2db1/attachment.htm From Ima.Mechanique at blueyonder.co.uk Sun Dec 25 15:15:24 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Sun, 25 Dec 2011 23:15:24 -0000 Subject: [opensource-dev] Review Request: Allow scripts to be saved/loaded to/from files. In-Reply-To: <20111209101217.14846.18122@domU-12-31-38-00-90-68.compute-1.internal> References: <20111209101217.14846.18122@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111225231524.1741.58811@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/516/ ----------------------------------------------------------- (Updated Dec. 25, 2011, 3:15 p.m.) Review request for Viewer. Changes ------- Updated to fix the Windows UI problem. It was caused by the dialogue filter info having been removed at some point. Hopefully, this fixes the problem *without* breaking anything else ;-) Description ------- Changes to allow opened script window to save/load to/from files on the users computer. This addresses bug https://jira.secondlife.com/browse/storm-1708. http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/storm-1708 Diffs (updated) ----- doc/contributions.txt a1319d553db9 indra/llui/lltexteditor.h a1319d553db9 indra/llui/lltexteditor.cpp a1319d553db9 indra/newview/llfilepicker.h a1319d553db9 indra/newview/llfilepicker.cpp a1319d553db9 indra/newview/llfloaternamedesc.h a1319d553db9 indra/newview/llfloaternamedesc.cpp a1319d553db9 indra/newview/llpreviewscript.h a1319d553db9 indra/newview/llpreviewscript.cpp a1319d553db9 indra/newview/llviewerfloaterreg.cpp a1319d553db9 indra/newview/skins/default/xui/en/panel_script_ed.xml a1319d553db9 indra/newview/skins/default/xui/en/strings.xml a1319d553db9 Diff: http://codereview.secondlife.com/r/516/diff/diff Testing ------- Successfully opened and saved scripts from/to local files. Thanks, Ima Mechanique -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111225/7363d8dd/attachment.htm From Ima.Mechanique at blueyonder.co.uk Sun Dec 25 15:17:17 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Sun, 25 Dec 2011 23:17:17 -0000 Subject: [opensource-dev] Review Request: Allow scripts to be saved/loaded to/from files. In-Reply-To: <20111225231524.1741.58811@domU-12-31-38-00-90-68.compute-1.internal> References: <20111225231524.1741.58811@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111225231717.1740.39499@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/516/ ----------------------------------------------------------- (Updated Dec. 25, 2011, 3:17 p.m.) Review request for Viewer. Description ------- Changes to allow opened script window to save/load to/from files on the users computer. This addresses bug storm-1708. http://jira.secondlife.com/browse/storm-1708 Diffs ----- doc/contributions.txt a1319d553db9 indra/llui/lltexteditor.h a1319d553db9 indra/llui/lltexteditor.cpp a1319d553db9 indra/newview/llfilepicker.h a1319d553db9 indra/newview/llfilepicker.cpp a1319d553db9 indra/newview/llfloaternamedesc.h a1319d553db9 indra/newview/llfloaternamedesc.cpp a1319d553db9 indra/newview/llpreviewscript.h a1319d553db9 indra/newview/llpreviewscript.cpp a1319d553db9 indra/newview/llviewerfloaterreg.cpp a1319d553db9 indra/newview/skins/default/xui/en/panel_script_ed.xml a1319d553db9 indra/newview/skins/default/xui/en/strings.xml a1319d553db9 Diff: http://codereview.secondlife.com/r/516/diff/diff Testing ------- Successfully opened and saved scripts from/to local files. Thanks, Ima Mechanique -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111225/9db0588d/attachment.htm From tillie at xp2.de Mon Dec 26 08:20:45 2011 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 26 Dec 2011 17:20:45 +0100 Subject: [opensource-dev] Real Time Animation with Kinect In-Reply-To: <4EF37445.3000305@solar-system.tuis.ac.jp> References: <4EF37445.3000305@solar-system.tuis.ac.jp> Message-ID: <4EF89EDD.9060108@xp2.de> On 22.12.2011 19:17, Fumi.Iseki wrote: > We are now developing SLKinect2(beta) that sends Animation Data to > SecondLife/OpenSim > Viewer on network in real-time. > It is possible that synchronization of Animation on the network using > Animation Relay Server Great to see this project advance! Keep us informed. That's pretty interesting. :) Tillie From lee.ponzu at gmail.com Mon Dec 26 11:23:08 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Mon, 26 Dec 2011 11:23:08 -0800 Subject: [opensource-dev] Chat in bubbles.... Message-ID: Maybe I am the only person in the universe who uses bubble chat, but I have always preferred it. Back in olden times, the bubbles were quite a bit too agressive. That is, a bubble from somebody 20 meters behind you would pop up in front of you so you could read it. However, at some point, somebody must have changed some parameters so that the bubbles don't try quite so hard to appear on your screen. So far so good, but for me 1) the bubbles are not quite aggressive enough, and 2) Maybe there should be a bubble chat aggression parameter that the user can set. 3) Maybe there already is? Anyway, before I start wandering aimlessly through the code, can someone for whom it might only take five seconds poibt me in the right direction (which does not include advice to not use bubble chat 8-). As usual, thanks, and keep up the good work. ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111226/b4b5993b/attachment.htm From marinekelley at gmail.com Wed Dec 28 03:54:59 2011 From: marinekelley at gmail.com (Marine Kelley) Date: Wed, 28 Dec 2011 12:54:59 +0100 Subject: [opensource-dev] Help on invisiprims being broken with deferred rendering Message-ID: Hi all, and Merry Christmas and Happy New Year (in advance) ! I am working on my RLV and am hitting a wall here. Invisiprims (the prims that hide a part of your body when you wear shoes or other pieces of clothing) are completely useless on the latest v-d viewer, when deferred rendering is active. I know that alpha clothing is supposed to do the same, but it is not possible to use it in every case, so I have been trying to fix it myself, to no avail. A couple months ago, simply backing out the fix to SH-2181 did the trick, but now the viewer uses OpenGL 3.0 so this solution is obsolete, since some of the functions it uses are now deprecated. I have filed a JIRA on this : https://jira.secondlife.com/browse/VWR-27981 I don't have much hope that this will be a high priority for LL, but it is very important for me that invisiprims work. Could someone point me into the right direction please ? I have been looking into the shaders but I don't understand much about them so I'm at a loss here. Thanks in advance, Marine From moriz.gupte at gmail.com Fri Dec 30 10:18:30 2011 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Fri, 30 Dec 2011 11:18:30 -0700 Subject: [opensource-dev] hover tooltips and camera control speed Message-ID: Hello, Before going into the code to try to make changes myself wanted to find out if 1. there is a debug setting in the dev viewer that allows the speed of the camera control via keybard (I guess I could adjust keyboard repeat rate)... but wondering 2. I see a lot tool tip debug settings but they seem to have no effect on tool tip behavior when running under Windows 7 (of course, I set them and then restarted ... no effect). Thanks Ramesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111230/9b38b6f6/attachment.htm