From tillie at xp2.de Thu Jun 2 03:19:24 2011 From: tillie at xp2.de (Tillie Ariantho) Date: Thu, 02 Jun 2011 12:19:24 +0200 Subject: [opensource-dev] releasenote list? In-Reply-To: References: Message-ID: <4DE763AC.40800@xp2.de> Hello, is there something like a combined change list for all the builds I can browse through, not including messages like "merged down from ..."? More like everything you would put into release notes. Tillie From jhwelch at gmail.com Thu Jun 2 14:03:25 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 02 Jun 2011 21:03:25 -0000 Subject: [opensource-dev] Review Request: STORM-49 As a Content Creator, I have to select a regular prim type and than choose sculpt from a drop-down menu in order to create a sculpted prim. Message-ID: <20110602210325.6377.56894@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/317/ ----------------------------------------------------------- Review request for Viewer. Summary ------- As a Content Creator, I have to select a regular prim type and than choose sculpt from a drop-down menu in order to create a sculpted prim. I have added a new Sculpt icon to the list of available object types that can be selected on the build menu. You can now rez a sculpt the same way you do a cube. Possible issue: I made up a new Pcode used only by the viewer. This addresses bug STORM-49. http://jira.secondlife.com/browse/STORM-49 Diffs ----- doc/contributions.txt a36a329e77cc indra/llmath/llvolume.h a36a329e77cc indra/llprimitive/llprimitive.cpp a36a329e77cc indra/newview/llfloatertools.cpp a36a329e77cc indra/newview/lltoolplacer.cpp a36a329e77cc indra/newview/llviewerobjectlist.h a36a329e77cc indra/newview/llviewerobjectlist.cpp a36a329e77cc indra/newview/skins/default/textures/build/Object_Sculpt.png a36a329e77cc indra/newview/skins/default/textures/build/Object_Sculpt_Selected.png a36a329e77cc indra/newview/skins/default/textures/textures.xml a36a329e77cc indra/newview/skins/default/xui/en/floater_tools.xml a36a329e77cc Diff: http://codereview.secondlife.com/r/317/diff Testing ------- Rezzed a sculpt both alone and with someone watching. Rezzed sculpts as fast as I could click (poor mans load test). Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110602/b1c58814/attachment.htm From hitomi.tiponi at yahoo.co.uk Thu Jun 2 17:47:51 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Fri, 3 Jun 2011 01:47:51 +0100 (BST) Subject: [opensource-dev] releasenote list? Message-ID: <881456.56482.qm@web23903.mail.ird.yahoo.com> As a side issue it seems the section 'Changes since last good build' is not opening on recent builds of Snowstorm. It was fine until a few days back - but now won't do the normal 'drop-down' thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110603/527b782d/attachment.htm From stickman at gmail.com Thu Jun 2 19:59:14 2011 From: stickman at gmail.com (Stickman) Date: Thu, 2 Jun 2011 19:59:14 -0700 Subject: [opensource-dev] releasenote list? In-Reply-To: <4DE763AC.40800@xp2.de> References: <4DE763AC.40800@xp2.de> Message-ID: > More like everything you would put into release notes. If you're looking for release notes, the wiki might be your best bet. http://wiki.secondlife.com/wiki/Release_Notes Scroll down to the bottom. Other than that, I can't help. Stickman From cg at lindenlab.com Thu Jun 2 22:51:27 2011 From: cg at lindenlab.com (CG Linden) Date: Thu, 2 Jun 2011 22:51:27 -0700 Subject: [opensource-dev] releasenote list? In-Reply-To: <881456.56482.qm@web23903.mail.ird.yahoo.com> References: <881456.56482.qm@web23903.mail.ird.yahoo.com> Message-ID: On Thu, Jun 2, 2011 at 5:47 PM, Hitomi Tiponi wrote: > As a side issue it seems the section 'Changes since last good build' is > not opening on recent builds of Snowstorm. It was fine until a few days > back - but now won't do the normal 'drop-down' thing. > > That should be fixed again. I first fixed a problem with the Jira-drop-down not working, and that broke the Changes dropdown. -- cg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110602/4c162ac1/attachment.htm From oz at lindenlab.com Fri Jun 3 07:43:38 2011 From: oz at lindenlab.com (Oz Linden) Date: Fri, 03 Jun 2011 14:43:38 -0000 Subject: [opensource-dev] Review Request: Update autobuilds default VC version to 2010 In-Reply-To: <20110516225043.4361.16523@domU-12-31-38-00-90-68.compute-1.internal> References: <20110516225043.4361.16523@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110603144338.6380.92934@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/305/ ----------------------------------------------------------- (Updated June 3, 2011, 7:43 a.m.) Review request for Viewer. Changes ------- adding link back to jira Summary ------- Autobuild defaults to VC 2005 if the environment variable AUTOBUILD_VSVER is unset. Now that LL have moved to VC 2010 completely, shouldn't this become the default version? This addresses bug open-66. http://jira.secondlife.com/browse/open-66 Diffs ----- autobuild/autobuild_tool_source_environment.py 2a560b1d8f95 Diff: http://codereview.secondlife.com/r/305/diff Testing ------- Thanks, Ima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110603/39ee7192/attachment.htm From log at lindenlab.com Fri Jun 3 12:56:50 2011 From: log at lindenlab.com (Log Linden) Date: Fri, 03 Jun 2011 19:56:50 -0000 Subject: [opensource-dev] Review Request: Viewer cache size increase to 10GB. Message-ID: <20110603195650.14439.46763@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/318/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This patch increases the maximum and default viewer cache size values. Due to limitations in the size of the VFS, the 80/20 texture cache/VFS split is maintained up to 5GB, then the remaining cache size is given to the texture cache. This caps the VFS size at 1GB ( up from .2 GB ). I made corresponding changes to the XUI to allow the slider to increase to the new cache size maximum. Bugfixes: * The reset cache location button will no longer tell the user that the cache will be cleared if the cache is already in the default location. Only the notification was suppressed, the cache was never cleared by this button unless the location changed. * The reset cache location button will now correctly clear the old cache when it is reset back to the default location. * I fixed an order of operation programming error in an llerrs log message in the lltexturecache.cpp. This was showing wildly incorrect texture cache size during a purge. * Code convention cleanup in llappviewer.cpp in initCache() and lltexturecache.cpp This addresses bugs er-767, er-883 and er-883. http://jira.secondlife.com/browse/er-767 http://jira.secondlife.com/browse/er-883 http://jira.secondlife.com/browse/er-883 Diffs ----- indra/newview/llappviewer.cpp 9c0506d10226 indra/newview/llfloaterpreference.cpp 9c0506d10226 indra/newview/lltexturecache.cpp 9c0506d10226 indra/newview/skins/default/xui/en/panel_preferences_setup.xml 9c0506d10226 Diff: http://codereview.secondlife.com/r/318/diff Testing ------- I have built and tested on all three platforms. The log files indicate that the caches are being initialised with the correct sizes. Thanks, Log -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110603/dea9608d/attachment.htm From log at lindenlab.com Fri Jun 3 12:56:52 2011 From: log at lindenlab.com (Log Linden) Date: Fri, 03 Jun 2011 19:56:52 -0000 Subject: [opensource-dev] Review Request: Viewer cache UI improvements. Message-ID: <20110603195652.7245.12799@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/321/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This is mostly a UI change in support of the viewer cache improvements I have been making. The XUI changes were mocked up and approved by Wolf. * Moved viewer cache controls to the advanced tab of the preferences menu. * Changed the cache size control to a spinner. * Relabeled the reset button to "Default Location" to clarify the purpose. * Readded a clear cache button. * Increased the minimum cache size to 64MB and set the max to 9984MB. The increment in the spinner is 64 and both the min, max and default are multiples of 64. Wolf suggested using a high 4 digit number to allow the 4 digit wide spinner text box to suggest the maximum size of the cache. Diffs ----- indra/newview/skins/default/xui/en/panel_preferences_advanced.xml 9c0506d10226 indra/newview/skins/default/xui/en/panel_preferences_setup.xml 9c0506d10226 indra/newview/skins/default/xui/en/notifications.xml 9c0506d10226 indra/newview/llappviewer.cpp 9c0506d10226 indra/newview/llfloaterpreference.h 9c0506d10226 indra/newview/llfloaterpreference.cpp 9c0506d10226 Diff: http://codereview.secondlife.com/r/321/diff Testing ------- I have built and tested all three platforms. I also tried switching between a viewer with a lower max or min. The value in the settings.xml file will be automatically clamped during the cache initialisation. On older viewers, when a user opens the settings tab with the cache size slider, it will jump to within the old bounds. When the user click ok in that preferences menu, the clamped value is saved in the settings file. In the new viewer with the spinner, the old out of bounds value will appear in the spinner until the user changes it. This won't have an effect on the value being used, because of the clamp during init. Thanks, Log -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110603/b7db785c/attachment.htm From sythos at gmail.com Fri Jun 3 17:03:49 2011 From: sythos at gmail.com (Altair Sythos Memo) Date: Sat, 4 Jun 2011 02:03:49 +0200 Subject: [opensource-dev] 3D connexion devices on linux Message-ID: <20110604020349.84330354.sythos@gmail.com> linux resident with kernel 2.6.35 (or more) cannot use 3d mouse bc NDOF0.2 don't support new "evdev" interface, NDOF 0.3 (released by same author of previous one) support fine both old and new kernels, how can somebody submit via HG or else the new code? From sythos at gmail.com Fri Jun 3 18:07:12 2011 From: sythos at gmail.com (Altair Memo) Date: Sat, 04 Jun 2011 01:07:12 -0000 Subject: [opensource-dev] Review Request: patch to let 3D connexion devices work on linux with kernel 2.6.35 or newer Message-ID: <20110604010712.9329.23675@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/322/ ----------------------------------------------------------- Review request for Viewer. Summary ------- fix for OPEN-21 added EVDEV layer for linux users on 2.6.35+ kernels - added both personal 3P libs and indra subdir (and cmake NDOF.cmake file fix), first one less usefull, should be more better find a place where put prebuilt lib (jira affect only linux) This addresses bug OPEN-21. http://jira.secondlife.com/browse/OPEN-21 Diffs ----- autobuild.xml d74fd886c8a6 indra/cmake/NDOF.cmake d74fd886c8a6 indra/llndof-linux/CMakeLists.txt PRE-CREATION indra/llndof-linux/Makefile PRE-CREATION indra/llndof-linux/ndofdev.c PRE-CREATION indra/llndof-linux/ndofdev_external.h PRE-CREATION Diff: http://codereview.secondlife.com/r/322/diff Testing ------- I suppose "on my linux system work" is a poor point, using prebuilt ?libs since long, the cmake and subdir work using autobuild with "ReleaseOS" Thanks, Altair -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110604/e9be881b/attachment.htm From sythos at gmail.com Fri Jun 3 18:10:27 2011 From: sythos at gmail.com (Altair Memo) Date: Sat, 04 Jun 2011 01:10:27 -0000 Subject: [opensource-dev] Review Request: patch to let 3D connexion devices work on linux with kernel 2.6.35 or newer In-Reply-To: <20110604010712.9329.23675@domU-12-31-38-00-90-68.compute-1.internal> References: <20110604010712.9329.23675@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110604011027.6381.3327@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/322/ ----------------------------------------------------------- (Updated June 3, 2011, 6:10 p.m.) Review request for Viewer. Changes ------- forgot contrib :-\ Summary ------- fix for OPEN-21 added EVDEV layer for linux users on 2.6.35+ kernels - added both personal 3P libs and indra subdir (and cmake NDOF.cmake file fix), first one less usefull, should be more better find a place where put prebuilt lib (jira affect only linux) This addresses bug OPEN-21. http://jira.secondlife.com/browse/OPEN-21 Diffs (updated) ----- autobuild.xml d74fd886c8a6 doc/contributions.txt d74fd886c8a6 indra/cmake/NDOF.cmake d74fd886c8a6 indra/llndof-linux/CMakeLists.txt PRE-CREATION indra/llndof-linux/Makefile PRE-CREATION indra/llndof-linux/ndofdev.c PRE-CREATION indra/llndof-linux/ndofdev_external.h PRE-CREATION Diff: http://codereview.secondlife.com/r/322/diff Testing ------- I suppose "on my linux system work" is a poor point, using prebuilt ?libs since long, the cmake and subdir work using autobuild with "ReleaseOS" Thanks, Altair -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110604/5765098c/attachment-0001.htm From sythos at gmail.com Sat Jun 4 01:37:47 2011 From: sythos at gmail.com (Francesco "Sythos") Date: Sat, 4 Jun 2011 10:37:47 +0200 Subject: [opensource-dev] 3D connexion devices on linux In-Reply-To: References: <20110604020349.84330354.sythos@gmail.com> Message-ID: <-1596093459512050577@unknownmsgid> We cannot ask to the world to patch the kernel for SL, not all have enough skills, and all other device and programs work fine. Imho the right way to work is fix the SL side, without introduce risk and collateral effect putting hands on kernel -- Sent by iPhone Il giorno 04/giu/2011, alle ore 08:59, "L. Christopher Bird" < zenmondo at gmail.com> ha scritto: I have a friend that uses a space navigator for SL and explains that it was broken in the past and SL had a workaround, and by actually fixing the kernel broke SL. Here is the patch she wrote. In short just adding a "return" in the right place. diff -ru linux-2.6.36-gentoo-r5/drivers/hid/hid-lg.c linux-2.6.36-gentoo-r5-new/drivers/hid/hid-lg.c --- linux-2.6.36-gentoo-r5/drivers/hid/hid-lg.c 2010-10-20 16:30:22.000000000 -0400 +++ linux-2.6.36-gentoo-r5-new/drivers/hid/hid-lg.c 2011-03-09 20:44:53.000000000 -0500 @@ -53,6 +53,7 @@ rdesc[84] = rdesc[89] = 0x4d; rdesc[85] = rdesc[90] = 0x10; } + return; // A cheap hack to make SL work. if ((quirks & LG_RDESC_REL_ABS) && rsize >= 50 && rdesc[32] == 0x81 && rdesc[33] == 0x06 && rdesc[49] == 0x81 && rdesc[50] == 0x06) { -- Zen On Fri, Jun 3, 2011 at 6:03 PM, Altair Sythos wrote: > linux resident with kernel 2.6.35 (or more) cannot use 3d mouse bc > NDOF0.2 don't support new "evdev" interface, NDOF 0.3 (released by same > author of previous one) support fine both old and new kernels, how can > somebody submit via HG or else the new code? > _______________________________________________ > 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/20110604/6a4af27b/attachment.htm From sllists at boroon.dasgupta.ch Sat Jun 4 04:00:38 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 04 Jun 2011 13:00:38 +0200 Subject: [opensource-dev] new subtasks added to STORM-312 (was: 3D connexion devices on linux) In-Reply-To: <-1596093459512050577@unknownmsgid> References: <20110604020349.84330354.sythos@gmail.com> <-1596093459512050577@unknownmsgid> Message-ID: <4DEA1056.3030000@boroon.dasgupta.ch> On 06/04/2011 10:37 AM, Francesco "Sythos" wrote: > We cannot ask to the world to patch the kernel for SL, not all have > enough skills, and all other device and programs work fine. Imho the > right way to work is fix the SL side, without introduce risk and > collateral effect putting hands on kernel Yes, patching the kernel is a workaround, not the solution. The kernel has changed its interface for a reason and linux libNDOFdev must go with it (and /has/ already gone with it. We just need to upgrade to Jan's latest version, 0.3.) The upgrade could easily be done by one of us community devs if the 3p-* repository to create the current linux libndofdev autobuild installable would be around. Note that the already published https://bitbucket.org/lindenlab/3p-libndofdev is a different library (the one for Mac and Windows by 3DConnexions, now hosted by LL). Thus I've created two subtasks on STORM-312 : * STORM-1319 for publishing the 3p-* repo with the currently used (0.2 based) code * STORM-1320 for upgrading it to Jan's version 0.3 I'm willing to take up STORM-1320 once STORM-1319 is done. @Oz: Can you please investigate (or get someone to investigate) whether a 3p-* repo for the linux libNDOFdev already exists internally at LL and can be published? If none exists, yet, and we thus have to create one for Jan's sources from scratch, I'd like someone to walk me through the process of doing so. (Yes, I know there are guides about that on the wiki, but I don't even know which of the apparently several ones to follow.) Cheers, Boroondas PS: For a history of this issue, also see the duplicate at OPEN-21 . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110604/ceebdebc/attachment.htm From sythos at gmail.com Sat Jun 4 04:05:57 2011 From: sythos at gmail.com (Altair Sythos Memo) Date: Sat, 4 Jun 2011 13:05:57 +0200 Subject: [opensource-dev] new subtasks added to STORM-312 (was: 3D connexion devices on linux) In-Reply-To: <4DEA1056.3030000@boroon.dasgupta.ch> References: <20110604020349.84330354.sythos@gmail.com> <-1596093459512050577@unknownmsgid> <4DEA1056.3030000@boroon.dasgupta.ch> Message-ID: <20110604130557.c6c484ba.sythos@gmail.com> On Sat, 04 Jun 2011 13:00:38 +0200 Boroondas Gupte wrote: > @Oz: Can you please investigate (or get someone to investigate) > whether a 3p-* repo for the linux libNDOFdev already exists > internally at LL and can be published? If none exists, yet, and we > thus have to create one for Jan's sources from scratch, I'd like > someone to walk me through the process of doing so. (Yes, I know > there are guides about that on the wiki, but I don't even know which > of the apparently several ones to follow.) agree a lot, i've already a 3p-ndof (used by me for KV purposes)m i should just clean around replacing KV with LL :) From sllists at boroon.dasgupta.ch Sat Jun 4 04:13:12 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 04 Jun 2011 11:13:12 -0000 Subject: [opensource-dev] Review Request: patch to let 3D connexion devices work on linux with kernel 2.6.35 or newer In-Reply-To: <20110604011027.6381.3327@domU-12-31-38-00-90-68.compute-1.internal> References: <20110604011027.6381.3327@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110604111312.6383.42901@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/322/#review717 ----------------------------------------------------------- autobuild.xml I don't think the LL viewer should use library binaries not hosted under LL's control. indra/llndof-linux/ndofdev.c You are replacing the prebuilt installable AND adding the lib sources to the viewer source tree? That can't be the right way, sorry. - Boroondas On June 3, 2011, 6:10 p.m., Altair Memo wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/322/ > ----------------------------------------------------------- > > (Updated June 3, 2011, 6:10 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > fix for OPEN-21 > added EVDEV layer for linux users on 2.6.35+ kernels > > - added both personal 3P libs and indra subdir (and cmake NDOF.cmake file fix), first one less usefull, should be more better find a place where put prebuilt lib (jira affect only linux) > > > This addresses bug OPEN-21. > http://jira.secondlife.com/browse/OPEN-21 > > > Diffs > ----- > > autobuild.xml d74fd886c8a6 > doc/contributions.txt d74fd886c8a6 > indra/cmake/NDOF.cmake d74fd886c8a6 > indra/llndof-linux/CMakeLists.txt PRE-CREATION > indra/llndof-linux/Makefile PRE-CREATION > indra/llndof-linux/ndofdev.c PRE-CREATION > indra/llndof-linux/ndofdev_external.h PRE-CREATION > > Diff: http://codereview.secondlife.com/r/322/diff > > > Testing > ------- > > I suppose "on my linux system work" is a poor point, using prebuilt ?libs since long, the cmake and subdir work using autobuild with "ReleaseOS" > > > Thanks, > > Altair > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110604/48bbfee3/attachment.htm From oz at lindenlab.com Sat Jun 4 04:32:22 2011 From: oz at lindenlab.com (Oz Linden) Date: Sat, 04 Jun 2011 11:32:22 -0000 Subject: [opensource-dev] Review Request: Viewer cache size increase to 10GB. In-Reply-To: <20110603195650.14439.46763@domU-12-31-38-00-90-68.compute-1.internal> References: <20110603195650.14439.46763@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110604113222.7243.23346@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/318/#review718 ----------------------------------------------------------- indra/newview/llfloaterpreference.cpp I would prefer to see this done the other way (even though it produces a larger diff); test for the positive condition and enclose the resulting action in the 'then' block. I dislike early returns. While they are sometimes justifiable in a large routine for unusual cases, I don't think this fits that bill. Not a show stopper, just a note for the future - Oz On June 3, 2011, 12:56 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/318/ > ----------------------------------------------------------- > > (Updated June 3, 2011, 12:56 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This patch increases the maximum and default viewer cache size values. Due to limitations in the size of the VFS, the 80/20 texture cache/VFS split is maintained up to 5GB, then the remaining cache size is given to the texture cache. This caps the VFS size at 1GB ( up from .2 GB ). I made corresponding changes to the XUI to allow the slider to increase to the new cache size maximum. > > Bugfixes: > * The reset cache location button will no longer tell the user that the cache will be cleared if the cache is already in the default location. Only the notification was suppressed, the cache was never cleared by this button unless the location changed. > * The reset cache location button will now correctly clear the old cache when it is reset back to the default location. > * I fixed an order of operation programming error in an llerrs log message in the lltexturecache.cpp. This was showing wildly incorrect texture cache size during a purge. > * Code convention cleanup in llappviewer.cpp in initCache() and lltexturecache.cpp > > > This addresses bugs er-767, er-883 and er-883. > http://jira.secondlife.com/browse/er-767 > http://jira.secondlife.com/browse/er-883 > http://jira.secondlife.com/browse/er-883 > > > Diffs > ----- > > indra/newview/llappviewer.cpp 9c0506d10226 > indra/newview/llfloaterpreference.cpp 9c0506d10226 > indra/newview/lltexturecache.cpp 9c0506d10226 > indra/newview/skins/default/xui/en/panel_preferences_setup.xml 9c0506d10226 > > Diff: http://codereview.secondlife.com/r/318/diff > > > Testing > ------- > > I have built and tested on all three platforms. The log files indicate that the caches are being initialised with the correct sizes. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110604/76860504/attachment-0001.htm From oz at lindenlab.com Sat Jun 4 04:32:39 2011 From: oz at lindenlab.com (Oz Linden) Date: Sat, 04 Jun 2011 11:32:39 -0000 Subject: [opensource-dev] Review Request: Viewer cache size increase to 10GB. In-Reply-To: <20110603195650.14439.46763@domU-12-31-38-00-90-68.compute-1.internal> References: <20110603195650.14439.46763@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110604113239.6382.73922@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/318/#review719 ----------------------------------------------------------- Ship it! - Oz On June 3, 2011, 12:56 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/318/ > ----------------------------------------------------------- > > (Updated June 3, 2011, 12:56 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This patch increases the maximum and default viewer cache size values. Due to limitations in the size of the VFS, the 80/20 texture cache/VFS split is maintained up to 5GB, then the remaining cache size is given to the texture cache. This caps the VFS size at 1GB ( up from .2 GB ). I made corresponding changes to the XUI to allow the slider to increase to the new cache size maximum. > > Bugfixes: > * The reset cache location button will no longer tell the user that the cache will be cleared if the cache is already in the default location. Only the notification was suppressed, the cache was never cleared by this button unless the location changed. > * The reset cache location button will now correctly clear the old cache when it is reset back to the default location. > * I fixed an order of operation programming error in an llerrs log message in the lltexturecache.cpp. This was showing wildly incorrect texture cache size during a purge. > * Code convention cleanup in llappviewer.cpp in initCache() and lltexturecache.cpp > > > This addresses bugs er-767, er-883 and er-883. > http://jira.secondlife.com/browse/er-767 > http://jira.secondlife.com/browse/er-883 > http://jira.secondlife.com/browse/er-883 > > > Diffs > ----- > > indra/newview/llappviewer.cpp 9c0506d10226 > indra/newview/llfloaterpreference.cpp 9c0506d10226 > indra/newview/lltexturecache.cpp 9c0506d10226 > indra/newview/skins/default/xui/en/panel_preferences_setup.xml 9c0506d10226 > > Diff: http://codereview.secondlife.com/r/318/diff > > > Testing > ------- > > I have built and tested on all three platforms. The log files indicate that the caches are being initialised with the correct sizes. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110604/b24c44a4/attachment.htm From jhwelch at gmail.com Sun Jun 5 07:36:20 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Sun, 05 Jun 2011 14:36:20 -0000 Subject: [opensource-dev] Review Request: VWR-25896 [Regression] Bulk uploads do not adhere to default permissions Message-ID: <20110605143620.6081.30456@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/323/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Something in the big mesh branch merge (build 230088) appears to have broken bulk uploading. * On inventory tab, click "+" menu -> Upload -> Set Default Permissions * Set your default permissions to enable Next owner Modify, Copy, and Resell/Giveaway and click OK * Click "+" menu -> Upload -> Bulk and select a group of multiple images * After upload completes, check permissions of each uploaded item Expected behavior is that all the bulk uploaded items would have Modify/Copy/Transfer permissions. Actual results is that first item upload has Modify/Copy/Transfer permissions, all others have no perms at all. I examined this area of code before the mesh merge and saw a small but significant difference. It is not clear to me that this is the only change necessary; in an email Oz said a server-side change might be needed too. This addresses bug VWR-25896. http://jira.secondlife.com/browse/VWR-25896 Diffs ----- doc/contributions.txt e4ef43d63d55 indra/newview/llassetuploadresponders.cpp e4ef43d63d55 Diff: http://codereview.secondlife.com/r/323/diff Testing ------- Repeated bulk uploading of two textures, altering the settings in the bulk upload floater for each test; their uploaded properties followed the settings I had set in the floater. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110605/65b0cb90/attachment.htm From sllists at boroon.dasgupta.ch Sun Jun 5 08:03:25 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 05 Jun 2011 15:03:25 -0000 Subject: [opensource-dev] Review Request: VWR-25896 [Regression] Bulk uploads do not adhere to default permissions In-Reply-To: <20110605143620.6081.30456@domU-12-31-38-00-90-68.compute-1.internal> References: <20110605143620.6081.30456@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110605150325.6080.1562@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/323/#review720 ----------------------------------------------------------- indra/newview/llassetuploadresponders.cpp While you're at it, re-complete this comment that was (probably accidentally) clipped in the same commit (https://bitbucket.org/lindenlab/viewer-development/changeset/8871cfd6eaf5#chg_indra/newview/llassetuploadresponders.cpp_oldline328 ) indra/newview/llassetuploadresponders.cpp If the original comment is still accurate, your fix should be fine. (The now missing line in the comment explains why mPostData has to be used here rather than content.) However a lot has changed around here, so it's hard to tell whether the original comment would still apply unchanged. - Boroondas On June 5, 2011, 7:36 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/323/ > ----------------------------------------------------------- > > (Updated June 5, 2011, 7:36 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Something in the big mesh branch merge (build 230088) appears to have broken bulk uploading. > > * On inventory tab, click "+" menu -> Upload -> Set Default Permissions > * Set your default permissions to enable Next owner Modify, Copy, and Resell/Giveaway and click OK > * Click "+" menu -> Upload -> Bulk and select a group of multiple images > * After upload completes, check permissions of each uploaded item > > Expected behavior is that all the bulk uploaded items would have Modify/Copy/Transfer permissions. > Actual results is that first item upload has Modify/Copy/Transfer permissions, all others have no perms at all. > > I examined this area of code before the mesh merge and saw a small but significant difference. It is not clear to me that this is the only change necessary; in an email Oz said a server-side change might be needed too. > > > This addresses bug VWR-25896. > http://jira.secondlife.com/browse/VWR-25896 > > > Diffs > ----- > > doc/contributions.txt e4ef43d63d55 > indra/newview/llassetuploadresponders.cpp e4ef43d63d55 > > Diff: http://codereview.secondlife.com/r/323/diff > > > Testing > ------- > > Repeated bulk uploading of two textures, altering the settings in the bulk upload floater for each test; their uploaded properties followed the settings I had set in the floater. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110605/b8f9038c/attachment-0001.htm From jhwelch at gmail.com Sun Jun 5 08:11:28 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Sun, 05 Jun 2011 15:11:28 -0000 Subject: [opensource-dev] Review Request: VWR-25896 [Regression] Bulk uploads do not adhere to default permissions In-Reply-To: <20110605143620.6081.30456@domU-12-31-38-00-90-68.compute-1.internal> References: <20110605143620.6081.30456@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110605151128.6075.50695@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/323/ ----------------------------------------------------------- (Updated June 5, 2011, 8:11 a.m.) Review request for Viewer. Summary ------- Something in the big mesh branch merge (build 230088) appears to have broken bulk uploading. * On inventory tab, click "+" menu -> Upload -> Set Default Permissions * Set your default permissions to enable Next owner Modify, Copy, and Resell/Giveaway and click OK * Click "+" menu -> Upload -> Bulk and select a group of multiple images * After upload completes, check permissions of each uploaded item Expected behavior is that all the bulk uploaded items would have Modify/Copy/Transfer permissions. Actual results is that first item upload has Modify/Copy/Transfer permissions, all others have no perms at all. I examined this area of code before the mesh merge and saw a small but significant difference. It is not clear to me that this is the only change necessary; in an email Oz said a server-side change might be needed too. This addresses bug VWR-25896. http://jira.secondlife.com/browse/VWR-25896 Diffs (updated) ----- doc/contributions.txt e4ef43d63d55 indra/newview/llassetuploadresponders.cpp e4ef43d63d55 Diff: http://codereview.secondlife.com/r/323/diff Testing ------- Repeated bulk uploading of two textures, altering the settings in the bulk upload floater for each test; their uploaded properties followed the settings I had set in the floater. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110605/1aa50238/attachment.htm From jhwelch at gmail.com Sun Jun 5 08:13:29 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Sun, 05 Jun 2011 15:13:29 -0000 Subject: [opensource-dev] Review Request: VWR-25896 [Regression] Bulk uploads do not adhere to default permissions In-Reply-To: <20110605150325.6080.1562@domU-12-31-38-00-90-68.compute-1.internal> References: <20110605150325.6080.1562@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110605151329.6514.82080@domU-12-31-38-00-90-68.compute-1.internal> > On June 5, 2011, 8:03 a.m., Boroondas Gupte wrote: > > indra/newview/llassetuploadresponders.cpp, lines 384-386 > > > > > > While you're at it, re-complete this comment that was (probably accidentally) clipped in the same commit (https://bitbucket.org/lindenlab/viewer-development/changeset/8871cfd6eaf5#chg_indra/newview/llassetuploadresponders.cpp_oldline328 ) Added back line in clipped comment. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/323/#review720 ----------------------------------------------------------- On June 5, 2011, 8:11 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/323/ > ----------------------------------------------------------- > > (Updated June 5, 2011, 8:11 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Something in the big mesh branch merge (build 230088) appears to have broken bulk uploading. > > * On inventory tab, click "+" menu -> Upload -> Set Default Permissions > * Set your default permissions to enable Next owner Modify, Copy, and Resell/Giveaway and click OK > * Click "+" menu -> Upload -> Bulk and select a group of multiple images > * After upload completes, check permissions of each uploaded item > > Expected behavior is that all the bulk uploaded items would have Modify/Copy/Transfer permissions. > Actual results is that first item upload has Modify/Copy/Transfer permissions, all others have no perms at all. > > I examined this area of code before the mesh merge and saw a small but significant difference. It is not clear to me that this is the only change necessary; in an email Oz said a server-side change might be needed too. > > > This addresses bug VWR-25896. > http://jira.secondlife.com/browse/VWR-25896 > > > Diffs > ----- > > doc/contributions.txt e4ef43d63d55 > indra/newview/llassetuploadresponders.cpp e4ef43d63d55 > > Diff: http://codereview.secondlife.com/r/323/diff > > > Testing > ------- > > Repeated bulk uploading of two textures, altering the settings in the bulk upload floater for each test; their uploaded properties followed the settings I had set in the floater. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110605/0ddd347c/attachment.htm From sllists at boroon.dasgupta.ch Sun Jun 5 08:19:47 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 05 Jun 2011 15:19:47 -0000 Subject: [opensource-dev] Review Request: VWR-25896 [Regression] Bulk uploads do not adhere to default permissions In-Reply-To: <20110605151128.6075.50695@domU-12-31-38-00-90-68.compute-1.internal> References: <20110605151128.6075.50695@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110605151947.6081.86196@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/323/#review723 ----------------------------------------------------------- Ship it! indra/newview/llassetuploadresponders.cpp No objections, so let's just see whether this works. It'd be nice if whoever did change this from 'mPostData' to 'content' would comment on this fix, but as the commit where that happened seems to lump together many unrelated changes (maybe still from an SVN branch?), it'll be difficult to track down who that even was. - Boroondas On June 5, 2011, 8:11 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/323/ > ----------------------------------------------------------- > > (Updated June 5, 2011, 8:11 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Something in the big mesh branch merge (build 230088) appears to have broken bulk uploading. > > * On inventory tab, click "+" menu -> Upload -> Set Default Permissions > * Set your default permissions to enable Next owner Modify, Copy, and Resell/Giveaway and click OK > * Click "+" menu -> Upload -> Bulk and select a group of multiple images > * After upload completes, check permissions of each uploaded item > > Expected behavior is that all the bulk uploaded items would have Modify/Copy/Transfer permissions. > Actual results is that first item upload has Modify/Copy/Transfer permissions, all others have no perms at all. > > I examined this area of code before the mesh merge and saw a small but significant difference. It is not clear to me that this is the only change necessary; in an email Oz said a server-side change might be needed too. > > > This addresses bug VWR-25896. > http://jira.secondlife.com/browse/VWR-25896 > > > Diffs > ----- > > doc/contributions.txt e4ef43d63d55 > indra/newview/llassetuploadresponders.cpp e4ef43d63d55 > > Diff: http://codereview.secondlife.com/r/323/diff > > > Testing > ------- > > Repeated bulk uploading of two textures, altering the settings in the bulk upload floater for each test; their uploaded properties followed the settings I had set in the floater. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110605/17773440/attachment-0001.htm From jhwelch at gmail.com Sun Jun 5 09:43:06 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Sun, 5 Jun 2011 12:43:06 -0400 Subject: [opensource-dev] Sorting table displays Message-ID: When you open up the information for a group and get the list of members, their role title, and their last active date none of those columns are sorted by default. Should one be and if so, which one? Are there other tables like this that you can think of which would benefit from being sorted (with some help I made this change for the results in the World map)? -jonathan From wolfpup67 at earthlink.net Sun Jun 5 18:27:10 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Sun, 5 Jun 2011 21:27:10 -0400 Subject: [opensource-dev] Sorting table displays In-Reply-To: References: Message-ID: <000001cc23e8$db5f1c10$921d5430$@net> I agree the list of people in the groups would benefit from a default sorting. The sorting order I would suggest would be the following: A) Status(online and last seen) descending. B) Roles ascending.(Owner -> Officers -> Everyone) C) Name descending. This would allow people to know when either the group owner is online or one of the officers or when they were last on. > -----Original Message----- > From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev- > bounces at lists.secondlife.com] On Behalf Of Jonathan Welch > Sent: Sunday, June 05, 2011 12:43 PM > To: OpenSource Mailing List > Subject: [opensource-dev] Sorting table displays > > When you open up the information for a group and get the list of > members, their role title, and their last active date none of those > columns are sorted by default. Should one be and if so, which one? > > Are there other tables like this that you can think of which would > benefit from being sorted (with some help I made this change for the > results in the World map)? > > -jonathan > _______________________________________________ > 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 > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1382 / Virus Database: 1511/3683 - Release Date: 06/05/11 From trilobyte550m at gmail.com Sun Jun 5 23:30:47 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Sun, 5 Jun 2011 23:30:47 -0700 Subject: [opensource-dev] Sorting table displays In-Reply-To: References: Message-ID: <92A6D55A-CCB9-4C00-8512-2A0E855B081B@gmail.com> For group lists and IM floaters, I'd personally prefer a name sort as primary, as any time I'm ever actually looking at the list, I'm looking for a specific individual. But in the group list, I can see the value of online status first, then by name (to see who's on) On Jun 5, 2011, at 9:43 AM, Jonathan Welch wrote: > When you open up the information for a group and get the list of > members, their role title, and their last active date none of those > columns are sorted by default. Should one be and if so, which one? > > Are there other tables like this that you can think of which would > benefit from being sorted (with some help I made this change for the > results in the World map)? > > -jonathan > _______________________________________________ > 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 Aleric.Inglewood at gmail.com Mon Jun 6 08:37:58 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Mon, 06 Jun 2011 15:37:58 -0000 Subject: [opensource-dev] Review Request: VWR-25862 Fix viewer caches not being cleared. In-Reply-To: <20110527200444.27676.96230@domU-12-31-38-00-90-68.compute-1.internal> References: <20110527200444.27676.96230@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110606153758.6471.79454@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/315/#review724 ----------------------------------------------------------- indra/newview/llvocache.cpp This patch removes (everywhere, not just here) the delimiter in front of 'mask' passed to deleteFilesInDir. deleteFilesInDir does nothing with mask but pass it to LLDirIterator. Apparently, the introduction of LLDirIterator (new in Viewer 2) requires mask to NOT start with a delimiter. However, you fail to correct this consistently; for example, in LLAppViewer::migrateCacheDirectory we have the following code: std::string mask = delimiter + "*.*"; LLDirIterator iter(old_cache_dir, mask); Can you explain that works (does it?) and the code that you changed didn't work? - Aleric On May 27, 2011, 1:04 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/315/ > ----------------------------------------------------------- > > (Updated May 27, 2011, 1:04 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch to fix the issues with clearing viewer caches documented in VWR-25862. I removed the leading delimiter in the place where each of the three caches are cleared. I also removed the mac specific deleteFilesInDir() method, which should have been removed for STORM-477. I removed unneeded calls to getDirDelimiter() in llvocache.cpp. > > > This addresses bugs vwr-25681 and vwr-25862. > http://jira.secondlife.com/browse/vwr-25681 > http://jira.secondlife.com/browse/vwr-25862 > > > Diffs > ----- > > indra/llvfs/lldir_mac.h UNKNOWN > indra/llvfs/lldir_mac.cpp UNKNOWN > indra/newview/llappviewer.cpp UNKNOWN > indra/newview/lltexturecache.cpp UNKNOWN > indra/newview/llvocache.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/315/diff > > > Testing > ------- > > Test plan: https://jira.secondlife.com/browse/VWR-25862?#comment-262800 > > I built and tested on Mac, Windows and Linux and saw the correct behavior when clicking the clear history button and the move cache button. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110606/ffec7aea/attachment.htm From jhwelch at gmail.com Mon Jun 6 09:37:33 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Mon, 6 Jun 2011 12:37:33 -0400 Subject: [opensource-dev] Minimum draw distance Message-ID: I have been working on a draw distance slider and realized this would be a good time to have a discussion about what the lowest value you can set your draw distance to should be. If you have an opinion of why it should be lowered from what it is now, 64, please reply to this message with your reasoning. Thank you, -Jonathan From holydoughnuts at gmail.com Mon Jun 6 09:52:17 2011 From: holydoughnuts at gmail.com (holydoughnuts) Date: Mon, 06 Jun 2011 12:52:17 -0400 Subject: [opensource-dev] Minimum draw distance In-Reply-To: References: Message-ID: <4DED05C1.60908@gmail.com> On 6/6/2011 12:37 PM, Jonathan Welch wrote: > I have been working on a draw distance slider and realized this would > be a good time to have a discussion about what the lowest value you > can set your draw distance to should be. > > If you have an opinion of why it should be lowered from what it is > now, 64, please reply to this message with your reasoning. > > Thank you, > > -Jonathan When I was stuck with seriously underpowered hardware, 24m was enough to let me get by in the busiest places, any less than that made the camera act wacky. It's still possible with RenderFarClip if there is no general desire to let the slider drop that far, so no huge deal. Why go that low? Because sometimes you've got to get inworld and do stuff, even when it can't look good, and even that nearsighted it's a lot easier to get things done than in a text based client. From arrehn at gmail.com Mon Jun 6 10:01:55 2011 From: arrehn at gmail.com (Arrehn Oberlander) Date: Mon, 6 Jun 2011 13:01:55 -0400 Subject: [opensource-dev] Minimum draw distance In-Reply-To: References: Message-ID: On Mon, Jun 6, 2011 at 12:37 PM, Jonathan Welch wrote: > ... > If you have an opinion of why it should be lowered from what it is > now, 64, please reply to this message with your reasoning. > > I'd say it is common for me to lower draw distance to 32, for densely populated events where the rendering of avatars alone, even with imposters, imposes a severe rendering burden and interferes with smooth behavior of stage effects, event effects, animations, etc. Less common but still about 1/week, I may have to reduce draw distance to zero briefly as a way to force texture refetches at a congested event. Typically this happens when an annoying threshhold of avatars I'm standing next to have seemingly permanently grey textures, because for whatever reason, their texture fetches failed when I initially arrived, perhaps due to poor bandwidth management/rescheduling. Despite the traffic that briefly reducing draw distance to zero may cause, in is highly reliable at filling on all previously grey textures that despite 10's of minutes of waiting, will not otherwise load. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110606/9c610589/attachment.htm From log at lindenlab.com Mon Jun 6 10:34:47 2011 From: log at lindenlab.com (Log Linden) Date: Mon, 06 Jun 2011 17:34:47 -0000 Subject: [opensource-dev] Review Request: VWR-25862 Fix viewer caches not being cleared. In-Reply-To: <20110606153758.6471.79454@domU-12-31-38-00-90-68.compute-1.internal> References: <20110606153758.6471.79454@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110606173447.6076.1947@domU-12-31-38-00-90-68.compute-1.internal> > On June 6, 2011, 8:37 a.m., Aleric Inglewood wrote: > > indra/newview/llvocache.cpp, lines 366-369 > > > > > > This patch removes (everywhere, not just here) the delimiter in front of 'mask' passed to deleteFilesInDir. > > > > deleteFilesInDir does nothing with mask but pass it to LLDirIterator. Apparently, the introduction of LLDirIterator (new in Viewer 2) requires mask to NOT start with a delimiter. > > > > However, you fail to correct this consistently; for example, in LLAppViewer::migrateCacheDirectory we have the following code: > > > > std::string mask = delimiter + "*.*"; > > > > LLDirIterator iter(old_cache_dir, mask); > > > > Can you explain that works (does it?) and the code that you changed didn't work? > > You're right, I checked the calls to deleteFilesInDir and fixed the ones that I felt able to reproduce and show that they were fixed. I reported the other calls to deleteFilesInDir that need to be fixed as subtasks of VWR-25861. I didn't check the other uses of LLDirIterator because I thought they would have been fixed when STORM-477 was merged. I'll fix what I can and report the others. Thanks - Log ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/315/#review724 ----------------------------------------------------------- On May 27, 2011, 1:04 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/315/ > ----------------------------------------------------------- > > (Updated May 27, 2011, 1:04 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch to fix the issues with clearing viewer caches documented in VWR-25862. I removed the leading delimiter in the place where each of the three caches are cleared. I also removed the mac specific deleteFilesInDir() method, which should have been removed for STORM-477. I removed unneeded calls to getDirDelimiter() in llvocache.cpp. > > > This addresses bugs vwr-25681 and vwr-25862. > http://jira.secondlife.com/browse/vwr-25681 > http://jira.secondlife.com/browse/vwr-25862 > > > Diffs > ----- > > indra/llvfs/lldir_mac.h UNKNOWN > indra/llvfs/lldir_mac.cpp UNKNOWN > indra/newview/llappviewer.cpp UNKNOWN > indra/newview/lltexturecache.cpp UNKNOWN > indra/newview/llvocache.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/315/diff > > > Testing > ------- > > Test plan: https://jira.secondlife.com/browse/VWR-25862?#comment-262800 > > I built and tested on Mac, Windows and Linux and saw the correct behavior when clicking the clear history button and the move cache button. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110606/e9c54da3/attachment-0001.htm From sythos at gmail.com Mon Jun 6 12:33:15 2011 From: sythos at gmail.com (Altair Memo) Date: Mon, 06 Jun 2011 19:33:15 -0000 Subject: [opensource-dev] Review Request: STORM-1103 Nearby sidebar minimap should be optional In-Reply-To: <20110514200727.22601.61704@domU-12-31-38-00-90-68.compute-1.internal> References: <20110514200727.22601.61704@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110606193315.6080.89988@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/265/#review726 ----------------------------------------------------------- Ship it! work fine on linux, nothing "evil" visible after some time of usage. - Altair On May 14, 2011, 1:07 p.m., Twisted Laws wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/265/ > ----------------------------------------------------------- > > (Updated May 14, 2011, 1:07 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Patch makes the map in the Nearby people tab optional with a menu option in the gear > menu. Patch is XML only and resizing of the map is disabled (user_resize="false" in > the layout_panels) as I could not find a way to easily save window sizes purely in XML. > Patch is in the repository of https://bitbucket.org/Twisted_Laws/viewer-development-storm-1103 as > https://bitbucket.org/Twisted_Laws/viewer-development-storm-1103/changeset/3455e79a14af > and https://bitbucket.org/Twisted_Laws/viewer-development-storm-1103/changeset/48b66643a4d1 > > > This addresses bug STORM-1103. > http://jira.secondlife.com/browse/STORM-1103 > > > Diffs > ----- > > doc/contributions.txt ee4d271eef9b > indra/newview/app_settings/settings.xml ee4d271eef9b > indra/newview/skins/default/xui/en/menu_people_nearby_view_sort.xml ee4d271eef9b > indra/newview/skins/default/xui/en/panel_people.xml ee4d271eef9b > > Diff: http://codereview.secondlife.com/r/265/diff > > > Testing > ------- > > Tested by exercising the gear menu option of "View Map" with the People tab attached > and detached insuring the map appears and disappears properly. > > > Thanks, > > Twisted > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110606/0ea5156a/attachment.htm From oz at lindenlab.com Mon Jun 6 12:46:05 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 06 Jun 2011 15:46:05 -0400 Subject: [opensource-dev] Minimum draw distance In-Reply-To: References: Message-ID: <4DED2E7D.9020305@lindenlab.com> On 2011-06-06 12:37, Jonathan Welch wrote: > I have been working on a draw distance slider and realized this would > be a good time to have a discussion about what the lowest value you > can set your draw distance to should be. > > If you have an opinion of why it should be lowered from what it is > now, 64, please reply to this message with your reasoning. There's a technical term for the above: "feature creep". Let's see if we can get the feature implemented and accepted, and then we can worry about changing the range. From Lance.Corrimal at eregion.de Mon Jun 6 13:02:26 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 6 Jun 2011 22:02:26 +0200 Subject: [opensource-dev] Minimum draw distance In-Reply-To: <4DED2E7D.9020305@lindenlab.com> References: <4DED2E7D.9020305@lindenlab.com> Message-ID: <201106062202.27064.Lance.Corrimal@eregion.de> Am Montag, 6. Juni 2011 schrieb Oz Linden (Scott Lawrence): > On 2011-06-06 12:37, Jonathan Welch wrote: > > I have been working on a draw distance slider and realized this > > would be a good time to have a discussion about what the lowest > > value you can set your draw distance to should be. > > > > If you have an opinion of why it should be lowered from what it > > is now, 64, please reply to this message with your reasoning. > > There's a technical term for the above: "feature creep". > > Let's see if we can get the feature implemented and accepted, and > then we can worry about changing the range. the draw distance slider has been a given in dolphin viewer 2, restrainedlove, and any viewer that uses a starlight skin... and people are loving it. bye, LC From trilobyte550m at gmail.com Mon Jun 6 15:12:27 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Mon, 6 Jun 2011 15:12:27 -0700 Subject: [opensource-dev] Minimum draw distance In-Reply-To: References: Message-ID: Vertical slider for the win! :-) I'm fine with existing settings, but given the large percentage of SL users that are using 'class 0' machines, I think a 48m or even 32m minimum would improve the experience and reduce the likelihood of crashing (especially at events or complex builds). On Jun 6, 2011, at 9:37 AM, Jonathan Welch wrote: > I have been working on a draw distance slider and realized this would > be a good time to have a discussion about what the lowest value you > can set your draw distance to should be. > > If you have an opinion of why it should be lowered from what it is > now, 64, please reply to this message with your reasoning. > > Thank you, > > -Jonathan > _______________________________________________ > 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 tateru at taterunino.net Mon Jun 6 20:00:32 2011 From: tateru at taterunino.net (Tateru Nino) Date: Tue, 07 Jun 2011 13:00:32 +1000 Subject: [opensource-dev] Review Request: Viewer cache size increase to 10GB. In-Reply-To: <20110604113239.6382.73922@domU-12-31-38-00-90-68.compute-1.internal> References: <20110603195650.14439.46763@domU-12-31-38-00-90-68.compute-1.internal> <20110604113239.6382.73922@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <4DED9450.4020302@taterunino.net> Not that I'm not glad to see the maximum cache size increased, but the cache cap was only very reluctantly increased to 1GB as the performance of the system increasingly suffered as the quantity of cached objects increased. How did we solve this? On 4/06/2011 9:32 PM, Oz Linden wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/318/ > > > Ship it! > > - Oz > > > On June 3rd, 2011, 12:56 p.m., Log Linden wrote: > > Review request for Viewer. > By Log Linden. > > /Updated June 3, 2011, 12:56 p.m./ > > > Description > > This patch increases the maximum and default viewer cache size values. Due to limitations in the size of the VFS, the 80/20 texture cache/VFS split is maintained up to 5GB, then the remaining cache size is given to the texture cache. This caps the VFS size at 1GB ( up from .2 GB ). I made corresponding changes to the XUI to allow the slider to increase to the new cache size maximum. > > Bugfixes: > * The reset cache location button will no longer tell the user that the cache will be cleared if the cache is already in the default location. Only the notification was suppressed, the cache was never cleared by this button unless the location changed. > * The reset cache location button will now correctly clear the old cache when it is reset back to the default location. > * I fixed an order of operation programming error in an llerrs log message in the lltexturecache.cpp. This was showing wildly incorrect texture cache size during a purge. > * Code convention cleanup in llappviewer.cpp in initCache() and lltexturecache.cpp > > > Testing > > I have built and tested on all three platforms. The log files indicate that the caches are being initialised with the correct sizes. > > *Bugs: * er-767 , er-883 > , er-883 > > > > Diffs > > * indra/newview/llappviewer.cpp (9c0506d10226) > * indra/newview/llfloaterpreference.cpp (9c0506d10226) > * indra/newview/lltexturecache.cpp (9c0506d10226) > * indra/newview/skins/default/xui/en/panel_preferences_setup.xml > (9c0506d10226) > > 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/20110607/30659b93/attachment.htm From monty at lindenlab.com Mon Jun 6 22:38:47 2011 From: monty at lindenlab.com (Monty Brandenberg) Date: Tue, 07 Jun 2011 01:38:47 -0400 Subject: [opensource-dev] Review Request: Viewer cache size increase to 10GB. In-Reply-To: <4DED9450.4020302@taterunino.net> References: <20110603195650.14439.46763@domU-12-31-38-00-90-68.compute-1.internal> <20110604113239.6382.73922@domU-12-31-38-00-90-68.compute-1.internal> <4DED9450.4020302@taterunino.net> Message-ID: <4DEDB967.9080808@lindenlab.com> On 6/6/2011 11:00 PM, Tateru Nino wrote: > Not that I'm not glad to see the maximum cache size increased, but the > cache cap was only very reluctantly increased to 1GB as the performance > of the system increasingly suffered as the quantity of cached objects > increased. > > How did we solve this? Different cache for the most part (we have many caches). This change mainly affects the *texture* cache. The general asset VFS cache is still capped for technical reasons. The scene caching is unchanged. We really want feedback on this on all platforms. Load up the texture cache, get your favorite regions in there, run around, clear the cache, do it again, etc. This work is being done under VWR-25182. Comments welcome and attach some jiras if you encounter problems. m From hitomi.tiponi at yahoo.co.uk Tue Jun 7 03:41:16 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Tue, 7 Jun 2011 11:41:16 +0100 (BST) Subject: [opensource-dev] Minimum draw distance Message-ID: <381099.80462.qm@web23902.mail.ird.yahoo.com> On 6/6/2011 12:37 PM, Jonathan Welch wrote: > I have been working on a draw distance slider and realized this would > be a good time to have a discussion about what the lowest value you > can set your draw distance to should be. > > If you have an opinion of why it should be lowered from what it is > now, 64, please reply to this message with your reasoning. > > Thank you, > > -Jonathan Yay - good to see that you guys are finally working on something that has been in the StarLight skin for over a year - please have a look at my xml code if you want. I did some experimentation with it a while back and found that 32 was a good minimum distance - if you go much lower you find that the camera behaves oddly when editing appearance. Also you have to think what you want as a maximum distance - I have chosen 992 because some people want to see a long way when sailing etc. (and it was highest multiple of 32 under 1000). Hitomi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110607/8fdba2ae/attachment.htm From log at lindenlab.com Tue Jun 7 11:42:34 2011 From: log at lindenlab.com (Log Linden) Date: Tue, 07 Jun 2011 18:42:34 -0000 Subject: [opensource-dev] Review Request: VWR-25965 LLDirIterator fixes in the viewer cache migration and VFS fallback. Message-ID: <20110607184234.6077.32210@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/324/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This removes additional leading delimiters in llappviewer needed due to the STORM-477 changes. This change should fix the fallback used when the viewer cannot find a VFS with the salt it expects to find and instead looks for any VFS data file in the cache directory to use. It also fixes cache directory migration code that runs on Mac and Windows every time the viewer is updated. This addresses bug VWR-25964. http://jira.secondlife.com/browse/VWR-25964 Diffs ----- indra/newview/llappviewer.cpp 1d4d568986e3 Diff: http://codereview.secondlife.com/r/324/diff Testing ------- Test Plan: https://jira.secondlife.com/browse/VWR-25965?focusedCommentId=264386 I ran Case 1 on Linux and Case 2 on Mac and Windows. Everything worked as expected. Thanks, Log -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110607/2d7bcc33/attachment.htm From sythos at gmail.com Tue Jun 7 13:44:35 2011 From: sythos at gmail.com (Altair Memo) Date: Tue, 07 Jun 2011 20:44:35 -0000 Subject: [opensource-dev] Review Request: VWR-25965 LLDirIterator fixes in the viewer cache migration and VFS fallback. In-Reply-To: <20110607184234.6077.32210@domU-12-31-38-00-90-68.compute-1.internal> References: <20110607184234.6077.32210@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110607204435.6500.78567@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/324/#review727 ----------------------------------------------------------- Ship it! work fine on linux, all test passed (no problem if cache is stored on ramdisk too, erased every reboot start fine each run) - Altair On June 7, 2011, 11:42 a.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/324/ > ----------------------------------------------------------- > > (Updated June 7, 2011, 11:42 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This removes additional leading delimiters in llappviewer needed due to the STORM-477 changes. This change should fix the fallback used when the viewer cannot find a VFS with the salt it expects to find and instead looks for any VFS data file in the cache directory to use. It also fixes cache directory migration code that runs on Mac and Windows every time the viewer is updated. > > > This addresses bug VWR-25964. > http://jira.secondlife.com/browse/VWR-25964 > > > Diffs > ----- > > indra/newview/llappviewer.cpp 1d4d568986e3 > > Diff: http://codereview.secondlife.com/r/324/diff > > > Testing > ------- > > Test Plan: > https://jira.secondlife.com/browse/VWR-25965?focusedCommentId=264386 > > I ran Case 1 on Linux and Case 2 on Mac and Windows. Everything worked as expected. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110607/1d2a6d1d/attachment.htm From jhwelch at gmail.com Tue Jun 7 14:32:37 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Tue, 07 Jun 2011 21:32:37 -0000 Subject: [opensource-dev] Review Request: STORM-899 'No attachments worn' text on blank 'Attachments' accordion remains in English for all locales Message-ID: <20110607213237.6081.29399@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/326/ ----------------------------------------------------------- Review request for Viewer. Summary ------- 1. Launch viewer, change language to German for example. 2. Re-login, open COF for edit. 3. Open 'Attachments' accordion, delete all objects. ===> Actual: 'No attachments worn' text appears in English. This addresses bug STORM-899. http://jira.secondlife.com/browse/STORM-899 Diffs ----- doc/contributions.txt c0c940514b74 indra/newview/llcofwearables.cpp c0c940514b74 indra/newview/skins/default/xui/en/panel_cof_wearables.xml c0c940514b74 indra/newview/skins/default/xui/en/strings.xml c0c940514b74 Diff: http://codereview.secondlife.com/r/326/diff Testing ------- Opened this tab with the viewer in English and also in French. I saw the same message, but that is because there is no translation for French, but it shows the call for a translation is working. What I am not sure of is if I made fix in the right way. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110607/5d002ed8/attachment.htm From Ima.Mechanique at blueyonder.co.uk Tue Jun 7 14:37:29 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Tue, 07 Jun 2011 21:37:29 -0000 Subject: [opensource-dev] Review Request: Adding ability for Prebuilt.cmake to pass necessary additional options to 'autobuild install' Message-ID: <20110607213729.6076.17408@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/327/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This is primarily to allow the passing of '--config-file file-name' through cmake, so that 'autobuild configure' can work correctly. The options are passed by adding -- -DAUTOBUILD_EXTRA_ARGS:STRING=options-to-add to the end of the configure command. e.g. autobuild configure --config-file ab-custom.xml -c ReleaseOS -- -DAUTOBUILD_EXTRA_ARGS:STRING=--config-file=ab-custom.xml Thanks to Brad Linden, for most of the work. This addresses bugs OPEN-76 and OPEN-77. http://jira.secondlife.com/browse/OPEN-76 http://jira.secondlife.com/browse/OPEN-77 Diffs ----- indra/cmake/Prebuilt.cmake 1d4d568986e3 Diff: http://codereview.secondlife.com/r/327/diff Testing ------- Successfully configured and built the viewer with a custom configuration and no autobuild.xml present. Thanks, Ima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110607/636f6a8e/attachment.htm From Ima.Mechanique at blueyonder.co.uk Tue Jun 7 15:03:31 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Tue, 07 Jun 2011 22:03:31 -0000 Subject: [opensource-dev] Review Request: OPEN-78 Automate the process of passing additional arguments to prebuilt.cmake Message-ID: <20110607220331.6081.71898@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/331/ ----------------------------------------------------------- Review request for Viewer. Summary ------- The fix in OPEN-77 allows configure to run correctly, but is cumbersome and not exactly pretty on the command line ;-) This fix allows autobuild itself, to automatically add the --config-file option when it determines the default (autobuild.xml) is not being used. This addresses bugs OPEN-76 and OPEN-78. http://jira.secondlife.com/browse/OPEN-76 http://jira.secondlife.com/browse/OPEN-78 Diffs ----- autobuild/autobuild_tool_configure.py 2a560b1d8f95 Diff: http://codereview.secondlife.com/r/331/diff Testing ------- Configure and built viewer-development with custom configuration and no default file present. Thanks, Ima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110607/ba2de326/attachment.htm From Ima.Mechanique at blueyonder.co.uk Tue Jun 7 15:17:17 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Tue, 07 Jun 2011 22:17:17 -0000 Subject: [opensource-dev] Review Request: OPEN-77 Adding ability for Prebuilt.cmake to pass necessary additional options to 'autobuild install' In-Reply-To: <20110607213729.6076.17408@domU-12-31-38-00-90-68.compute-1.internal> References: <20110607213729.6076.17408@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110607221717.6079.98890@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/327/ ----------------------------------------------------------- (Updated June 7, 2011, 3:17 p.m.) Review request for Viewer. Changes ------- Updated diff (includes contributions.txt change now) and summary (to include jira number). Summary (updated) ------- This is primarily to allow the passing of '--config-file file-name' through cmake, so that 'autobuild configure' can work correctly. The options are passed by adding -- -DAUTOBUILD_EXTRA_ARGS:STRING=options-to-add to the end of the configure command. e.g. autobuild configure --config-file ab-custom.xml -c ReleaseOS -- -DAUTOBUILD_EXTRA_ARGS:STRING=--config-file=ab-custom.xml Thanks to Brad Linden, for most of the work. This addresses bugs OPEN-76 and OPEN-77. http://jira.secondlife.com/browse/OPEN-76 http://jira.secondlife.com/browse/OPEN-77 Diffs (updated) ----- doc/contributions.txt 1d4d568986e3 indra/cmake/Prebuilt.cmake 1d4d568986e3 Diff: http://codereview.secondlife.com/r/327/diff Testing ------- Successfully configured and built the viewer with a custom configuration and no autobuild.xml present. Thanks, Ima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110607/3046df69/attachment-0001.htm From sllists at boroon.dasgupta.ch Tue Jun 7 16:06:19 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 07 Jun 2011 23:06:19 -0000 Subject: [opensource-dev] Review Request: OPEN-77 Adding ability for Prebuilt.cmake to pass necessary additional options to 'autobuild install' In-Reply-To: <20110607221717.6079.98890@domU-12-31-38-00-90-68.compute-1.internal> References: <20110607221717.6079.98890@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110607230619.6074.4640@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/327/#review731 ----------------------------------------------------------- Ship it! Looks good. indra/cmake/Prebuilt.cmake It looks like currently, the call to autobuild install is the only call from CMake back to autobuild. If we plan to ever add more back-calls (I don't think we do nor should), we should think about whether all back-calls will take the same extra arguments. If not, better give a specific name here, like AUTOBUILD_INSTALL_EXTRA_ARGS, so they can be distinguished. - Boroondas On June 7, 2011, 3:17 p.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/327/ > ----------------------------------------------------------- > > (Updated June 7, 2011, 3:17 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is primarily to allow the passing of '--config-file file-name' through cmake, so that 'autobuild configure' can work correctly. > The options are passed by adding -- -DAUTOBUILD_EXTRA_ARGS:STRING=options-to-add to the end of the configure command. > e.g. autobuild configure --config-file ab-custom.xml -c ReleaseOS -- -DAUTOBUILD_EXTRA_ARGS:STRING=--config-file=ab-custom.xml > Thanks to Brad Linden, for most of the work. > > > This addresses bugs OPEN-76 and OPEN-77. > http://jira.secondlife.com/browse/OPEN-76 > http://jira.secondlife.com/browse/OPEN-77 > > > Diffs > ----- > > doc/contributions.txt 1d4d568986e3 > indra/cmake/Prebuilt.cmake 1d4d568986e3 > > Diff: http://codereview.secondlife.com/r/327/diff > > > Testing > ------- > > Successfully configured and built the viewer with a custom configuration and no autobuild.xml present. > > > Thanks, > > Ima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110607/8e588e2f/attachment.htm From sllists at boroon.dasgupta.ch Tue Jun 7 17:36:17 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 08 Jun 2011 00:36:17 -0000 Subject: [opensource-dev] Review Request: OPEN-78 Automate the process of passing additional arguments to prebuilt.cmake In-Reply-To: <20110607220331.6081.71898@domU-12-31-38-00-90-68.compute-1.internal> References: <20110607220331.6081.71898@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110608003617.6076.42919@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/331/#review732 ----------------------------------------------------------- It should be noted that this fix depends on your OPEN-77 implementation (being reviewed at http://codereview.secondlife.com/r/327/ ) and should not be pulled without that. autobuild/autobuild_tool_configure.py Don't forget that file UNIX filesystems are case sensitive. Even worse, the fact that GNU make looks first for a file named 'makefile' then for one named 'Makefile' makes it common that projects ship with a 'makefile' file, and the user would then create a 'Makefile' file to override that, if wanted. That might inspire Mac/Linux users to use Autobuild.xml or some other capitalization variation for their own autobuild config file. Luckily, there's a http://docs.python.org/library/os.path.html#os.path.normcase , which does just what we want here. autobuild/autobuild_tool_configure.py somelist[0:0] = [something] might be more readable rewritten as somelist.insert(0, something) (Though maybe that's just a matter of different taste. I dunno whether somelist[0:0] is a common idiom in python ... but it had me think twice before I realized it was simply used for prepending) Because args.config_file is appended at the end, you might want to use the string concatenation operator (+) rather than substitution: 'foo%s' % bar is the same as 'foo' + bar So this line could become args.additional_options.insert(0, '-DAUTOBUILD_EXTRA_ARGS:STRING=--config-file=' + args.config_file) (Maybe this should be broken into two lines.) - Boroondas On June 7, 2011, 3:03 p.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/331/ > ----------------------------------------------------------- > > (Updated June 7, 2011, 3:03 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > The fix in OPEN-77 allows configure to run correctly, but is cumbersome and not exactly pretty on the command line ;-) > This fix allows autobuild itself, to automatically add the --config-file option when it determines the default (autobuild.xml) is not being used. > > > This addresses bugs OPEN-76 and OPEN-78. > http://jira.secondlife.com/browse/OPEN-76 > http://jira.secondlife.com/browse/OPEN-78 > > > Diffs > ----- > > autobuild/autobuild_tool_configure.py 2a560b1d8f95 > > Diff: http://codereview.secondlife.com/r/331/diff > > > Testing > ------- > > Configure and built viewer-development with custom configuration and no default file present. > > > Thanks, > > Ima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110608/d86e195a/attachment-0001.htm From sllists at boroon.dasgupta.ch Tue Jun 7 17:40:58 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 08 Jun 2011 00:40:58 -0000 Subject: [opensource-dev] Review Request: OPEN-78 Automate the process of passing additional arguments to prebuilt.cmake In-Reply-To: <20110608003617.6076.42919@domU-12-31-38-00-90-68.compute-1.internal> References: <20110608003617.6076.42919@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110608004058.9378.8864@domU-12-31-38-00-90-68.compute-1.internal> > On June 7, 2011, 5:36 p.m., Boroondas Gupte wrote: > > autobuild/autobuild_tool_configure.py, line 69 > > > > > > Don't forget that file UNIX filesystems are case sensitive. Even worse, the fact that GNU make looks first for a file named 'makefile' then for one named 'Makefile' makes it common that projects ship with a 'makefile' file, and the user would then create a 'Makefile' file to override that, if wanted. That might inspire Mac/Linux users to use Autobuild.xml or some other capitalization variation for their own autobuild config file. > > > > Luckily, there's a http://docs.python.org/library/os.path.html#os.path.normcase , which does just what we want here. meh, got GNU make's search order mixed up, but I guess you know what I mean. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/331/#review732 ----------------------------------------------------------- On June 7, 2011, 3:03 p.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/331/ > ----------------------------------------------------------- > > (Updated June 7, 2011, 3:03 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > The fix in OPEN-77 allows configure to run correctly, but is cumbersome and not exactly pretty on the command line ;-) > This fix allows autobuild itself, to automatically add the --config-file option when it determines the default (autobuild.xml) is not being used. > > > This addresses bugs OPEN-76 and OPEN-78. > http://jira.secondlife.com/browse/OPEN-76 > http://jira.secondlife.com/browse/OPEN-78 > > > Diffs > ----- > > autobuild/autobuild_tool_configure.py 2a560b1d8f95 > > Diff: http://codereview.secondlife.com/r/331/diff > > > Testing > ------- > > Configure and built viewer-development with custom configuration and no default file present. > > > Thanks, > > Ima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110608/9c85a46d/attachment.htm From oz at lindenlab.com Tue Jun 7 19:07:40 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 08 Jun 2011 02:07:40 -0000 Subject: [opensource-dev] Review Request: OPEN-77 Adding ability for Prebuilt.cmake to pass necessary additional options to 'autobuild install' In-Reply-To: <20110607221717.6079.98890@domU-12-31-38-00-90-68.compute-1.internal> References: <20110607221717.6079.98890@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110608020740.6077.47050@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/327/#review734 ----------------------------------------------------------- This should not be needed, and is not a good general way to solve the problem. See comment in the jira: https://jira.secondlife.com/browse/OPEN-76?focusedCommentId=264587&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-264587 - Oz On June 7, 2011, 3:17 p.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/327/ > ----------------------------------------------------------- > > (Updated June 7, 2011, 3:17 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is primarily to allow the passing of '--config-file file-name' through cmake, so that 'autobuild configure' can work correctly. > The options are passed by adding -- -DAUTOBUILD_EXTRA_ARGS:STRING=options-to-add to the end of the configure command. > e.g. autobuild configure --config-file ab-custom.xml -c ReleaseOS -- -DAUTOBUILD_EXTRA_ARGS:STRING=--config-file=ab-custom.xml > Thanks to Brad Linden, for most of the work. > > > This addresses bugs OPEN-76 and OPEN-77. > http://jira.secondlife.com/browse/OPEN-76 > http://jira.secondlife.com/browse/OPEN-77 > > > Diffs > ----- > > doc/contributions.txt 1d4d568986e3 > indra/cmake/Prebuilt.cmake 1d4d568986e3 > > Diff: http://codereview.secondlife.com/r/327/diff > > > Testing > ------- > > Successfully configured and built the viewer with a custom configuration and no autobuild.xml present. > > > Thanks, > > Ima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110608/4ed25aa2/attachment.htm From oz at lindenlab.com Wed Jun 8 04:36:29 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 08 Jun 2011 11:36:29 -0000 Subject: [opensource-dev] Review Request: OPEN-77 Adding ability for Prebuilt.cmake to pass necessary additional options to 'autobuild install' In-Reply-To: <20110608020740.6077.47050@domU-12-31-38-00-90-68.compute-1.internal> References: <20110608020740.6077.47050@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110608113629.6077.33137@domU-12-31-38-00-90-68.compute-1.internal> > On June 7, 2011, 7:07 p.m., Oz Linden wrote: > > This should not be needed, and is not a good general way to solve the problem. > > > > See comment in the jira: https://jira.secondlife.com/browse/OPEN-76?focusedCommentId=264587&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-264587 even more specifically, here's the changeset that added the environment variable: http://bitbucket.org/lindenlab/autobuild/changeset/ff4b1c11908f - Oz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/327/#review734 ----------------------------------------------------------- On June 7, 2011, 3:17 p.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/327/ > ----------------------------------------------------------- > > (Updated June 7, 2011, 3:17 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is primarily to allow the passing of '--config-file file-name' through cmake, so that 'autobuild configure' can work correctly. > The options are passed by adding -- -DAUTOBUILD_EXTRA_ARGS:STRING=options-to-add to the end of the configure command. > e.g. autobuild configure --config-file ab-custom.xml -c ReleaseOS -- -DAUTOBUILD_EXTRA_ARGS:STRING=--config-file=ab-custom.xml > Thanks to Brad Linden, for most of the work. > > > This addresses bugs OPEN-76 and OPEN-77. > http://jira.secondlife.com/browse/OPEN-76 > http://jira.secondlife.com/browse/OPEN-77 > > > Diffs > ----- > > doc/contributions.txt 1d4d568986e3 > indra/cmake/Prebuilt.cmake 1d4d568986e3 > > Diff: http://codereview.secondlife.com/r/327/diff > > > Testing > ------- > > Successfully configured and built the viewer with a custom configuration and no autobuild.xml present. > > > Thanks, > > Ima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110608/6f8f446c/attachment.htm From Aleric.Inglewood at gmail.com Wed Jun 8 04:47:35 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Wed, 08 Jun 2011 11:47:35 -0000 Subject: [opensource-dev] Review Request: VWR-25965 LLDirIterator fixes in the viewer cache migration and VFS fallback. In-Reply-To: <20110607184234.6077.32210@domU-12-31-38-00-90-68.compute-1.internal> References: <20110607184234.6077.32210@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110608114735.6074.70417@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/324/#review736 ----------------------------------------------------------- Ship it! - Aleric On June 7, 2011, 11:42 a.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/324/ > ----------------------------------------------------------- > > (Updated June 7, 2011, 11:42 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This removes additional leading delimiters in llappviewer needed due to the STORM-477 changes. This change should fix the fallback used when the viewer cannot find a VFS with the salt it expects to find and instead looks for any VFS data file in the cache directory to use. It also fixes cache directory migration code that runs on Mac and Windows every time the viewer is updated. > > > This addresses bug VWR-25964. > http://jira.secondlife.com/browse/VWR-25964 > > > Diffs > ----- > > indra/newview/llappviewer.cpp 1d4d568986e3 > > Diff: http://codereview.secondlife.com/r/324/diff > > > Testing > ------- > > Test Plan: > https://jira.secondlife.com/browse/VWR-25965?focusedCommentId=264386 > > I ran Case 1 on Linux and Case 2 on Mac and Windows. Everything worked as expected. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110608/f8a67227/attachment-0001.htm From trilobyte550m at gmail.com Wed Jun 8 10:55:58 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 8 Jun 2011 10:55:58 -0700 Subject: [opensource-dev] Minimum draw distance In-Reply-To: <381099.80462.qm@web23902.mail.ird.yahoo.com> References: <381099.80462.qm@web23902.mail.ird.yahoo.com> Message-ID: <1426A70B-62F3-4671-8F36-1D26F762F6ED@gmail.com> I agree, I love having a slider. But I think this one's going to be a vertical slider, behaving something like the way the volume control does. Hopefully we'll get to take a peek soon :-) On Jun 7, 2011, at 3:41 AM, Hitomi Tiponi wrote: > On 6/6/2011 12:37 PM, Jonathan Welch wrote: > > I have been working on a draw distance slider and realized this would > > be a good time to have a discussion about what the lowest value you > > can set your draw distance to should be. > > > > If you have an opinion of why it should be lowered from what it is > > now, 64, please reply to this message with your reasoning. > > > > Thank you, > > > > -Jonathan > > Yay - good to see that you guys are finally working on something that has been in the StarLight skin for over a year - please have a look at my xml code if you want. > > I did some experimentation with it a while back and found that 32 was a good minimum distance - if you go much lower you find that the camera behaves oddly when editing appearance. Also you have to think what you want as a maximum distance - I have chosen 992 because some people want to see a long way when sailing etc. (and it was highest multiple of 32 under 1000). > > Hitomi > _______________________________________________ > 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/20110608/a1be64e0/attachment.htm From jhwelch at gmail.com Thu Jun 9 09:56:20 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 09 Jun 2011 16:56:20 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam Message-ID: <20110609165620.6514.70030@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/333/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. ---- Ways to reproduce: log into a simulator. Reproduces: always Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). What happens: In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing Expected: On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). ---- going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. This addresses bug VWR-25923. http://jira.secondlife.com/browse/VWR-25923 Diffs ----- doc/contributions.txt a36a329e77cc indra/newview/llvoicevivox.h a36a329e77cc indra/newview/llvoicevivox.cpp a36a329e77cc Diff: http://codereview.secondlife.com/r/333/diff Testing ------- Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110609/3b4c885b/attachment.htm From oz at lindenlab.com Thu Jun 9 12:00:38 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 09 Jun 2011 15:00:38 -0400 Subject: [opensource-dev] Minimum draw distance In-Reply-To: <1426A70B-62F3-4671-8F36-1D26F762F6ED@gmail.com> References: <381099.80462.qm@web23902.mail.ird.yahoo.com> <1426A70B-62F3-4671-8F36-1D26F762F6ED@gmail.com> Message-ID: <4DF11856.60908@lindenlab.com> On 2011-06-08 13:55, Trilo Byte wrote: > I agree, I love having a slider. But I think this one's going to be a > vertical slider, behaving something like the way the volume control > does. Hopefully we'll get to take a peek soon :-) here's the review viewer: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-3/rev/232119/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110609/902b81ae/attachment.htm From sythos at gmail.com Thu Jun 9 13:48:14 2011 From: sythos at gmail.com (Altair Memo) Date: Thu, 09 Jun 2011 20:48:14 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110609165620.6514.70030@domU-12-31-38-00-90-68.compute-1.internal> References: <20110609165620.6514.70030@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110609204814.6077.92537@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/333/#review738 ----------------------------------------------------------- indra/newview/llvoicevivox.h I think is better put a comment (generic too) here about the meaning and usage of mRegionHasVoice indra/newview/llvoicevivox.cpp not sure is a nice choice remove the warn, a resident lose the only way to know if all work fine - Altair On June 9, 2011, 9:56 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 9:56 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt a36a329e77cc > indra/newview/llvoicevivox.h a36a329e77cc > indra/newview/llvoicevivox.cpp a36a329e77cc > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110609/39d4f0c4/attachment.htm From trilobyte550m at gmail.com Thu Jun 9 19:47:03 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Thu, 9 Jun 2011 19:47:03 -0700 Subject: [opensource-dev] Minimum draw distance In-Reply-To: <4DF11856.60908@lindenlab.com> References: <381099.80462.qm@web23902.mail.ird.yahoo.com> <1426A70B-62F3-4671-8F36-1D26F762F6ED@gmail.com> <4DF11856.60908@lindenlab.com> Message-ID: <434E828C-8C3B-46D7-96B8-65780700E942@gmail.com> Awesome slider! Works great on the mac client. Two things: 1) Needs a better icon (black on the dark gray UI is extremely difficult to make out) 2) PLEASE for the sake of all those poor class 0 machines, allow the minimum to be set to 32 or at least 48m This is going to make things easier for a lot of people :) On Jun 9, 2011, at 12:00 PM, Oz Linden (Scott Lawrence) wrote: > On 2011-06-08 13:55, Trilo Byte wrote: >> >> I agree, I love having a slider. But I think this one's going to be a vertical slider, behaving something like the way the volume control does. Hopefully we'll get to take a peek soon :-) > > here's the review viewer: > > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-3/rev/232119/index.html > _______________________________________________ > 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/20110609/b3e2dcaf/attachment.htm From opensourceobscure at gmail.com Fri Jun 10 01:16:14 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Fri, 10 Jun 2011 10:16:14 +0200 Subject: [opensource-dev] Minimum draw distance In-Reply-To: <434E828C-8C3B-46D7-96B8-65780700E942@gmail.com> References: <381099.80462.qm@web23902.mail.ird.yahoo.com> <1426A70B-62F3-4671-8F36-1D26F762F6ED@gmail.com> <4DF11856.60908@lindenlab.com> <434E828C-8C3B-46D7-96B8-65780700E942@gmail.com> Message-ID: On Fri, Jun 10, 2011 at 04:47, Trilo Byte wrote: > Awesome slider! ?Works great on the mac client. WOW. thanks for this. Also great how you can quickly reach Graphic Preferences, which I suspect are frequently changed by a relevant number of users. > Two things: > 1) Needs a better icon (black on the dark gray UI is extremely difficult to > make out) I like the icon itself but I agree on colors. > 2) PLEASE for the sake of all those poor class 0 machines, allow the minimum > to be set to 32 or at least 48m I agree. Also raise maximum to more than 512 as previously suggested in this discussion. Kudos! Opensource Obscure -- http://twitter.com/oobscure - http://opensourceobscure.com/lol discuss Second Life Viewer 2: http://j.mp/slv2group From Ima.Mechanique at blueyonder.co.uk Fri Jun 10 01:57:22 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Fri, 10 Jun 2011 08:57:22 -0000 Subject: [opensource-dev] Review Request: OPEN-76 Fix autobuild so that --config-file option is honoured by subsequent (possibly recursive) commands Message-ID: <20110610085722.6471.4209@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/335/ ----------------------------------------------------------- Review request for Viewer. Summary ------- When running a command such as: autobuild configure --config-file ab-test.xml -c ReleaseOS the configuration is only partially completed correctly. When the installables are processed, it does not use the correct configuration file. This is due to cmake calling autobuild install to do the actual install, but not passing the --config-file option. Autobuild falls back to the default autobuild.xml, because the correct configuration file is not saved at any point, which is not the intention and can cause configuration to be done with incorrect libraries. If autobuild.xml is missing or corrupt, an error occurs (which is how I discovered this), stopping the configure command. This fix saves the current value of the configuration file into the AUTOBUILD_CONFIG_FILE environmental variable so that it becomes the default value should any subsequent command need it. I believe that something like this was the original intention when adding this environment variable as part of the default check, but was overlooked. This addresses bug OPEN-76. http://jira.secondlife.com/browse/OPEN-76 Diffs ----- autobuild/configfile.py 2a560b1d8f95 Diff: http://codereview.secondlife.com/r/335/diff Testing ------- Ran 'autobuild configure --config-file ab-test.xml -c ReleaseOS' successfully without any errors and was able to build the expected viewer afterwards. Thanks, Ima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110610/ddbd8ac1/attachment-0001.htm From jhwelch at gmail.com Fri Jun 10 01:49:49 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 10 Jun 2011 04:49:49 -0400 Subject: [opensource-dev] Minimum draw distance In-Reply-To: References: <381099.80462.qm@web23902.mail.ird.yahoo.com> <1426A70B-62F3-4671-8F36-1D26F762F6ED@gmail.com> <4DF11856.60908@lindenlab.com> <434E828C-8C3B-46D7-96B8-65780700E942@gmail.com> Message-ID: The icon was just something I found and is a placeholder until a better-designed one can be generated. A friend testing this found what might be considered a bug which none of you advanced people would notice: when you click on the gear and am sent to the preferences window you do not see the advanced section with all the sliders for micro-adjustments unless at some point in the past you had already expanded your graphics panel past just the low-ultra slider. Is this something that should be forced? Just being sent to the graphics page and only seeing a slider is not quite what I would expect, though I can see both sides of this argument. -jonathan From sllists at boroon.dasgupta.ch Fri Jun 10 02:22:44 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 10 Jun 2011 09:22:44 -0000 Subject: [opensource-dev] Review Request: OPEN-76 Fix autobuild so that --config-file option is honoured by subsequent (possibly recursive) commands In-Reply-To: <20110610085722.6471.4209@domU-12-31-38-00-90-68.compute-1.internal> References: <20110610085722.6471.4209@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110610092244.17341.76284@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/335/#review739 ----------------------------------------------------------- autobuild/configfile.py I think the environment variable should be set right after this if-else block (which I think is the only place where self.path is set or modified). Otherwise the environment variable might not be set although self.path is set. ... or set the environment variable in __init__, right after the self.__load(path) call. - Boroondas On June 10, 2011, 1:57 a.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/335/ > ----------------------------------------------------------- > > (Updated June 10, 2011, 1:57 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > When running a command such as: > > autobuild configure --config-file ab-test.xml -c ReleaseOS > > the configuration is only partially completed correctly. When the installables are processed, it does not use the correct configuration file. This is due to cmake calling autobuild install to do the actual install, but not passing the --config-file option. Autobuild falls back to the default autobuild.xml, because the correct configuration file is not saved at any point, which is not the intention and can cause configuration to be done with incorrect libraries. If autobuild.xml is missing or corrupt, an error occurs (which is how I discovered this), stopping the configure command. > > This fix saves the current value of the configuration file into the AUTOBUILD_CONFIG_FILE environmental variable so that it becomes the default value should any subsequent command need it. I believe that something like this was the original intention when adding this environment variable as part of the default check, but was overlooked. > > > This addresses bug OPEN-76. > http://jira.secondlife.com/browse/OPEN-76 > > > Diffs > ----- > > autobuild/configfile.py 2a560b1d8f95 > > Diff: http://codereview.secondlife.com/r/335/diff > > > Testing > ------- > > Ran 'autobuild configure --config-file ab-test.xml -c ReleaseOS' successfully without any errors and was able to build the expected viewer afterwards. > > > Thanks, > > Ima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110610/c0707edf/attachment.htm From latifer at streamgrid.net Fri Jun 10 02:31:27 2011 From: latifer at streamgrid.net (Latif Khalifa) Date: Fri, 10 Jun 2011 11:31:27 +0200 Subject: [opensource-dev] Minimum draw distance In-Reply-To: References: <381099.80462.qm@web23902.mail.ird.yahoo.com> <1426A70B-62F3-4671-8F36-1D26F762F6ED@gmail.com> <4DF11856.60908@lindenlab.com> <434E828C-8C3B-46D7-96B8-65780700E942@gmail.com> Message-ID: On Fri, Jun 10, 2011 at 10:49 AM, Jonathan Welch wrote: > A friend testing this found what might be considered a bug which none > of you advanced people would notice: when you click on the gear and am > sent to the preferences window you do not see the advanced section > with all the sliders for micro-adjustments unless at some point in the > past you had already expanded your graphics panel past just the > low-ultra slider. > > Is this something that should be forced? ?Just being sent to the > graphics page and only seeing a slider is not quite what I would > expect, though I can see both sides of this argument. I'd say keep it simple. They can open advanced on that panel they get sent to. The feature is very nice as is, I'd also like to see slider go down to 32. From jhwelch at gmail.com Fri Jun 10 02:36:02 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 10 Jun 2011 05:36:02 -0400 Subject: [opensource-dev] Minimum draw distance In-Reply-To: References: <381099.80462.qm@web23902.mail.ird.yahoo.com> <1426A70B-62F3-4671-8F36-1D26F762F6ED@gmail.com> <4DF11856.60908@lindenlab.com> <434E828C-8C3B-46D7-96B8-65780700E942@gmail.com> Message-ID: For those of you who were not at yesterday's Snowstorm scrum Wolf told us this feature is being evaluated. They 1) don't want the UI to be too complicated and 2) would like to merge Basic mode in with Advanced. From Ima.Mechanique at blueyonder.co.uk Fri Jun 10 02:47:31 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Fri, 10 Jun 2011 09:47:31 -0000 Subject: [opensource-dev] Review Request: OPEN-76 Fix autobuild so that --config-file option is honoured by subsequent (possibly recursive) commands In-Reply-To: <20110610085722.6471.4209@domU-12-31-38-00-90-68.compute-1.internal> References: <20110610085722.6471.4209@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110610094731.17341.70320@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/335/ ----------------------------------------------------------- (Updated June 10, 2011, 2:47 a.m.) Review request for Viewer. Changes ------- After discussing with Boroondas on IRC we concluded that __INIT__ is a more sensible place for the environment variable to be set, after __load has finished checking its validity. Summary ------- When running a command such as: autobuild configure --config-file ab-test.xml -c ReleaseOS the configuration is only partially completed correctly. When the installables are processed, it does not use the correct configuration file. This is due to cmake calling autobuild install to do the actual install, but not passing the --config-file option. Autobuild falls back to the default autobuild.xml, because the correct configuration file is not saved at any point, which is not the intention and can cause configuration to be done with incorrect libraries. If autobuild.xml is missing or corrupt, an error occurs (which is how I discovered this), stopping the configure command. This fix saves the current value of the configuration file into the AUTOBUILD_CONFIG_FILE environmental variable so that it becomes the default value should any subsequent command need it. I believe that something like this was the original intention when adding this environment variable as part of the default check, but was overlooked. This addresses bug OPEN-76. http://jira.secondlife.com/browse/OPEN-76 Diffs (updated) ----- autobuild/configfile.py 2a560b1d8f95 Diff: http://codereview.secondlife.com/r/335/diff Testing ------- Ran 'autobuild configure --config-file ab-test.xml -c ReleaseOS' successfully without any errors and was able to build the expected viewer afterwards. Thanks, Ima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110610/4a668a2a/attachment-0001.htm From oz at lindenlab.com Fri Jun 10 04:38:16 2011 From: oz at lindenlab.com (Oz Linden) Date: Fri, 10 Jun 2011 11:38:16 -0000 Subject: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up. In-Reply-To: <20110301165847.24776.99074@domU-12-31-38-00-90-68.compute-1.internal> References: <20110301165847.24776.99074@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110610113816.17341.21687@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/152/#review438 ----------------------------------------------------------- indra/newview/lltexlayer.h better to define an enum here rather than use a bool: "{ finalBake, lowresBake }" - Oz On March 1, 2011, 8:58 a.m., Thickbrick Sleaford wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/152/ > ----------------------------------------------------------- > > (Updated March 1, 2011, 8:58 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't send a AgentSetAppearance message. This can happen without the user being aware, leaving the avatar looking good on their screen, but not updated to the same outfit on other people's screens. The avatar will remain in that state until the user does something that causes a rebake (manually rebake or change outfit.) The solution here is to retry the upload after a small delay. > > What this diff changes: when a full-res upload fails, retry to upload it after a 5s delay, up to 5 times (in case the cap is available, last attempt is via the old asset store.) Also, some clearer log messages. This implements an old *FIX: comment: > // *FIX: retry upload after n seconds, asset server could be busy > > This isn't needed for low res uploads, because they don't block subsequent full-res uploads (mNeedsUpload isn't set to FALSE in LLTexLayerSetBuffer::doUpload in low-res uploads.) > > > This addresses bug VWR-24889. > http://jira.secondlife.com/browse/VWR-24889 > > > Diffs > ----- > > indra/newview/llassetuploadresponders.h 767feb16f05f > indra/newview/llassetuploadresponders.cpp 767feb16f05f > indra/newview/lltexlayer.h 767feb16f05f > indra/newview/lltexlayer.cpp 767feb16f05f > > Diff: http://codereview.secondlife.com/r/152/diff > > > Testing > ------- > > Attempted outfit changes using a problematic connection (not recently used outfits to avoid using cached bakes). Looked for "Baked full res texture upload for failed" log messages, observed the subsequent retries and successful upload for that region. Observed that eventually the fully-baked avatar is visible to other users. > > > Thanks, > > Thickbrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110610/8d41aa32/attachment.htm From jhwelch at gmail.com Fri Jun 10 05:02:45 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 10 Jun 2011 08:02:45 -0400 Subject: [opensource-dev] Review viewer -- draw distance slider Message-ID: In case you missed the message from Oz in a different thread here is the review viewer for the proposed draw distance slider: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-3/rev/232119/index.html There is a temporary binocular graphic next to volume slider where you access the control from. There is discussion within LL if this will be taken in. The concerns are for new residents 1) having too many options on the screen and 2) performance or experience issues if the slider is moved too far in either direction. Please write back with your feedback, -Jonathan From hitomi.tiponi at yahoo.co.uk Fri Jun 10 06:13:35 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Fri, 10 Jun 2011 14:13:35 +0100 (BST) Subject: [opensource-dev] Minimum draw distance Message-ID: <224896.87289.qm@web23908.mail.ird.yahoo.com> That's not bad :). My thoughts: * The range should start at 32 and move out further - make it jump in increments of 16 instead. * Slider should highlight when selected like with other sliders in preferences. * Replace icon with something better - and make it so that the distance is always shown in the status bar when slider is collapsed. * General point - am wondering why the sliders don't have the gear icon on a button like the rest of the interface does for consistency.I like the way the sliders are now next to the money - I kept the volume and media pop up when I was going to minimise a window before. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110610/ee21088f/attachment.htm From opensourceobscure at gmail.com Fri Jun 10 08:01:19 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Fri, 10 Jun 2011 17:01:19 +0200 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 14:02, Jonathan Welch wrote: > There is discussion within LL if this will be taken in. ?The concerns > are for new residents 1) having too many options on the screen and 2) > performance or experience issues if the slider is moved too far in > either direction. Since Basic mode is now available, I'm much less convinced than in the past by claims about having too many options on the screen in Advanced Mode. By definition, new residents switch to a more complicated user interface when they leave Basic mode - more complicated, and more useful/powerful. Opensource Obscure -- http://twitter.com/oobscure - http://opensourceobscure.com/lol discuss Second Life Viewer 2: http://j.mp/slv2group From trilobyte550m at gmail.com Fri Jun 10 13:15:41 2011 From: trilobyte550m at gmail.com (Trilo) Date: Fri, 10 Jun 2011 13:15:41 -0700 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: Message-ID: It's a little disturbing to me that someone within LL would not see this as a must-have feature. Without having access to the crash report data, my guess would be that a very significant portion of Viewer crashes are the result of the viewer getting overwhelmed by requests (often because someone has their draw distance up too high and then teleports to a complex build, or some similar variant). And if you spend any appreciable time in-world, it should become clear early on that changing the draw distance to suit the scene/location/event is essential to a good experience. At a party/event and things are getting laggy, drop the draw distance down. Taking to the skies and flying around the grid at altitude, or maybe setting up to take some great pictures, increase the draw distance. By having the control in an easy-to-reach spot, it makes using Second Life significantly easier for the overwhelming majority of users. And by having draw distance at easy reach, it lessens the need for less advanced users to have to click on the 'Advanced' button on the graphics tab of the preferences screen. I'd recommend that a ToolTip floater be added over the binoculars icon, to reduce or eliminate confusion. Something like "Adjust the distance from your avatar that the Viewer tries to draw (lower = faster/less lag, higher = longer load time)". It's a simple and intuitive control that uses very little screen space, and empowers residents to easily improve their viewer performance and SL experience. That's my 2 cents :-) On Fri, Jun 10, 2011 at 5:02 AM, Jonathan Welch wrote: > In case you missed the message from Oz in a different thread here is > the review viewer for the proposed draw distance slider: > > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-3/rev/232119/index.html > > There is a temporary binocular graphic next to volume slider where you > access the control from. > > There is discussion within LL if this will be taken in. The concerns > are for new residents 1) having too many options on the screen and 2) > performance or experience issues if the slider is moved too far in > either direction. > > Please write back with your feedback, > > -Jonathan > _______________________________________________ > 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 > -- ~Trilo~ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110610/4be75030/attachment.htm From hitomi.tiponi at yahoo.co.uk Fri Jun 10 13:35:38 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Fri, 10 Jun 2011 21:35:38 +0100 (BST) Subject: [opensource-dev] Review viewer - draw distance slider Message-ID: <991189.44644.qm@web23902.mail.ird.yahoo.com> Just knocked this up by modding the xml you did - see what you think Jonathan. http://farm3.static.flickr.com/2758/5819291026_895c9231da.jpg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110610/0da3cf51/attachment.htm From sythos at gmail.com Fri Jun 10 15:01:08 2011 From: sythos at gmail.com (Altair Sythos Memo) Date: Sat, 11 Jun 2011 00:01:08 +0200 Subject: [opensource-dev] new subtasks added to STORM-312 (was: 3D connexion devices on linux) In-Reply-To: <4DEA1056.3030000@boroon.dasgupta.ch> References: <20110604020349.84330354.sythos@gmail.com> <-1596093459512050577@unknownmsgid> <4DEA1056.3030000@boroon.dasgupta.ch> Message-ID: <20110611000108.33a23b21.sythos@gmail.com> On Sat, 04 Jun 2011 13:00:38 +0200 Boroondas Gupte wrote: > @Oz: Can you please investigate (or get someone to investigate) > whether a 3p-* repo for the linux libNDOFdev already exists > internally at LL and can be published? If none exists, yet, and we > thus have to create one for Jan's sources from scratch, I'd like > someone to walk me through the process of doing so. (Yes, I know > there are guides about that on the wiki, but I don't even know which > of the apparently several ones to follow.) no news? From trilobyte550m at gmail.com Fri Jun 10 16:22:19 2011 From: trilobyte550m at gmail.com (Trilo) Date: Fri, 10 Jun 2011 16:22:19 -0700 Subject: [opensource-dev] Review viewer - draw distance slider In-Reply-To: <991189.44644.qm@web23902.mail.ird.yahoo.com> References: <991189.44644.qm@web23902.mail.ird.yahoo.com> Message-ID: I think the icon may be less intuitive. Without taking a few minutes or knowing it was probably some kind of eye, I don't know that I would have figured it out (as it was, it took me a little while). Jonathan's binoculars (if done in white against the UI bgnd) ore maybe the inverse of this image... http://cdn4.iconfinder.com/data/icons/cc_mono_icon_set/blacks/48x48/eye.png On Fri, Jun 10, 2011 at 1:35 PM, Hitomi Tiponi wrote: > > Just knocked this up by modding the xml you did - see what you think > Jonathan. > > http://farm3.static.flickr.com/2758/5819291026_895c9231da.jpg > > _______________________________________________ > 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 > -- ~Trilo~ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110610/641d3a31/attachment.htm From jhwelch at gmail.com Fri Jun 10 16:36:53 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 10 Jun 2011 19:36:53 -0400 Subject: [opensource-dev] Review viewer - draw distance slider In-Reply-To: References: <991189.44644.qm@web23902.mail.ird.yahoo.com> Message-ID: Those binoculars were just something I picked up quickly not expecting they would be a permanent solution. Later I experimented with a few eyes, but 1) the color has to work in shades of grey and 2) has to be scaled down to 16px*16px, so oblong shapes don't fare very well. -jonathan From aklo at skyhighway.com Fri Jun 10 20:59:38 2011 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Fri, 10 Jun 2011 20:59:38 -0700 Subject: [opensource-dev] Review viewer -- draw distance slider Message-ID: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> Guys, the whole thing with the easily accessible slider for draw distance is really great! Inspiring, actually. It's almost enough to make me wanna try out the v2 viewer again. i hope the feature gets back-ported to Snowglobe v1 by someone better at that stuff than me. The binocs idea for the icon is the best! It's totally like the average person is going to think about it. And it's the way our eyes work. Maybe spend time coming up with the best binocs icon or icon loc so it doesn't get confused with what everybody sees for "search" everywhere, but i can't think of anything better unless it was a magnifying glass (also over-used), eyeglasses, or a telescope. Maybe somebody wants to look at a collection on the web of what camera mfrs put on their focus buttons? (Maybe just the word "ZOOM" instead of an image?) And, being able to pull it down as far as possible is a good thing. Sometimes in tight spaces with lots of avis anything else is just a waste. Or distraction. Or both. And however far out it can go, even for short periods or whatever would be awesome! There's the maps and then there's actually being able to *see* what's up. But one thing i don't think i've seen in the discussion, wouldn't it be a good idea to have an auto-reset take place on every tp? Have it go to some standard value that works pretty good most places, and it'll save forgetful or excited people problems. i mean, if the control is right there and easy to adjust, why not make it more useful than just improved eyesight? Thx again! You guys are great! - AK In case you missed the message from Oz in a different thread here is the review viewer for the proposed draw distance slider: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repooz_project-3/rev/232119/index.html There is a temporary binocular graphic next to volume slider where you access the control from. There is discussion within LL if this will be taken in. The concerns are for new residents 1) having too many options on the screen and 2) performance or experience issues if the slider is moved too far in either direction. Please write back with your feedback, -Jonathan _______________________________________________ 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 jhwelch at gmail.com Sat Jun 11 03:23:33 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Sat, 11 Jun 2011 06:23:33 -0400 Subject: [opensource-dev] Debug console changes -- feedback sought Message-ID: If you use the debug console (Ctrl+Shift+4) I would like your feedback on some changes I would like to make to it: 1) Widen the lines from 50% of the screen width to 75% 2) Reduce the spacing between lines from 8px to 1px 3) Swap the foreground and background colors (I am not sure how effective this change would be, maybe it would be better to leave the colors as-is). Please take a look at https://jira.secondlife.com/browse/VWR-25987 and comment. Thank you, -Jonathan From marinekelley at gmail.com Sat Jun 11 04:14:40 2011 From: marinekelley at gmail.com (Marine Kelley) Date: Sat, 11 Jun 2011 13:14:40 +0200 Subject: [opensource-dev] Debug console changes -- feedback sought In-Reply-To: References: Message-ID: Whoops once again I replied to Jonathan only instead of the whole list. Sorry about that. Here is what I tried to answer : It should be copiable and pastable ! The debug console is nigh useless without these two features. On 11/06/2011, Jonathan Welch wrote: > If you use the debug console (Ctrl+Shift+4) I would like your feedback > on some changes I would like to make to it: > 1) Widen the lines from 50% of the screen width to 75% > 2) Reduce the spacing between lines from 8px to 1px > 3) Swap the foreground and background colors (I am not sure how > effective this change would be, maybe it would be better to leave the > colors as-is). > > Please take a look at https://jira.secondlife.com/browse/VWR-25987 and > comment. > > Thank you, > > -Jonathan > _______________________________________________ > 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 jhwelch at gmail.com Sat Jun 11 05:08:26 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Sat, 11 Jun 2011 08:08:26 -0400 Subject: [opensource-dev] Debug console changes -- feedback sought In-Reply-To: References: Message-ID: The debug setting showconsoleWindow gives you a free-standing window with the same information scrolling by in it. In Windows I get a dos-type window, so copying and pasting is not as easy as it should be. > It should be copiable and pastable ! The debug console is nigh useless > without these two features. From hitomi.tiponi at yahoo.co.uk Sat Jun 11 05:17:18 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Sat, 11 Jun 2011 13:17:18 +0100 (BST) Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> Message-ID: <367710.12991.qm@web23908.mail.ird.yahoo.com> > Guys, the whole thing with the easily accessible slider for draw distance > is really great! Inspiring, actually. It's almost enough to make me > wanna try out the v2 viewer again. i hope the feature gets back-ported to > Snowglobe v1 by someone better at that stuff than me. There is a simplified version of this in some V1 TPVs - the code from that is simple enough to copy across, but I'm not doing anything with V1 :). >Maybe somebody wants to look at a >collection on the web of what camera mfrs put on their focus buttons? >(Maybe just the word "ZOOM" instead of an image?) But it doesn't actually 'zoom' - it just increases visibility which is why the binoculars or eye icon would be best. >And, being able to pull it down as far as possible is a good thing. >Sometimes in tight spaces with lots of avis anything else is just a waste. >Or distraction. Or both. And however far out it can go, even for short >periods or whatever would be awesome! There's the maps and then there's >actually being able to *see* what's up. But one thing i don't think i've >seen in the discussion, wouldn't it be a good idea to have an auto-reset >take place on every tp? Have it go to some standard value that works >pretty good most places, and it'll save forgetful or excited people >problems. i mean, if the control is right there and easy to adjust, why >not make it more useful than just improved eyesight? I've been running a version of this on Viewer 2 for over a year, and have received several comments back on it that have influenced the decision to set it at 32 to 992 on my Viewer skin. Below 32 the Viewer messes up sometimes and when you set it to 992 even in the Blake Sea with a decent PC it takes a while to rez, though the views are awesome - for most 512 would be the max they'd ever use. 'Reset after each TP' would be a real pain - I have found that I alter the setting a lot depending on where I am tping around between - with 128 being usual on scenic sims, 32 in clubs and 64 when shopping. >Thx again! You guys are great! Are you a Linden in disguise? :) ________________________________ From: "aklo at skyhighway.com" To: opensource-dev at lists.secondlife.com Cc: jhwelch at gmail.com; trilobyte550m at gmail.com; hitomi.tiponi at yahoo.co.uk; opensourceobscure at gmail.com; latifer at streamgrid.net; oz at lindenlab.com Sent: Sat, 11 June, 2011 4:59:38 Subject: [opensource-dev] Review viewer -- draw distance slider Guys, the whole thing with the easily accessible slider for draw distance is really great! Inspiring, actually. It's almost enough to make me wanna try out the v2 viewer again. i hope the feature gets back-ported to Snowglobe v1 by someone better at that stuff than me. The binocs idea for the icon is the best! It's totally like the average person is going to think about it. And it's the way our eyes work. Maybe spend time coming up with the best binocs icon or icon loc so it doesn't get confused with what everybody sees for "search" everywhere, but i can't think of anything better unless it was a magnifying glass (also over-used), eyeglasses, or a telescope. Maybe somebody wants to look at a collection on the web of what camera mfrs put on their focus buttons? (Maybe just the word "ZOOM" instead of an image?) And, being able to pull it down as far as possible is a good thing. Sometimes in tight spaces with lots of avis anything else is just a waste. Or distraction. Or both. And however far out it can go, even for short periods or whatever would be awesome! There's the maps and then there's actually being able to *see* what's up. But one thing i don't think i've seen in the discussion, wouldn't it be a good idea to have an auto-reset take place on every tp? Have it go to some standard value that works pretty good most places, and it'll save forgetful or excited people problems. i mean, if the control is right there and easy to adjust, why not make it more useful than just improved eyesight? Thx again! You guys are great! - AK In case you missed the message from Oz in a different thread here is the review viewer for the proposed draw distance slider: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repooz_project-3/rev/232119/index.html There is a temporary binocular graphic next to volume slider where you access the control from. There is discussion within LL if this will be taken in. The concerns are for new residents 1) having too many options on the screen and 2) performance or experience issues if the slider is moved too far in either direction. Please write back with your feedback, -Jonathan _______________________________________________ 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/20110611/40be1569/attachment.htm From marinekelley at gmail.com Sat Jun 11 05:17:53 2011 From: marinekelley at gmail.com (Marine Kelley) Date: Sat, 11 Jun 2011 14:17:53 +0200 Subject: [opensource-dev] Debug console changes -- feedback sought In-Reply-To: References: Message-ID: Guess we learn everyday. Thanks for that :) On 11/06/2011, Jonathan Welch wrote: > The debug setting showconsoleWindow gives you a free-standing window > with the same information scrolling by in it. > > In Windows I get a dos-type window, so copying and pasting is not as > easy as it should be. >> It should be copiable and pastable ! The debug console is nigh useless >> without these two features. > _______________________________________________ > 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 jhwelch at gmail.com Sat Jun 11 05:29:07 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Sat, 11 Jun 2011 08:29:07 -0400 Subject: [opensource-dev] Debug console changes -- feedback sought In-Reply-To: References: Message-ID: You have to do a viewer restart to get showconsoleWindow to display. There's also a command line switch for it. From carlo at alinoe.com Sat Jun 11 05:57:12 2011 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 11 Jun 2011 14:57:12 +0200 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> Message-ID: <20110611145712.51a0b0d9@hikaru.localdomain> If you like Snowglobe v1, then why aren't you using Singularity? http://www.singularityviewer.org/downloads It's been worked on hard to make it entirely Viewer 2 engine with a viewer 1 UI. It's perfect. It's also incredibly much faster due to other improvements ;) On Fri, 10 Jun 2011 20:59:38 -0700 aklo at skyhighway.com wrote: > Guys, the whole thing with the easily accessible slider for draw > distance is really great! Inspiring, actually. It's almost enough > to make me wanna try out the v2 viewer again. i hope the feature > gets back-ported to Snowglobe v1 by someone better at that stuff than > me. > > The binocs idea for the icon is the best! It's totally like the > average person is going to think about it. And it's the way our eyes > work. Maybe spend time coming up with the best binocs icon or icon > loc so it doesn't get confused with what everybody sees for "search" > everywhere, but i can't think of anything better unless it was a > magnifying glass (also over-used), eyeglasses, or a telescope. Maybe > somebody wants to look at a collection on the web of what camera mfrs > put on their focus buttons? (Maybe just the word "ZOOM" instead of an > image?) > > And, being able to pull it down as far as possible is a good thing. > Sometimes in tight spaces with lots of avis anything else is just a > waste. Or distraction. Or both. And however far out it can go, even > for short periods or whatever would be awesome! There's the maps and > then there's actually being able to *see* what's up. But one thing i > don't think i've seen in the discussion, wouldn't it be a good idea > to have an auto-reset take place on every tp? Have it go to some > standard value that works pretty good most places, and it'll save > forgetful or excited people problems. i mean, if the control is > right there and easy to adjust, why not make it more useful than just > improved eyesight? > > Thx again! You guys are great! > > - AK > > > In case you missed the message from Oz in a different thread here is > the review viewer for the proposed draw distance slider: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repooz_project-3/rev/232119/index.html > > There is a temporary binocular graphic next to volume slider where you > access the control from. > > There is discussion within LL if this will be taken in. The concerns > are for new residents 1) having too many options on the screen and 2) > performance or experience issues if the slider is moved too far in > either direction. > > Please write back with your feedback, > > -Jonathan > _______________________________________________ > 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 > > > _______________________________________________ > 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 -- Carlo Wood From josh at lindenlab.com Sat Jun 11 08:46:40 2011 From: josh at lindenlab.com (Joshua Bell) Date: Sat, 11 Jun 2011 08:46:40 -0700 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> Message-ID: On Fri, Jun 10, 2011 at 8:59 PM, wrote: > The binocs idea for the icon is the best! It's totally like the average > person is going to think about it. And it's the way our eyes work. I have serious concerns (based only on the screenshot posted earlier): * By elevating this option to the top bar, we would expect many more users to interact with the control than when it is buried in preferences. * Without textual cues, you rely on the users to associate the button with some meaning. While binoculars may be a good metaphor (and perhaps the best available), it's not a commonly used glyph. Contrast with play/pause/stop or speaker-as-volume, which are now nearly universal in audio controls. I would not expect many users to either go looking for it or easily understand what the control is affecting from just the icon. * In the mockup I've seen, the control will look similar and behave almost exactly like the nearby volume control. I would expect many novice users to click the icon by mistake, adjust the setting, then wonder why the volume didn't change, and thus leave the draw distance altered unexpectedly. * The negative side effects of setting a large draw distance are not obvious to most new users. By making the control so prominent, I would expect that many would discover the control, set it to the most aesthetically pleasing value (i.e. "see more stuff"), then forget about it and wonder why the world is suddenly reacting more sluggishly. I think it's a very cool idea and conceptually love the design, but please proceed with caution. At the risk of making the implementation more difficult, I'd suggest adding labels along the lines of "See More (Slower)" "See Less (Faster)" at the top/bottom of the slider to alleviate the confusion. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110611/f6174ad4/attachment-0001.htm From jhwelch at gmail.com Sat Jun 11 09:05:23 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Sat, 11 Jun 2011 12:05:23 -0400 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> Message-ID: I too am a bit worried that novice viewer users will hurt themselves with this slider in an easily accessible place. How about tying the presence of the control to only show when the Advanced menu has been enabled (in addition or instead of the warning labels Joshua has suggested)? Presumably someone who is smart enough to activate the Advanced menu has a better chance of knowing what they are doing. -jonathan From opensourceobscure at gmail.com Sat Jun 11 09:36:19 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Sat, 11 Jun 2011 18:36:19 +0200 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> Message-ID: On Sat, Jun 11, 2011 at 17:46, Joshua Bell wrote: > I think it's a very cool idea and conceptually love the design, but please > proceed with caution. At the risk of making the implementation more > difficult, I'd suggest adding labels along the lines of "See More (Slower)" > "See Less (Faster)" at the top/bottom of the slider to alleviate the > confusion. I added a first mockup image to https://jira.secondlife.com/browse/VWR-10307 https://jira.secondlife.com/secure/attachment/51182/DD-slider-with-info.jpg on a second thought, it could get even narrower by rewriting labels the following way: - See More (Fast) See Less (Slow) - Opensource Obscure -- http://twitter.com/oobscure - http://opensourceobscure.com/lol discuss Second Life Viewer 2: http://j.mp/slv2group From hitomi.tiponi at yahoo.co.uk Sat Jun 11 12:06:47 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Sat, 11 Jun 2011 20:06:47 +0100 (BST) Subject: [opensource-dev] Review viewer -- draw distance slider Message-ID: <719616.63116.qm@web23904.mail.ird.yahoo.com> Love OO's idea of the labels - that should do a lot to offset Josh's, very reasonable, concerns. Also - maybe move it the other side of the 'Lindens' fields to show that it isn't just another audio/media setting. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110611/9719eae3/attachment.htm From jhwelch at gmail.com Sat Jun 11 14:18:23 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Sat, 11 Jun 2011 17:18:23 -0400 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <719616.63116.qm@web23904.mail.ird.yahoo.com> References: <719616.63116.qm@web23904.mail.ird.yahoo.com> Message-ID: I added in the labels and have been thinking about i10n issues with them. Would be better to use a graphic or else have some other window appear with a warning message? From trilobyte550m at gmail.com Sat Jun 11 15:02:51 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Sat, 11 Jun 2011 15:02:51 -0700 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <20110611145712.51a0b0d9@hikaru.localdomain> References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> <20110611145712.51a0b0d9@hikaru.localdomain> Message-ID: <7A643B8F-5E16-4E0F-AA09-C2AA3A750437@web-pass.com> Today, novice users are already hurting themselves by a much larger measure. At the earliest stages, they're directed by other residents to click the advanced button and right away change the slider. Not only are they potentially hurting themselves with the slider, but there are a wide range of other controls they may not understand. I see it happen with great regularity in the small number of SL groups that I participate in, and have no doubts it's happening everywhere on the grid. Given the choice between binoculars and a speaker icon, I'm not that concerned that a newbie will choose the binoculars to change their volume, but someone without any ideas just wiggling buttons is a portential issue. As OO and I had mentioned previously, I think a tooltip floater with simple explanation will close the gap. If there's concern about it being "too advanced" for a novice to see at first glance (well, second... they've already survived basic mode), then make the control be enabled via a 'Show Slider' checkbox on the Preferences -> Graphics -> Advanced tab. For the majority of customers who spend any appreciable time using the viewer product, having that slider makes using the product easier. On Jun 11, 2011, at 5:57 AM, Carlo Wood wrote: > If you like Snowglobe v1, then why aren't you using > Singularity? http://www.singularityviewer.org/downloads > > It's been worked on hard to make it entirely Viewer 2 engine > with a viewer 1 UI. It's perfect. It's also incredibly > much faster due to other improvements ;) > > On Fri, 10 Jun 2011 20:59:38 -0700 > aklo at skyhighway.com wrote: > >> Guys, the whole thing with the easily accessible slider for draw >> distance is really great! Inspiring, actually. It's almost enough >> to make me wanna try out the v2 viewer again. i hope the feature >> gets back-ported to Snowglobe v1 by someone better at that stuff than >> me. >> >> The binocs idea for the icon is the best! It's totally like the >> average person is going to think about it. And it's the way our eyes >> work. Maybe spend time coming up with the best binocs icon or icon >> loc so it doesn't get confused with what everybody sees for "search" >> everywhere, but i can't think of anything better unless it was a >> magnifying glass (also over-used), eyeglasses, or a telescope. Maybe >> somebody wants to look at a collection on the web of what camera mfrs >> put on their focus buttons? (Maybe just the word "ZOOM" instead of an >> image?) >> >> And, being able to pull it down as far as possible is a good thing. >> Sometimes in tight spaces with lots of avis anything else is just a >> waste. Or distraction. Or both. And however far out it can go, even >> for short periods or whatever would be awesome! There's the maps and >> then there's actually being able to *see* what's up. But one thing i >> don't think i've seen in the discussion, wouldn't it be a good idea >> to have an auto-reset take place on every tp? Have it go to some >> standard value that works pretty good most places, and it'll save >> forgetful or excited people problems. i mean, if the control is >> right there and easy to adjust, why not make it more useful than just >> improved eyesight? >> >> Thx again! You guys are great! >> >> - AK >> >> >> In case you missed the message from Oz in a different thread here is >> the review viewer for the proposed draw distance slider: >> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repooz_project-3/rev/232119/index.html >> >> There is a temporary binocular graphic next to volume slider where you >> access the control from. >> >> There is discussion within LL if this will be taken in. The concerns >> are for new residents 1) having too many options on the screen and 2) >> performance or experience issues if the slider is moved too far in >> either direction. >> >> Please write back with your feedback, >> >> -Jonathan >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 > > > > -- > Carlo Wood > _______________________________________________ > 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 jhwelch at gmail.com Sat Jun 11 16:08:46 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Sat, 11 Jun 2011 19:08:46 -0400 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <7A643B8F-5E16-4E0F-AA09-C2AA3A750437@web-pass.com> References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> <20110611145712.51a0b0d9@hikaru.localdomain> <7A643B8F-5E16-4E0F-AA09-C2AA3A750437@web-pass.com> Message-ID: While testing the updated graphic I've been looking at the cautionary wording on the slider and am not happy with it. There is no good way to align the text so it looks nice in all languages and the width of the slider would have to be wide enough to support the longest word in whatever language that happens to be. I am thinking that a warning notification message could be sent if the draw distance is adjusted up past a certain threshold. Much more explanatory text could be put into this notice and it would also be i10n friendly. Warning: You have just set your draw distance to a large value. This may cause poor system response. From ima.mechanique at blueyonder.co.uk Sat Jun 11 16:53:39 2011 From: ima.mechanique at blueyonder.co.uk (Ima Mechanique) Date: Sun, 12 Jun 2011 00:53:39 +0100 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> Message-ID: <20110612002937.568A.5FD3A259@blueyonder.co.uk> > On Fri, Jun 10, 2011 at 8:59 PM, wrote: > > > The binocs idea for the icon is the best! It's totally like the average > > person is going to think about it. And it's the way our eyes work. > > > I have serious concerns (based only on the screenshot posted earlier): > * By elevating this option to the top bar, we would expect many more users > to interact with the control than when it is buried in preferences. Yes, but only those that need/choose to adjust their draw distance regularly. The same could be said of the volume control, which I adjust once to an appropriate level and never touch again. I expect I would use the draw distance more often and find it more useful on the top bar. > * Without textual cues, you rely on the users to associate the button with > some meaning. While binoculars may be a good metaphor (and perhaps the best > available), it's not a commonly used glyph. Contrast with play/pause/stop or > speaker-as-volume, which are now nearly universal in audio controls. I would > not expect many users to either go looking for it or easily understand what > the control is affecting from just the icon. Binoculars is a commonly use icon in some applications. However, it is used for "Find/Search" hence it being a temporary choice here for demonstration purposes until a custom icon can be made. I liked Hitomi's eye, but would prefer it without the radiating lines, too easy to confuse that with an active speaker icon at small sizes or on large monitors. > * In the mockup I've seen, the control will look similar and behave almost > exactly like the nearby volume control. I would expect many novice users to > click the icon by mistake, adjust the setting, then wonder why the volume > didn't change, and thus leave the draw distance altered unexpectedly. > * The negative side effects of setting a large draw distance are not obvious > to most new users. By making the control so prominent, I would expect that > many would discover the control, set it to the most aesthetically pleasing > value (i.e. "see more stuff"), then forget about it and wonder why the world > is suddenly reacting more sluggishly. Something best dealt with by education. The same problem exists with the current preferences, people will still ignore the recommended settings that SL sets up on startup, and turn up the quality. The only difference here is the ease with which it can be done. The same ease they have to turn it down again. Additionally this is only one setting, not all of those available in preferences. > I think it's a very cool idea and conceptually love the design, but please > proceed with caution. At the risk of making the implementation more > difficult, I'd suggest adding labels along the lines of "See More (Slower)" > "See Less (Faster)" at the top/bottom of the slider to alleviate the > confusion. Agreed. Given Jonathan's recent comment regarding the tooltip, keeping it simple (More/Slower, Less/Faster) might be an idea. -- Ima Mechanique ima.mechanique(at)blueyonder.co.uk From wolfpup67 at earthlink.net Sat Jun 11 19:58:10 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Sat, 11 Jun 2011 22:58:10 -0400 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> <20110611145712.51a0b0d9@hikaru.localdomain> <7A643B8F-5E16-4E0F-AA09-C2AA3A750437@web-pass.com> Message-ID: <000c01cc28ac$9042e1d0$b0c8a570$@net> I like the idea of a warning notification if you take the sliders above a certain distance plus you could even have the warning connected to the graphics levels. e.g.: low -> above 94m mid -> above 188m high -> above 512m ultra -> above 1024m these are just examples. Also instead of just saying system you could say viewer/system as sometimes you can affect viewer performance without affecting system performance. > -----Original Message----- > From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev- > bounces at lists.secondlife.com] On Behalf Of Jonathan Welch > Sent: Saturday, June 11, 2011 7:09 PM > Cc: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Review viewer -- draw distance slider > > While testing the updated graphic I've been looking at the cautionary > wording on the slider and am not happy with it. There is no good way > to align the text so it looks nice in all languages and the width of > the slider would have to be wide enough to support the longest word in > whatever language that happens to be. > > I am thinking that a warning notification message could be sent if the > draw distance is adjusted up past a certain threshold. Much more > explanatory text could be put into this notice and it would also be > i10n friendly. > > Warning: You have just set your draw distance to a large value. This > may cause poor system response. > _______________________________________________ > 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 > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1382 / Virus Database: 1513/3695 - Release Date: 06/11/11 From tateru at taterunino.net Sat Jun 11 21:17:53 2011 From: tateru at taterunino.net (Tateru Nino) Date: Sun, 12 Jun 2011 14:17:53 +1000 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> <20110611145712.51a0b0d9@hikaru.localdomain> <7A643B8F-5E16-4E0F-AA09-C2AA3A750437@web-pass.com> Message-ID: <4DF43DF1.9000908@taterunino.net> Use a tooltip for the text, and have it trigger as soon as the slider is interacted with, and persist for several seconds after. That way, there's informational text that follows the mouse cursor from the moment the user starts interacting with it, until they stop - and several seconds more. That should give you the space for a concise (but not overly brief) notification or explanatory message. On 12/06/2011 9:08 AM, Jonathan Welch wrote: > While testing the updated graphic I've been looking at the cautionary > wording on the slider and am not happy with it. There is no good way > to align the text so it looks nice in all languages and the width of > the slider would have to be wide enough to support the longest word in > whatever language that happens to be. > > I am thinking that a warning notification message could be sent if the > draw distance is adjusted up past a certain threshold. Much more > explanatory text could be put into this notice and it would also be > i10n friendly. > > Warning: You have just set your draw distance to a large value. This > may cause poor system response. > _______________________________________________ > 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 secret.argent at gmail.com Sun Jun 12 08:38:35 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 12 Jun 2011 10:38:35 -0500 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <367710.12991.qm@web23908.mail.ird.yahoo.com> References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> <367710.12991.qm@web23908.mail.ird.yahoo.com> Message-ID: <9A99577A-29B8-4B91-94A1-27BE4A14BF95@gmail.com> I think the icon should be a magnifying glass. From hitomi.tiponi at yahoo.co.uk Sun Jun 12 08:42:47 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Sun, 12 Jun 2011 16:42:47 +0100 (BST) Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <9A99577A-29B8-4B91-94A1-27BE4A14BF95@gmail.com> References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> <367710.12991.qm@web23908.mail.ird.yahoo.com> <9A99577A-29B8-4B91-94A1-27BE4A14BF95@gmail.com> Message-ID: <616610.85640.qm@web23904.mail.ird.yahoo.com> Trouble with that is that LL already have that symbol used for Search and also for Zoom on the World Map, and it isn't really a 'zoom' feature. ________________________________ From: Argent Stonecutter To: Hitomi Tiponi Cc: opensource-dev at lists.secondlife.com; aklo at skyhighway.com Sent: Sun, 12 June, 2011 16:38:35 Subject: Re: [opensource-dev] Review viewer -- draw distance slider I think the icon should be a magnifying glass. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110612/a9e32cf2/attachment-0001.htm From secret.argent at gmail.com Sun Jun 12 08:55:27 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 12 Jun 2011 10:55:27 -0500 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <616610.85640.qm@web23904.mail.ird.yahoo.com> References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> <367710.12991.qm@web23908.mail.ird.yahoo.com> <9A99577A-29B8-4B91-94A1-27BE4A14BF95@gmail.com> <616610.85640.qm@web23904.mail.ird.yahoo.com> Message-ID: On 2011-06-12, at 10:42, Hitomi Tiponi wrote: > Trouble with that is that LL already have that symbol [[magnifying glass]] used for Search and also for Zoom on the World Map, and it isn't really a 'zoom' feature. You're right. Suggestion withdrawn. From aklo at skyhighway.com Sun Jun 12 09:00:34 2011 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Sun, 12 Jun 2011 09:00:34 -0700 Subject: [opensource-dev] Review viewer -- draw distance slider Message-ID: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> Hi! i found a cool idea on a camera. It had a single large tree on one end of the focus setting and 4 small trees on the other end. i know the draw distance slider isn't a focus button, but how about a single house pic on one end and a small cluster of houses on the other? Or maybe a group of skyscrapers? Maybe that's too much for the number of pixels available? The trees thing on the camera button looks pretty good. If you wanna see it, look up online doc for a Canon SX10. Thx! - AK Trouble with that is that LL already have that symbol used for Search and also for Zoom on the World Map, and it isn't really a 'zoom' feature From: Argent Stonecutter To: Hitomi Tiponi Cc: opensource-dev at lists.secondlife.com; aklo at skyhighway.com Sent: Sun, 12 June, 2011 16:38:35 Subject: Re: [opensource-dev] Review viewer -- draw distance slider I think the icon should be a magnifying glass. From trilobyte550m at gmail.com Sun Jun 12 12:01:31 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Sun, 12 Jun 2011 12:01:31 -0700 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> <20110611145712.51a0b0d9@hikaru.localdomain> <7A643B8F-5E16-4E0F-AA09-C2AA3A750437@web-pass.com> Message-ID: Agreed regarding the magnifying glass icon - it's used both in SL and in some browsers as an icon representing Search. The problem with using a 1 tree/many trees approach is that a) that's already used to denote zoom, not viewing distance, and b) that type of display works best when it's on either side of the control in question (either side of the zoom rocker on a digital camera, for example. I like the binoculars icon idea, but agree that it could cause confusion since other applications commonly use the symbol for search. An eye icon has merit, since it controls how much the user sees. Given the 16x16 pixel constraint, I think the rays/lines coming off the eye would be less clear, and may cause some possible confusion with the speaker/volume icon (which is exactly what you want to avoid). Speaker icon for what you hear, eye for what you see, seems pretty straightforward, and a tooltip when moused over/used would further eliminate confusion. As for the notice to pop up when the setting gets raised too high, how about using "caution" in place of "warning". - subtle change in language makes the message read more like helpful guidance. On Jun 11, 2011, at 4:08 PM, Jonathan Welch wrote: > While testing the updated graphic I've been looking at the cautionary > wording on the slider and am not happy with it. There is no good way > to align the text so it looks nice in all languages and the width of > the slider would have to be wide enough to support the longest word in > whatever language that happens to be. > > I am thinking that a warning notification message could be sent if the > draw distance is adjusted up past a certain threshold. Much more > explanatory text could be put into this notice and it would also be > i10n friendly. > > Warning: You have just set your draw distance to a large value. This > may cause poor system response. > _______________________________________________ > 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 secret.argent at gmail.com Sun Jun 12 12:21:31 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 12 Jun 2011 14:21:31 -0500 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> <20110611145712.51a0b0d9@hikaru.localdomain> <7A643B8F-5E16-4E0F-AA09-C2AA3A750437@web-pass.com> Message-ID: <159392BE-53E8-4625-A08F-649D37EBE82C@gmail.com> How about a camera iris? From danielravennest at gmail.com Sun Jun 12 12:43:30 2011 From: danielravennest at gmail.com (Daniel) Date: Sun, 12 Jun 2011 14:43:30 -0500 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: Message-ID: <4DF516E2.3080704@gmail.com> What would directly tell people what the slider does is a ground outline on the terrain showing how far away items will be shown (similar to property lines ie shown directly on the ground). Along with things starting to appear or vanish as they play with the slider, there should be no confusion about the function. Along with that, provide a tooltip explaining the more area you see, the slower things will run. If you want to cover the case of people flying or in a skybox, do it as a temporary horizontal ~50% opaque red circle centered on the avatar, which persists for several seconds after moving the slider. From jhwelch at gmail.com Sun Jun 12 13:09:15 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Sun, 12 Jun 2011 20:09:15 -0000 Subject: [opensource-dev] Review Request: STORM-787 Mute Gestures Button Message-ID: <20110612200915.2648.31481@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/336/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Added a checkbox control in Preferences->Sound and Media (see attached image in jira) to enable/disable sounds coming from gestures. There is a long writeup in the jira for reasons to have this. This control is linked to 1) the master volume control and 2) the sound effects control. If either of these is disabled (speaker has a red line through it) the checkbox is disabled. This addresses bug STORM-787. http://jira.secondlife.com/browse/STORM-787 Diffs ----- doc/contributions.txt 6a3e7e403bd1 indra/newview/app_settings/settings.xml 6a3e7e403bd1 indra/newview/llfloaterpreference.h 6a3e7e403bd1 indra/newview/llfloaterpreference.cpp 6a3e7e403bd1 indra/newview/llviewermessage.cpp 6a3e7e403bd1 indra/newview/skins/default/xui/en/panel_preferences_sound.xml 6a3e7e403bd1 Diff: http://codereview.secondlife.com/r/336/diff Testing ------- Tested per test plan in jira. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110612/8611f817/attachment.htm From marinekelley at gmail.com Sun Jun 12 13:23:54 2011 From: marinekelley at gmail.com (Marine Kelley) Date: Sun, 12 Jun 2011 22:23:54 +0200 Subject: [opensource-dev] ER-480 fix brought a showstopper Message-ID: Hi all, Has anybody noticed this already ? Basically the current viewer in v-d has a malformed notifications.xml file, breaking it completely as soon as you raise the camera controls floater. https://jira.secondlife.com/browse/VWR-26000 If it hits viewer-release, this will become a showstopper right away. Suggest immediate fixin'. Marine From hitomi.tiponi at yahoo.co.uk Sun Jun 12 15:30:45 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Sun, 12 Jun 2011 23:30:45 +0100 (BST) Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> Message-ID: <360394.83545.qm@web23905.mail.ird.yahoo.com> /me looks forward to seeing someone draw this one in a 16x16 pixel grid :) ________________________________ From: "aklo at skyhighway.com" To: opensource-dev at lists.secondlife.com; hitomi.tiponi at yahoo.co.uk Cc: secret.argent at gmail.com Sent: Sun, 12 June, 2011 17:00:34 Subject: Re: [opensource-dev] Review viewer -- draw distance slider Hi! i found a cool idea on a camera. It had a single large tree on one end of the focus setting and 4 small trees on the other end. i know the draw distance slider isn't a focus button, but how about a single house pic on one end and a small cluster of houses on the other? Or maybe a group of skyscrapers? Maybe that's too much for the number of pixels available? The trees thing on the camera button looks pretty good. If you wanna see it, look up online doc for a Canon SX10. Thx! - AK Trouble with that is that LL already have that symbol used for Search and also for Zoom on the World Map, and it isn't really a 'zoom' feature From: Argent Stonecutter To: Hitomi Tiponi Cc: opensource-dev at lists.secondlife.com; aklo at skyhighway.com Sent: Sun, 12 June, 2011 16:38:35 Subject: Re: [opensource-dev] Review viewer -- draw distance slider I think the icon should be a magnifying glass. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110612/15eae57d/attachment.htm From secret.argent at gmail.com Sun Jun 12 17:58:54 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 12 Jun 2011 19:58:54 -0500 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <360394.83545.qm@web23905.mail.ird.yahoo.com> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <360394.83545.qm@web23905.mail.ird.yahoo.com> Message-ID: <6C6A223A-4E84-4161-ABBE-D7DBD604D8ED@gmail.com> On 2011-06-12, at 17:30, Hitomi Tiponi wrote: > /me looks forward to seeing someone draw this one in a 16x16 pixel grid :) I think three small pine trees could be rendered in a 16x16 grid. From hitomi.tiponi at yahoo.co.uk Mon Jun 13 02:49:55 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Mon, 13 Jun 2011 10:49:55 +0100 (BST) Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <6C6A223A-4E84-4161-ABBE-D7DBD604D8ED@gmail.com> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <360394.83545.qm@web23905.mail.ird.yahoo.com> <6C6A223A-4E84-4161-ABBE-D7DBD604D8ED@gmail.com> Message-ID: <645564.61817.qm@web23901.mail.ird.yahoo.com> Yes it's possible (see attached) - but something like that says 'landscape' or 'plants' to me. ________________________________ From: Argent Stonecutter To: Hitomi Tiponi Cc: aklo at skyhighway.com; opensource-dev at lists.secondlife.com Sent: Mon, 13 June, 2011 1:58:54 Subject: Re: [opensource-dev] Review viewer -- draw distance slider On 2011-06-12, at 17:30, Hitomi Tiponi wrote: > /me looks forward to seeing someone draw this one in a 16x16 pixel grid :) I think three small pine trees could be rendered in a 16x16 grid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110613/abd3d90e/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: three trees.png Type: image/png Size: 1056 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110613/abd3d90e/attachment-0001.png From opensourceobscure at gmail.com Mon Jun 13 03:14:11 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Mon, 13 Jun 2011 12:14:11 +0200 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <645564.61817.qm@web23901.mail.ird.yahoo.com> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <360394.83545.qm@web23905.mail.ird.yahoo.com> <6C6A223A-4E84-4161-ABBE-D7DBD604D8ED@gmail.com> <645564.61817.qm@web23901.mail.ird.yahoo.com> Message-ID: While clear, such an icon doesn't look much self-explaining to me with regard to its associated Draw Distance functionality. I still feel binoculars may be the best option. Binoculars may not be a commonly used glyph outside of SL, but it's a fact that many Second Life features are just .. not commonly used features. In most applications / online services / information environments or RL appliances, you just don't have the concept of "Draw Distance" or anything similar. On Mon, Jun 13, 2011 at 11:49, Hitomi Tiponi wrote: > Yes it's possible (see attached) - but something like that says 'landscape' > or 'plants' to me. > > ________________________________ > From: Argent Stonecutter > To: Hitomi Tiponi > Cc: aklo at skyhighway.com; opensource-dev at lists.secondlife.com > Sent: Mon, 13 June, 2011 1:58:54 > Subject: Re: [opensource-dev] Review viewer -- draw distance slider > > On 2011-06-12, at 17:30, Hitomi Tiponi wrote: >> /me looks forward to seeing someone draw this one in a 16x16 pixel grid :) > > I think three small pine trees could be rendered in a 16x16 grid. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- Opensource Obscure -- http://twitter.com/oobscure - http://opensourceobscure.com/lol discuss Second Life Viewer 2: http://j.mp/slv2group From carlo at alinoe.com Mon Jun 13 05:44:56 2011 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 13 Jun 2011 14:44:56 +0200 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <360394.83545.qm@web23905.mail.ird.yahoo.com> <6C6A223A-4E84-4161-ABBE-D7DBD604D8ED@gmail.com> <645564.61817.qm@web23901.mail.ird.yahoo.com> Message-ID: <20110613144456.629cfe2c@hikaru.localdomain> I think that no matter what you draw, the icon will not be clear to the majority of people. The icon only needs to be recognizable to those who saw it before. They will have to learn it's meaning from the tool tip imho. Nevertheless, binoculars are usually used for either zoom or search, so I think another icon would be better. Thinking about an avatar with a (half) sphere around it, I'd use as icon a circle with a dot in it, or a half circle with a vertical line in the center, ie: _ - _ . . / O \ ------|------ On Mon, 13 Jun 2011 12:14:11 +0200 Opensource Obscure wrote: > While clear, such an icon doesn't look much self-explaining to me > with regard to its associated Draw Distance functionality. > > I still feel binoculars may be the best option. > > Binoculars may not be a commonly used glyph outside of SL, > but it's a fact that many Second Life features are just .. not > commonly used features. In most applications / online services / > information environments or RL appliances, you just don't have the > concept of "Draw Distance" or anything similar. > > On Mon, Jun 13, 2011 at 11:49, Hitomi Tiponi > wrote: > > Yes it's possible (see attached) - but something like that says > > 'landscape' or 'plants' to me. > > > > ________________________________ > > From: Argent Stonecutter > > To: Hitomi Tiponi > > Cc: aklo at skyhighway.com; opensource-dev at lists.secondlife.com > > Sent: Mon, 13 June, 2011 1:58:54 > > Subject: Re: [opensource-dev] Review viewer -- draw distance slider > > > > On 2011-06-12, at 17:30, Hitomi Tiponi wrote: > >> /me looks forward to seeing someone draw this one in a 16x16 pixel > >> grid :) > > > > I think three small pine trees could be rendered in a 16x16 grid. > > > > _______________________________________________ > > 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 > > > > > -- Carlo Wood From oz at lindenlab.com Mon Jun 13 06:50:13 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 13 Jun 2011 09:50:13 -0400 Subject: [opensource-dev] Good project idea: Lightweight markup support for chat text Message-ID: <4DF61595.8080504@lindenlab.com> Haravikk Mistral filed an interesting suggestion that we support markup for formatting text similar to what most wikis (and our jira) support: https://jira.secondlife.com/browse/VWR-25942 This would make an excellent project for an open source contributor (or small team). We would want to preserve some of the existing chat text behaviors such as '/me' handling and automatic creation of links. I suspect that the implementation would provide an opportunity to do some code cleanup and refactoring. From oz at lindenlab.com Mon Jun 13 08:20:07 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 13 Jun 2011 15:20:07 -0000 Subject: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up. In-Reply-To: <20110301165847.24776.99074@domU-12-31-38-00-90-68.compute-1.internal> References: <20110301165847.24776.99074@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110613152007.2653.60319@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/152/#review740 ----------------------------------------------------------- indra/newview/lltexlayer.h This would be more clear as an enum: when looking at a call to this method, a value 'true' or 'false' is much less informative that 'isHighestRes' or 'isLowRes' indra/newview/lltexlayer.cpp These should be 'static'; they don't need to be visible to the linker. indra/newview/lltexlayer.cpp what's with the minus one here? - Oz On March 1, 2011, 8:58 a.m., Thickbrick Sleaford wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/152/ > ----------------------------------------------------------- > > (Updated March 1, 2011, 8:58 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't send a AgentSetAppearance message. This can happen without the user being aware, leaving the avatar looking good on their screen, but not updated to the same outfit on other people's screens. The avatar will remain in that state until the user does something that causes a rebake (manually rebake or change outfit.) The solution here is to retry the upload after a small delay. > > What this diff changes: when a full-res upload fails, retry to upload it after a 5s delay, up to 5 times (in case the cap is available, last attempt is via the old asset store.) Also, some clearer log messages. This implements an old *FIX: comment: > // *FIX: retry upload after n seconds, asset server could be busy > > This isn't needed for low res uploads, because they don't block subsequent full-res uploads (mNeedsUpload isn't set to FALSE in LLTexLayerSetBuffer::doUpload in low-res uploads.) > > > This addresses bug VWR-24889. > http://jira.secondlife.com/browse/VWR-24889 > > > Diffs > ----- > > indra/newview/llassetuploadresponders.h 767feb16f05f > indra/newview/llassetuploadresponders.cpp 767feb16f05f > indra/newview/lltexlayer.h 767feb16f05f > indra/newview/lltexlayer.cpp 767feb16f05f > > Diff: http://codereview.secondlife.com/r/152/diff > > > Testing > ------- > > Attempted outfit changes using a problematic connection (not recently used outfits to avoid using cached bakes). Looked for "Baked full res texture upload for failed" log messages, observed the subsequent retries and successful upload for that region. Observed that eventually the fully-baked avatar is visible to other users. > > > Thanks, > > Thickbrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110613/0d363f92/attachment.htm From kf6kjg at gmail.com Mon Jun 13 12:07:03 2011 From: kf6kjg at gmail.com (Ricky) Date: Mon, 13 Jun 2011 12:07:03 -0700 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> <20110611145712.51a0b0d9@hikaru.localdomain> <7A643B8F-5E16-4E0F-AA09-C2AA3A750437@web-pass.com> Message-ID: Thus far I'm in favor of the eye icon. Lately I've been using the Unreal Developers Kit a lot for classwork, and there is even a 8x8 or so eye icon that is still legible, though most of the eye icons are larger. None have lashes, just the arcs and iris dot. Once the icon is set, people will get used to it fast. The issue here is that there is no "standard" (de facto or otherwise) for an icon that represents draw distance. I can't even find a program that has an icon for the draw distance setting: most either have the setting hidden in a config menu or, as in Blender, in a sidebar with a textual heading. We just don't want to try to redefine an icon that has an existent strong meaning. Camera iris is used for brightness, scaled trees (and magnifying glass) for zoom, magnifying glass and binoculars for search. The eye though has no strong meaning in my mind. UDK uses the eye for "lock selected actor to the camera" - not exactly an intuitive use, but they rolled with it. Ricky Cron Stardust On Sun, Jun 12, 2011 at 12:01 PM, Trilo Byte wrote: > Agreed regarding the magnifying glass icon - it's used both in SL and in some browsers as an icon representing Search. > > The problem with using a 1 tree/many trees approach is that a) that's already used to denote zoom, not viewing distance, and b) that type of display works best when it's on either side of the control in question (either side of ?the zoom rocker on a digital camera, for example. > > I like the binoculars icon idea, but agree that it could cause confusion since other applications commonly use the symbol for search. > > An eye icon has merit, since it controls how much the user sees. ?Given the 16x16 pixel constraint, I think the rays/lines coming off the eye would be less clear, and may cause some possible confusion with the speaker/volume icon (which is exactly what you want to avoid). ?Speaker icon for what you hear, eye for what you see, seems pretty straightforward, and a tooltip when moused over/used would further eliminate confusion. > > As for the notice to pop up when the setting gets raised too high, how about using "caution" in place of "warning". - subtle change in language makes the message read more like helpful guidance. > > On Jun 11, 2011, at 4:08 PM, Jonathan Welch wrote: > >> While testing the updated graphic I've been looking at the cautionary >> wording on the slider and am not happy with it. ?There is no good way >> to align the text so it looks nice in all languages and the width of >> the slider would have to be wide enough to support the longest word in >> whatever language that happens to be. >> >> I am thinking that a warning notification message could be sent if the >> draw distance is adjusted up past a certain threshold. ?Much more >> explanatory text could be put into this notice and it would also be >> i10n friendly. >> >> Warning: You have just set your draw distance to a large value. ?This >> may cause poor system response. >> _______________________________________________ >> 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 > > _______________________________________________ > 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 Lance.Corrimal at eregion.de Mon Jun 13 12:46:36 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 13 Jun 2011 21:46:36 +0200 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <20110613144456.629cfe2c@hikaru.localdomain> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <20110613144456.629cfe2c@hikaru.localdomain> Message-ID: <201106132146.36930.Lance.Corrimal@eregion.de> I think small binoculars for short range and large ones for long range makes the most sense. but since this has been discussed to death, how about this, taken from my digital camera... the glyph for "really short draw distance" is a simplified flower (think "closeup" on the presets menu on your casio camera), and the glyph for "really loooooong draw distance" is a simplified mountain range (think of the "landscape" setting on the same camera) and besides that, i think the slider should have a field that shows the actual value of the draw distance, and it should change the range based on powers of two: 32, 64, 128, 256, 512, 1024 that being said, whats with the symbols anyways. just put in a text field with the actual value, and a hovertip that says "this slider changes the draw distance. too high values will slow you down to a crawl." way less clutter. look at dolphin viewer 2, restrained life, and the starlight skins for reference. bye, LC Am Montag, 13. Juni 2011 schrieb Carlo Wood: > I think that no matter what you draw, the icon > will not be clear to the majority of people. > > The icon only needs to be recognizable to those > who saw it before. They will have to learn > it's meaning from the tool tip imho. > > Nevertheless, binoculars are usually used for > either zoom or search, so I think another icon > would be better. > > Thinking about an avatar with a (half) sphere > around it, I'd use as icon a circle with a dot > in it, or a half circle with a vertical line > in the center, ie: > _ - _ > . . > / O \ > ------|------ > > On Mon, 13 Jun 2011 12:14:11 +0200 > > Opensource Obscure wrote: > > While clear, such an icon doesn't look much self-explaining to me > > with regard to its associated Draw Distance functionality. > > > > I still feel binoculars may be the best option. > > > > Binoculars may not be a commonly used glyph outside of SL, > > but it's a fact that many Second Life features are just .. not > > commonly used features. In most applications / online services / > > information environments or RL appliances, you just don't have > > the concept of "Draw Distance" or anything similar. > > > > On Mon, Jun 13, 2011 at 11:49, Hitomi Tiponi > > > > wrote: > > > Yes it's possible (see attached) - but something like that says > > > 'landscape' or 'plants' to me. > > > > > > ________________________________ > > > From: Argent Stonecutter > > > To: Hitomi Tiponi > > > Cc: aklo at skyhighway.com; opensource-dev at lists.secondlife.com > > > Sent: Mon, 13 June, 2011 1:58:54 > > > Subject: Re: [opensource-dev] Review viewer -- draw distance > > > slider > > > > > > On 2011-06-12, at 17:30, Hitomi Tiponi wrote: > > >> /me looks forward to seeing someone draw this one in a 16x16 > > >> pixel grid :) > > > > > > I think three small pine trees could be rendered in a 16x16 > > > grid. > > > > > > _______________________________________________ > > > 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 Lance.Corrimal at eregion.de Mon Jun 13 12:52:27 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 13 Jun 2011 21:52:27 +0200 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: <201106132146.36930.Lance.Corrimal@eregion.de> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <20110613144456.629cfe2c@hikaru.localdomain> <201106132146.36930.Lance.Corrimal@eregion.de> Message-ID: <201106132152.30162.Lance.Corrimal@eregion.de> this just in from my wife: the globe icon that's used for "places" in the new search would be a nice choice: small globe on the left for "short draw distance", large globe on the right for "large draw distance". bye, LC From thickbrick.sleaford at gmail.com Mon Jun 13 13:58:03 2011 From: thickbrick.sleaford at gmail.com (Thickbrick Sleaford) Date: Mon, 13 Jun 2011 20:58:03 -0000 Subject: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up. In-Reply-To: <20110613152007.2653.60319@domU-12-31-38-00-90-68.compute-1.internal> References: <20110613152007.2653.60319@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110613205803.3662.13976@domU-12-31-38-00-90-68.compute-1.internal> > On June 13, 2011, 8:20 a.m., Oz Linden wrote: > > indra/newview/lltexlayer.cpp, line 518 > > > > > > what's with the minus one here? mUploadFailCount counts failures, while BAKE_UPLOAD_ATTEMPTS is the number of attempts. When doUpload() is called for the last attempt, mUploadFailCount equals BAKE_UPLOAD_ATTEMPTS - 1, since the last failure hasn't occurred yet. This tries to do the last upload via the old asset store (UDP), just in case the HTTP capability isn't working. Does this still makes sense, or will the asset store not be supported soon anyway? > On June 13, 2011, 8:20 a.m., Oz Linden wrote: > > indra/newview/lltexlayer.h, line 369 > > > > > > This would be more clear as an enum: when looking at a call to this method, a value 'true' or 'false' is much less informative that 'isHighestRes' or 'isLowRes' I'm not sure that an enum would make this clearer. This is never called with hard-coded values, and the value for the only call to this c'tor is taken from the result (BOOL) of mTexLayerSet::isLocalTextureDataFinal. Converting the BOOL to an enum, just to check later for equality to one of the enum values seems redundant to me. - Thickbrick ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/152/#review740 ----------------------------------------------------------- On March 1, 2011, 8:58 a.m., Thickbrick Sleaford wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/152/ > ----------------------------------------------------------- > > (Updated March 1, 2011, 8:58 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't send a AgentSetAppearance message. This can happen without the user being aware, leaving the avatar looking good on their screen, but not updated to the same outfit on other people's screens. The avatar will remain in that state until the user does something that causes a rebake (manually rebake or change outfit.) The solution here is to retry the upload after a small delay. > > What this diff changes: when a full-res upload fails, retry to upload it after a 5s delay, up to 5 times (in case the cap is available, last attempt is via the old asset store.) Also, some clearer log messages. This implements an old *FIX: comment: > // *FIX: retry upload after n seconds, asset server could be busy > > This isn't needed for low res uploads, because they don't block subsequent full-res uploads (mNeedsUpload isn't set to FALSE in LLTexLayerSetBuffer::doUpload in low-res uploads.) > > > This addresses bug VWR-24889. > http://jira.secondlife.com/browse/VWR-24889 > > > Diffs > ----- > > indra/newview/llassetuploadresponders.h 767feb16f05f > indra/newview/llassetuploadresponders.cpp 767feb16f05f > indra/newview/lltexlayer.h 767feb16f05f > indra/newview/lltexlayer.cpp 767feb16f05f > > Diff: http://codereview.secondlife.com/r/152/diff > > > Testing > ------- > > Attempted outfit changes using a problematic connection (not recently used outfits to avoid using cached bakes). Looked for "Baked full res texture upload for failed" log messages, observed the subsequent retries and successful upload for that region. Observed that eventually the fully-baked avatar is visible to other users. > > > Thanks, > > Thickbrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110613/792efca6/attachment.htm From oz at lindenlab.com Mon Jun 13 13:59:24 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 13 Jun 2011 16:59:24 -0400 Subject: [opensource-dev] PO Review Build Message-ID: <4DF67A2C.4070401@lindenlab.com> A number of open source contributions are ready for a functional review STORM-787 Mute Gestures Button STORM-956 Ability to mute dialogs by muting object (or object owner) STORM-1103 Nearby sidebar minimap should be optional STORM-1273 Duplicate entries in settings.xml STORM-1293 Make user aware of the "CTRL + Up/Down Arrow" feature (which scrolls back message history) STORM-1313 Fix for Storm-956 crashes viewer when connected to non-LL grids http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_viewer-poreview/rev/232771/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110613/bc7a12c8/attachment-0001.htm From wolfpup67 at earthlink.net Mon Jun 13 14:32:24 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Mon, 13 Jun 2011 17:32:24 -0400 Subject: [opensource-dev] Post Open Developer User Group meeting Message-ID: <001201cc2a11$62ed47f0$28c7d7d0$@net> For this discussion please refer to : https://wiki.secondlife.com/wiki/Open_Development_User_Group/Archive/2011-06 -13-post-meeting This was an in world discussion of making llconvexdecompositionstub into a functional and working Open Source. Most of you may think I'm still a PITA with this subject but this is something that needs to be addressed and the main people that can is the Open Source Developer community. We need to get this functional BEFORE mesh goes live on the main grid. We do have the mesh enabled sims on aditi to be able to test with so that we can know if we are getting it working and working right for the most part. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110613/3066e274/attachment.htm From thickbrick.sleaford at gmail.com Mon Jun 13 14:39:58 2011 From: thickbrick.sleaford at gmail.com (Thickbrick Sleaford) Date: Mon, 13 Jun 2011 21:39:58 -0000 Subject: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up. In-Reply-To: <20110301165847.24776.99074@domU-12-31-38-00-90-68.compute-1.internal> References: <20110301165847.24776.99074@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110613213958.2653.50981@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/152/ ----------------------------------------------------------- (Updated June 13, 2011, 2:39 p.m.) Review request for Viewer. Changes ------- - Fixed typo in comment ("intermediary"). - Changed file-scope constants to static const. - At Oz's suggestion (in email), delays are now exponential. Oz suggested leaving this to hammer the server indefinitely, but I feel more comfortable with a limit of 7 attempts. The first attempt is immediate, and 6 retries are done with delays: 2s, 4s, ... 64s. The delays sum up to 126 seconds. Summary ------- When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't send a AgentSetAppearance message. This can happen without the user being aware, leaving the avatar looking good on their screen, but not updated to the same outfit on other people's screens. The avatar will remain in that state until the user does something that causes a rebake (manually rebake or change outfit.) The solution here is to retry the upload after a small delay. What this diff changes: when a full-res upload fails, retry to upload it after a 5s delay, up to 5 times (in case the cap is available, last attempt is via the old asset store.) Also, some clearer log messages. This implements an old *FIX: comment: // *FIX: retry upload after n seconds, asset server could be busy This isn't needed for low res uploads, because they don't block subsequent full-res uploads (mNeedsUpload isn't set to FALSE in LLTexLayerSetBuffer::doUpload in low-res uploads.) This addresses bug VWR-24889. http://jira.secondlife.com/browse/VWR-24889 Diffs (updated) ----- indra/newview/llassetuploadresponders.h df4801993ea4 indra/newview/llassetuploadresponders.cpp df4801993ea4 indra/newview/lltexlayer.h df4801993ea4 indra/newview/lltexlayer.cpp df4801993ea4 Diff: http://codereview.secondlife.com/r/152/diff Testing ------- Attempted outfit changes using a problematic connection (not recently used outfits to avoid using cached bakes). Looked for "Baked full res texture upload for failed" log messages, observed the subsequent retries and successful upload for that region. Observed that eventually the fully-baked avatar is visible to other users. Thanks, Thickbrick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110613/32c912f8/attachment.htm From aklo at skyhighway.com Mon Jun 13 20:09:52 2011 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Mon, 13 Jun 2011 20:09:52 -0700 Subject: [opensource-dev] Review viewer -- draw distance slider Message-ID: <9d589e8a51b26a97c9e2dd9809379085.squirrel@cruziomail.cruzio.com> While clear, such an icon doesn't look much self-explaining to me with regard to its associated Draw Distance functionality. I still feel binoculars may be the best option. Binoculars may not be a commonly used glyph outside of SL, but it's a fact that many Second Life features are just .. not commonly used features. In most applications / online services / information environments or RL appliances, you just don't have the concept of "Draw Distance" or anything similar. On Mon, Jun 13, 2011 at 11:49, Hitomi Tiponi wrote: > > Yes it's possible (see attached) - but something like that says 'landscape' > > or 'plants' to me. > > > > ________________________________ > > From: Argent Stonecutter > > To: Hitomi Tiponi > > Cc: aklo at skyhighway.com; opensource-dev at lists.secondlife.com > > Sent: Mon, 13 June, 2011 1:58:54 > > Subject: Re: [opensource-dev] Review viewer -- draw distance slider Hey guys, i had an idea and i tried to draw it, but it was sorta disappointing. It looks sorta ok at 32x32, but at 16x16 it starts to get kinda, "Huh?" See, it's supposed to be a hand drawing. Like holding a pencil, with an arrow underneath it pointing the direction it's drawing. i attached a copy of the 32x32 one to this message. You can laugh at it and call it names if you want. It was just an idea. i've been sick like fever puking for three days and today one of my teeth started on the pain like please just give me to the CIA and let them torture me to death thing, so it's not like you could possibly make anything hurt worse. Maybe it will even give someone a better idea? i can do way better graphic art, too, but maybe not while i'm shaking, sweating, and trying not to scream myself unconscious. Have fun! - AK > > > > On 2011-06-12, at 17:30, Hitomi Tiponi wrote: >> >> /me looks forward to seeing someone draw this one in a 16x16 pixel grid :) > > > > I think three small pine trees could be rendered in a 16x16 grid. > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > > privileges > > -- Opensource Obscure -- http://twitter.com/oobscure - http://opensourceobscure.com/lol discuss Second Life Viewer 2: http://j.mp/slv2group _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: draw_distance_32.jpg Type: image/jpeg Size: 23667 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110613/7d8b790a/attachment-0001.jpg From akanevsky at productengine.com Mon Jun 13 23:43:39 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Mon, 13 Jun 2011 23:43:39 -0700 Subject: [opensource-dev] PO Review Build In-Reply-To: <4DF67A2C.4070401@lindenlab.com> References: <4DF67A2C.4070401@lindenlab.com> Message-ID: 2011/6/13 Oz Linden (Scott Lawrence) > A number of open source contributions are ready for a functional review > > STORM-787 Mute Gestures > Button > approved, great stuff > STORM-956 Ability to mute > dialogs by muting object (or object owner) > this is an old closed jira and I see no recent activity on it - what is the current change? > STORM-1103 Nearby sidebar > minimap should be optional > approved, great stuff too! > STORM-1273 Duplicate > entries in settings.xml > approved > STORM-1293 Make user aware > of the "CTRL + Up/Down Arrow" feature (which scrolls back message history) > esbee's going to run this by UX > STORM-1313 Fix for > Storm-956 crashes viewer when connected to non-LL grids > > > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_viewer-poreview/rev/232771/index.html > > > > _______________________________________________ > 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/20110613/5b253859/attachment.htm From sllists at boroon.dasgupta.ch Tue Jun 14 03:03:09 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 14 Jun 2011 12:03:09 +0200 Subject: [opensource-dev] Proposal for draw distance slider icon: Drawing hand and an arrow (was: Review viewer -- draw distance slider) In-Reply-To: <9d589e8a51b26a97c9e2dd9809379085.squirrel@cruziomail.cruzio.com> References: <9d589e8a51b26a97c9e2dd9809379085.squirrel@cruziomail.cruzio.com> Message-ID: <4DF731DD.9090703@boroon.dasgupta.ch> On 06/14/2011 05:09 AM, aklo at skyhighway.com wrote: > i had an idea and i tried to draw it, but it was sorta disappointing. It > looks sorta ok at 32x32, but at 16x16 it starts to get kinda, "Huh?" See, > it's supposed to be a hand drawing. Like holding a pencil, with an arrow > underneath it pointing the direction it's drawing. i attached a copy of > the 32x32 one to this message. Interesting idea! If we'd have to make it work on 16x16, one would probably have to go with a more cartoonish hand, maybe in the style of the hand cursors: * A typical link-hover cursor (unlabeled, maybe from Windows?) I found on Wikimedia Commons * SL's 'grab' cursor The above examples are larger than 16x16 but the SL 'sit' cursor demonstrates that the hand can work on smaller space (approximately 16x16), too. I don't know how well it'd work for a /drawing/ hand in that size, but I found a high-resolution drawing hand illustration in a similar style. A possibility might be to just use the pen without a hand, but that'd probably purport the notion of "edit" or "write" rather than "draw". How about a paint brush instead of a pen? But even the whole 32x32 icon might be more confusing than helping. While dissecting compound words and circumscribing the parts individually is a good strategy for Taboo, Pictionary and other word-guessing games, people using a program don't expect to have to think 'around the corner' to make sense of its GUI. I don't think many associate the drawing the rendering engine does with manually drawing a sketch or drawing on a canvas, although both are still the graphical meaning of 'draw', rather than one of the many other meanings of the word. On the other hand, once the user 'gets' the icon, it'll be easy to remember and recognize and also easy to distinguish from the volume slider's speaker icon. > You can laugh at it and call it names if you want. It was just an idea. I wouldn't laugh /at/ the idea. I appreciate the creativity! I might laugh /about/ it, because I like it's attempt at word-play, even though that word-play is probably detrimental for the icon's use in the UI. > i've been sick like fever puking for three days and today one of my teeth > started on the pain like please just give me to the CIA and let them > torture me to death thing, so it's not like you could possibly make > anything hurt worse. Maybe it will even give someone a better idea? i > can do way better graphic art, too, but maybe not while i'm shaking, > sweating, and trying not to scream myself unconscious. Ew, that sounds bad. I hope you get well soon! Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/c479af1f/attachment.htm From sllists at boroon.dasgupta.ch Tue Jun 14 04:02:45 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 14 Jun 2011 13:02:45 +0200 Subject: [opensource-dev] More proposals for draw distance slider icon (was: Review viewer -- draw distance slider) In-Reply-To: <20110613144456.629cfe2c@hikaru.localdomain> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <360394.83545.qm@web23905.mail.ird.yahoo.com> <6C6A223A-4E84-4161-ABBE-D7DBD604D8ED@gmail.com> <645564.61817.qm@web23901.mail.ird.yahoo.com> <20110613144456.629cfe2c@hikaru.localdomain> Message-ID: <4DF73FD5.4090709@boroon.dasgupta.ch> On 06/13/2011 02:44 PM, Carlo Wood wrote: > I think that no matter what you draw, the icon > will not be clear to the majority of people. > > The icon only needs to be recognizable to those > who saw it before. They will have to learn > it's meaning from the tool tip imho. > > Nevertheless, binoculars are usually used for > either zoom or search, so I think another icon > would be better. > > Thinking about an avatar with a (half) sphere > around it, I'd use as icon a circle with a dot > in it, or a half circle with a vertical line > in the center, ie: > _ - _ > . . > / O \ > ------|------ Here are some sketches I did based on Aleric's idea: * * Here are some ideas of my own: (Descriptions intentionally omitted, as we should not use the icons if they aren't recognizable. If you can't figure them out, I can tell you what I had in mind later on, in case someone wants to make better icons for the same concepts.) * * * Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/368663d9/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: point-line_hemisphere.png Type: image/png Size: 274 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/368663d9/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: avatar_hemisphere.png Type: image/png Size: 266 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/368663d9/attachment-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: telescope.png Type: image/png Size: 209 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/368663d9/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: telescope_tripod.png Type: image/png Size: 264 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/368663d9/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: eye_arrow.png Type: image/png Size: 316 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/368663d9/attachment-0004.png From tateru at taterunino.net Tue Jun 14 05:38:53 2011 From: tateru at taterunino.net (Tateru Nino) Date: Tue, 14 Jun 2011 22:38:53 +1000 Subject: [opensource-dev] More proposals for draw distance slider icon In-Reply-To: <4DF73FD5.4090709@boroon.dasgupta.ch> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <360394.83545.qm@web23905.mail.ird.yahoo.com> <6C6A223A-4E84-4161-ABBE-D7DBD604D8ED@gmail.com> <645564.61817.qm@web23901.mail.ird.yahoo.com> <20110613144456.629cfe2c@hikaru.localdomain> <4DF73FD5.4090709@boroon.dasgupta.ch> Message-ID: <4DF7565D.7000307@taterunino.net> I'd consider a microscope to match the telescope. On 14/06/2011 9:02 PM, Boroondas Gupte wrote: > On 06/13/2011 02:44 PM, Carlo Wood wrote: >> I think that no matter what you draw, the icon >> will not be clear to the majority of people. >> >> The icon only needs to be recognizable to those >> who saw it before. They will have to learn >> it's meaning from the tool tip imho. >> >> Nevertheless, binoculars are usually used for >> either zoom or search, so I think another icon >> would be better. >> >> Thinking about an avatar with a (half) sphere >> around it, I'd use as icon a circle with a dot >> in it, or a half circle with a vertical line >> in the center, ie: >> _ - _ >> . . >> / O \ >> ------|------ > Here are some sketches I did based on Aleric's idea: > > * > * > > Here are some ideas of my own: > (Descriptions intentionally omitted, as we should not use the icons if > they aren't recognizable. If you can't figure them out, I can tell you > what I had in mind later on, in case someone wants to make better > icons for the same concepts.) > > * > * > * > > Cheers, > Boroondas > > > _______________________________________________ > 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/20110614/494a9d82/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 274 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/494a9d82/attachment-0005.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 266 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/494a9d82/attachment-0006.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 209 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/494a9d82/attachment-0007.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 264 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/494a9d82/attachment-0008.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 316 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/494a9d82/attachment-0009.png From mike.chase at alternatemetaverse.com Tue Jun 14 05:41:04 2011 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Tue, 14 Jun 2011 08:41:04 -0400 Subject: [opensource-dev] More proposals for draw distance slider icon In-Reply-To: <4DF7565D.7000307@taterunino.net> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <360394.83545.qm@web23905.mail.ird.yahoo.com> <6C6A223A-4E84-4161-ABBE-D7DBD604D8ED@gmail.com> <645564.61817.qm@web23901.mail.ird.yahoo.com> <20110613144456.629cfe2c@hikaru.localdomain> <4DF73FD5.4090709@boroon.dasgupta.ch> <4DF7565D.7000307@taterunino.net> Message-ID: <4DF756E0.8060806@alternatemetaverse.com> On 06/14/2011 08:38 AM, Tateru Nino wrote: > I'd consider a microscope to match the telescope. Since its distance we're dealing with why not a "ruler". I haven't followed the entire thread so apologies if thats been mentioned and rejected already. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/5fe9e920/attachment.htm From nickyperian at yahoo.com Tue Jun 14 05:44:41 2011 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 14 Jun 2011 05:44:41 -0700 (PDT) Subject: [opensource-dev] Proposal for draw distance slider icon: Drawing hand and an arrow (was: Review viewer -- draw distance slider) In-Reply-To: <4DF731DD.9090703@boroon.dasgupta.ch> References: <9d589e8a51b26a97c9e2dd9809379085.squirrel@cruziomail.cruzio.com> <4DF731DD.9090703@boroon.dasgupta.ch> Message-ID: <470676.45000.qm@web43510.mail.sp1.yahoo.com> How about the binoculars with a plain moon in one eye and a detailed moon or man in the moon in the other. Also, thought about the earth rising photo from the moon in one and plain earth in the other but, I think that would lack contrast. ________________________________ From: Boroondas Gupte To: opensource-dev at lists.secondlife.com Sent: Tue, June 14, 2011 5:03:09 AM Subject: [opensource-dev] Proposal for draw distance slider icon: Drawing hand and an arrow (was: Review viewer -- draw distance slider) On 06/14/2011 05:09 AM, aklo at skyhighway.com wrote: i had an idea and i tried to draw it, but it was sorta disappointing. It looks sorta ok at 32x32, but at 16x16 it starts to get kinda, "Huh?" See, it's supposed to be a hand drawing. Like holding a pencil, with an arrow underneath it pointing the direction it's drawing. i attached a copy of the 32x32 one to this message. Interesting idea! If we'd have to make it work on 16x16, one would probably have to go with a more cartoonish hand, maybe in the style of the hand cursors: * A typical link-hover cursor (unlabeled, maybe from Windows?) I found on Wikimedia Commons * SL's 'grab' cursor The above examples are larger than 16x16 but the SL 'sit' cursor demonstrates that the hand can work on smaller space (approximately 16x16), too. I don't know how well it'd work for a drawing hand in that size, but I found a high-resolution drawing hand illustration in a similar style. A possibility might be to just use the pen without a hand, but that'd probably purport the notion of "edit" or "write" rather than "draw". How about a paint brush instead of a pen? But even the whole 32x32 icon might be more confusing than helping. While dissecting compound words and circumscribing the parts individually is a good strategy for Taboo, Pictionary and other word-guessing games, people using a program don't expect to have to think 'around the corner' to make sense of its GUI. I don't think many associate the drawing the rendering engine does with manually drawing a sketch or drawing on a canvas, although both are still the graphical meaning of 'draw', rather than one of the many other meanings of the word. On the other hand, once the user 'gets' the icon, it'll be easy to remember and recognize and also easy to distinguish from the volume slider's speaker icon. You can laugh at it and call it names if you want. It was just an idea. I wouldn't laugh at the idea. I appreciate the creativity! I might laugh about it, because I like it's attempt at word-play, even though that word-play is probably detrimental for the icon's use in the UI. i've been sick like fever puking for three days and today one of my teeth started on the pain like please just give me to the CIA and let them torture me to death thing, so it's not like you could possibly make anything hurt worse. Maybe it will even give someone a better idea? i can do way better graphic art, too, but maybe not while i'm shaking, sweating, and trying not to scream myself unconscious. Ew, that sounds bad. I hope you get well soon! Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/c8a0060d/attachment.htm From vsavchuk at productengine.com Tue Jun 14 06:53:04 2011 From: vsavchuk at productengine.com (Vadim Savchuk) Date: Tue, 14 Jun 2011 16:53:04 +0300 Subject: [opensource-dev] ER-480 fix brought a showstopper In-Reply-To: References: Message-ID: On Sun, Jun 12, 2011 at 11:23 PM, Marine Kelley wrote: > Has anybody noticed this already ? Basically the current viewer in v-d > has a malformed notifications.xml file, breaking it completely as soon > as you raise the camera controls floater. > If you mean the missing "<" issue, I remember fixing it in changeset 61ac1004521a . -- Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/f2ca0c19/attachment.htm From hitomi.tiponi at yahoo.co.uk Tue Jun 14 06:55:15 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Tue, 14 Jun 2011 14:55:15 +0100 (BST) Subject: [opensource-dev] Icons for Draw distance et al Message-ID: <363946.93215.qm@web23905.mail.ird.yahoo.com> As this has created such an interest, and ideas, amongst the community maybe LL should think of throwing the ideas for icons for new features open to the community. It looks like mesh could definitely do with a few ideas. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/3d8012d1/attachment.htm From sllists at boroon.dasgupta.ch Tue Jun 14 07:26:21 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 14 Jun 2011 16:26:21 +0200 Subject: [opensource-dev] Proposal for draw distance slider icon: binoculars with plain moon and detailed moon (was: Proposal for draw distance slider icon: Drawing hand and an arrow) In-Reply-To: <470676.45000.qm@web43510.mail.sp1.yahoo.com> References: <9d589e8a51b26a97c9e2dd9809379085.squirrel@cruziomail.cruzio.com> <4DF731DD.9090703@boroon.dasgupta.ch> <470676.45000.qm@web43510.mail.sp1.yahoo.com> Message-ID: <4DF76F8D.9050800@boroon.dasgupta.ch> On 06/14/2011 02:44 PM, Nicky Perian wrote: > How about the binoculars with a plain moon in one eye and a detailed > moon or man in the moon in the other. Also, thought about the earth > rising photo from the moon in one and plain earth in the other but, I > think that would lack contrast. I doubt that'd fit on 16x16 pixes and still be recognizable. (Feel free to prove me wrong.) Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/f65b59e6/attachment.htm From robertltux at gmail.com Tue Jun 14 07:39:29 2011 From: robertltux at gmail.com (Robert Martin) Date: Tue, 14 Jun 2011 10:39:29 -0400 Subject: [opensource-dev] Fwd: Review viewer -- draw distance slider In-Reply-To: References: <31b21e7a13865f52ef439ce4c5434887.squirrel@cruziomail.cruzio.com> Message-ID: On Fri, Jun 10, 2011 at 11:59 PM, ? wrote: > ?But one thing i don't think i've > seen in the discussion, wouldn't it be a good idea to have an auto-reset > take place on every tp? ?Have it go to some standard value that works > pretty good most places, and it'll save forgetful or excited people > problems. No on the auto reset the problems are 1 how do you define "standard value"?? 2 what about folks that have their draw distance chopped short for performance reasons?? 3 or folks that have their draw distance further out on purpose?? 4 even if you somehow define a system based "standard value" what happens when somebody knows they are going into a high prim area and sets their draw distance short SO THEY DON'T CRASH ON ENTRY (or take 15 minutes trying to rez) -- Robert L Martin -- Robert L Martin From sllists at boroon.dasgupta.ch Tue Jun 14 07:56:19 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 14 Jun 2011 16:56:19 +0200 Subject: [opensource-dev] More proposals for draw distance slider icon In-Reply-To: <4DF7565D.7000307@taterunino.net> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <360394.83545.qm@web23905.mail.ird.yahoo.com> <6C6A223A-4E84-4161-ABBE-D7DBD604D8ED@gmail.com> <645564.61817.qm@web23901.mail.ird.yahoo.com> <20110613144456.629cfe2c@hikaru.localdomain> <4DF73FD5.4090709@boroon.dasgupta.ch> <4DF7565D.7000307@taterunino.net> Message-ID: <4DF77693.5010903@boroon.dasgupta.ch> On 06/14/2011 02:38 PM, Tateru Nino wrote: > I'd consider a microscope to match the telescope. Yay, my icon is recognizable! (Or did you look at the filename?) About the microscope: I actually thought about that when I did my icons. The reason why I didn't draw one: * If I have understood correctly, we are currently looking for one single icon to open the slider, not for a pair of icons to put at each end. * As a single icon (although contrasted with the telescope), the microscope stands for the small and nearby stuff. So it might be a good icon for a slider that moves the near clipping plane (as opposed to draw distance, which AFAIK determines the far clipping plane, as well as which object updates are sent to you) or for a slider that sets the limit for how close you can zoom in on stuff. I don't think either of these sliders is needed. If you have to modify these values, you probably don't have to do so often *and* you should know very well what you are doing, so debug settings sounds like the right place to set them. * While a schematic microscope silhouette would probably be easy to recognize by people involved or interested in science, I'm not sure how well-known this shape would be to the general public. (Dear general public: Sorry if I'm grossly underestimating you. No offense intended.) Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/7e1864bb/attachment-0001.htm From da5idkronfeld at gmail.com Tue Jun 14 09:03:01 2011 From: da5idkronfeld at gmail.com (Da5id Kronfeld) Date: Tue, 14 Jun 2011 09:03:01 -0700 Subject: [opensource-dev] More proposals for draw distance slider icon In-Reply-To: <4DF77693.5010903@boroon.dasgupta.ch> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <360394.83545.qm@web23905.mail.ird.yahoo.com> <6C6A223A-4E84-4161-ABBE-D7DBD604D8ED@gmail.com> <645564.61817.qm@web23901.mail.ird.yahoo.com> <20110613144456.629cfe2c@hikaru.localdomain> <4DF73FD5.4090709@boroon.dasgupta.ch> <4DF7565D.7000307@taterunino.net> <4DF77693.5010903@boroon.dasgupta.ch> Message-ID: <58C5FF4F-AE73-4B4E-AE92-3A0B91EB7FC2@gmail.com> How about an eye with a ruler (horizontally) underneath it (or vertically beside it)? From trilobyte550m at gmail.com Tue Jun 14 09:07:06 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Tue, 14 Jun 2011 09:07:06 -0700 Subject: [opensource-dev] More proposals for draw distance slider icon In-Reply-To: <4DF77693.5010903@boroon.dasgupta.ch> References: <5ca4c1f8c958b02dd1a63422a17706d9.squirrel@cruziomail.cruzio.com> <360394.83545.qm@web23905.mail.ird.yahoo.com> <6C6A223A-4E84-4161-ABBE-D7DBD604D8ED@gmail.com> <645564.61817.qm@web23901.mail.ird.yahoo.com> <20110613144456.629cfe2c@hikaru.localdomain> <4DF73FD5.4090709@boroon.dasgupta.ch> <4DF7565D.7000307@taterunino.net> <4DF77693.5010903@boroon.dasgupta.ch> Message-ID: <6764D1BF-3364-46E4-859F-5E06A6A4BA59@web-pass.com> A few of the ideas have merit, but fall apart when you're constrained to 16x16. Not only are you constrained to 16x16, but looking at the other controls near it, you can't really get away with single-pixel-width lines and have it look good. Plus, it's got to be something that people may recognize fairly easily. An eye doesn't work, since it's already used within the interface (move & view controls). A globe doesn't work for the same reason (places), and neither does a magnifying glass (search). For me, binoculars is sounding like the logical choice (even though that one's tough to do within a 16x16 pixel space). On Jun 14, 2011, at 7:56 AM, Boroondas Gupte wrote: > On 06/14/2011 02:38 PM, Tateru Nino wrote: >> >> I'd consider a microscope to match the telescope. > Yay, my icon is recognizable! (Or did you look at the filename?) > > About the microscope: I actually thought about that when I did my icons. The reason why I didn't draw one: > If I have understood correctly, we are currently looking for one single icon to open the slider, not for a pair of icons to put at each end. > As a single icon (although contrasted with the telescope), the microscope stands for the small and nearby stuff. So it might be a good icon for a slider that moves the near clipping plane (as opposed to draw distance, which AFAIK determines the far clipping plane, as well as which object updates are sent to you) or for a slider that sets the limit for how close you can zoom in on stuff. I don't think either of these sliders is needed. If you have to modify these values, you probably don't have to do so often and you should know very well what you are doing, so debug settings sounds like the right place to set them. > While a schematic microscope silhouette would probably be easy to recognize by people involved or interested in science, I'm not sure how well-known this shape would be to the general public. (Dear general public: Sorry if I'm grossly underestimating you. No offense intended.) > Cheers, > Boroondas > _______________________________________________ > 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/20110614/a4c114b2/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: SL-topcorner.jpg Type: image/jpg Size: 2965 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/a4c114b2/attachment.jpg From danielravennest at gmail.com Tue Jun 14 11:49:30 2011 From: danielravennest at gmail.com (Daniel) Date: Tue, 14 Jun 2011 13:49:30 -0500 Subject: [opensource-dev] More proposals for draw distance slider icon (Mike Chase) In-Reply-To: References: Message-ID: <4DF7AD3A.6010101@gmail.com> For the icon, label it "DD" for draw distance. That will fit in 16x16 pixels, and not conflict with other symbols. Alternately an eye symbol with a slanted dotted rectangle under it to indicate see + boundary From lisa.mcconnell at upcmail.nl Tue Jun 14 14:22:44 2011 From: lisa.mcconnell at upcmail.nl (Lisa McConnell) Date: Tue, 14 Jun 2011 23:22:44 +0200 Subject: [opensource-dev] opensource-dev Digest, Vol 17, Issue 31 Message-ID: <3wv0cpudvypcyrp9pxynf35u.1308086564278@email.android.com> had a nice evening? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/19abd737/attachment.htm From jenn at lindenlab.com Tue Jun 14 14:46:59 2011 From: jenn at lindenlab.com (Jenn) Date: Tue, 14 Jun 2011 21:46:59 -0000 Subject: [opensource-dev] Review Request: Enable watchdog timer for Beta release crash hunting. Message-ID: <20110614214659.2651.51593@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/337/ ----------------------------------------------------------- Review request for Viewer, Alain Linden, Richard Nelson, and Nat Goodspeed. Summary ------- Enable watchdog timer for Beta release to get tracebacks for classes of crashes for which we currently have little data. Setting timer to 20 seconds. Will either disable or make longer for deployment to the Release channel. Diffs ----- indra/newview/app_settings/settings.xml a7c507c7e0f8 Diff: http://codereview.secondlife.com/r/337/diff Testing ------- Thanks, Jenn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/38407ca6/attachment.htm From alain at lindenlab.com Tue Jun 14 14:50:15 2011 From: alain at lindenlab.com (Alain Linden) Date: Tue, 14 Jun 2011 21:50:15 -0000 Subject: [opensource-dev] Review Request: Enable watchdog timer for Beta release crash hunting. In-Reply-To: <20110614214659.2651.51593@domU-12-31-38-00-90-68.compute-1.internal> References: <20110614214659.2651.51593@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110614215015.4024.95308@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/337/#review743 ----------------------------------------------------------- indra/newview/app_settings/settings.xml I presume this means trigger the watchdog after 20 seconds of 'freeze'. - Alain On June 14, 2011, 2:46 p.m., Jenn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/337/ > ----------------------------------------------------------- > > (Updated June 14, 2011, 2:46 p.m.) > > > Review request for Viewer, Alain Linden, Richard Nelson, and Nat Goodspeed. > > > Summary > ------- > > Enable watchdog timer for Beta release to get tracebacks for classes of crashes for which we currently have little data. > > Setting timer to 20 seconds. Will either disable or make longer for deployment to the Release channel. > > > Diffs > ----- > > indra/newview/app_settings/settings.xml a7c507c7e0f8 > > Diff: http://codereview.secondlife.com/r/337/diff > > > Testing > ------- > > > Thanks, > > Jenn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/da34eed6/attachment.htm From jenn at lindenlab.com Tue Jun 14 14:50:32 2011 From: jenn at lindenlab.com (Jenn) Date: Tue, 14 Jun 2011 21:50:32 -0000 Subject: [opensource-dev] Review Request: Enable watchdog timer for Beta crash hunting. In-Reply-To: <20110614214659.2651.51593@domU-12-31-38-00-90-68.compute-1.internal> References: <20110614214659.2651.51593@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110614215032.3662.13279@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/337/ ----------------------------------------------------------- (Updated June 14, 2011, 2:50 p.m.) Review request for Viewer, Alain Linden, Richard Nelson, and Nat Goodspeed. Summary (updated) ------- Enable watchdog timer for Beta release to get tracebacks for classes of crashes for which we currently have little data. Setting timer to 20 seconds. Will either disable or make longer for deployment to the Release channel. Diffs ----- indra/newview/app_settings/settings.xml a7c507c7e0f8 Diff: http://codereview.secondlife.com/r/337/diff Testing ------- Thanks, Jenn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/f6c02efe/attachment.htm From jenn at lindenlab.com Tue Jun 14 14:50:57 2011 From: jenn at lindenlab.com (Jenn) Date: Tue, 14 Jun 2011 21:50:57 -0000 Subject: [opensource-dev] Review Request: Enable watchdog timer for Beta crash hunting. In-Reply-To: <20110614215015.4024.95308@domU-12-31-38-00-90-68.compute-1.internal> References: <20110614215015.4024.95308@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110614215057.2648.28068@domU-12-31-38-00-90-68.compute-1.internal> > On June 14, 2011, 2:50 p.m., Alain Linden wrote: > > indra/newview/app_settings/settings.xml, line 12409 > > > > > > I presume this means trigger the watchdog after 20 seconds of 'freeze'. :) yes - Jenn ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/337/#review743 ----------------------------------------------------------- On June 14, 2011, 2:50 p.m., Jenn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/337/ > ----------------------------------------------------------- > > (Updated June 14, 2011, 2:50 p.m.) > > > Review request for Viewer, Alain Linden, Richard Nelson, and Nat Goodspeed. > > > Summary > ------- > > Enable watchdog timer for Beta release to get tracebacks for classes of crashes for which we currently have little data. > > Setting timer to 20 seconds. Will either disable or make longer for deployment to the Release channel. > > > Diffs > ----- > > indra/newview/app_settings/settings.xml a7c507c7e0f8 > > Diff: http://codereview.secondlife.com/r/337/diff > > > Testing > ------- > > > Thanks, > > Jenn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/026100c6/attachment.htm From sldev at free.fr Tue Jun 14 15:28:39 2011 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 15 Jun 2011 00:28:39 +0200 Subject: [opensource-dev] New web search: how to get search_token or auth_token in v1 viewers ? In-Reply-To: <4DDFE884.1020801@lindenlab.com> References: <20110526214153.f3c0f18a.sldev@free.fr> <20110527021044.4ca75358.sldev@free.fr> <20110527093643.d086a81f.sldev@free.fr> <4DDFE884.1020801@lindenlab.com> Message-ID: <20110615002839.3a6b5b89.sldev@free.fr> On Fri, 27 May 2011 14:08:04 -0400, Oz Linden (Scott Lawrence) wrote: > On 2011-05-27 3:36, Henri Beauchamp wrote: > > > However, I found another bug in the new search... the maturity rating > > parameter (r=13 or r=21 or r=42) passed in the search URL seems to be > > completely ignored, that is, if I want only the G results for a given > > search (I kept maturity selection checkboxes in the search panel for > > this purpose) while my global maturity preference is set to G+M+A, > > I'm still presented with all results, including M and A ones... > > Also, given what I can see of the viewer-search v2 code and of the > > values passed for this rating parameter (13/21/42), it doesn't seem > > designed to allow searching only for M or only for A, or only for > > M+A stuff, like it was possible to do with the old web (and also with > > the oldest non-web) search. > > The new search backend was originally designed to be inclusive: G, G+M, > or G+M+A - like the viewer. However, we are changing that now and we > will have the backend support for searching just M or just A and any > combination soon. I can now see the three maturity checkboxes in the search page results. However the "r" (rating) parameter in the search URL (http://search-beta.secondlife.com/viewer/[CATEGORY]/?q=[QUERY]&p=[AUTH_TOKEN]&r=[MATURITY]...) is still completely ignored (when I pass, 21 for M, for example, the checkboxes in the search results page are not modified to match and the search results are not updated to show only M results either), and the only valid (if to believe viewer sources) values for this parameter (13 xor 21 xor 42) do not allow to pass combined maturity queries (G+M, M+A, G+M+A, etc). Could we get a "m" (maturity) parameter in the search URL that would actually be taken into account (automatically updating the checkboxes in the web page) and would allow to combine maturity flags (such as what is done for the current/old web search) ? The advantage of such a parameter is that the viewer can remember the preferred maturity for the user's searches over sessions and pass the right parameter value on opening the search floater, unlike the new web-based maturity check boxes (which are always reset to G+M+A (or G+M if you are not adult-verified) at the next viewer session). Henri. From alain at lindenlab.com Tue Jun 14 15:29:38 2011 From: alain at lindenlab.com (Alain Linden) Date: Tue, 14 Jun 2011 22:29:38 -0000 Subject: [opensource-dev] Review Request: Enable watchdog timer for Beta crash hunting. In-Reply-To: <20110614215032.3662.13279@domU-12-31-38-00-90-68.compute-1.internal> References: <20110614215032.3662.13279@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110614222938.3902.61724@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/337/#review745 ----------------------------------------------------------- Ship it! - Alain On June 14, 2011, 2:50 p.m., Jenn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/337/ > ----------------------------------------------------------- > > (Updated June 14, 2011, 2:50 p.m.) > > > Review request for Viewer, Alain Linden, Richard Nelson, and Nat Goodspeed. > > > Summary > ------- > > Enable watchdog timer for Beta release to get tracebacks for classes of crashes for which we currently have little data. > > Setting timer to 20 seconds. Will either disable or make longer for deployment to the Release channel. > > > Diffs > ----- > > indra/newview/app_settings/settings.xml a7c507c7e0f8 > > Diff: http://codereview.secondlife.com/r/337/diff > > > Testing > ------- > > > Thanks, > > Jenn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/11470214/attachment.htm From richard at lindenlab.com Tue Jun 14 15:38:06 2011 From: richard at lindenlab.com (Richard Nelson) Date: Tue, 14 Jun 2011 22:38:06 -0000 Subject: [opensource-dev] Review Request: Enable watchdog timer for Beta crash hunting. In-Reply-To: <20110614215032.3662.13279@domU-12-31-38-00-90-68.compute-1.internal> References: <20110614215032.3662.13279@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110614223806.2650.68383@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/337/#review746 ----------------------------------------------------------- Ship it! - Richard On June 14, 2011, 2:50 p.m., Jenn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/337/ > ----------------------------------------------------------- > > (Updated June 14, 2011, 2:50 p.m.) > > > Review request for Viewer, Alain Linden, Richard Nelson, and Nat Goodspeed. > > > Summary > ------- > > Enable watchdog timer for Beta release to get tracebacks for classes of crashes for which we currently have little data. > > Setting timer to 20 seconds. Will either disable or make longer for deployment to the Release channel. > > > Diffs > ----- > > indra/newview/app_settings/settings.xml a7c507c7e0f8 > > Diff: http://codereview.secondlife.com/r/337/diff > > > Testing > ------- > > > Thanks, > > Jenn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110614/0a3c0d75/attachment.htm From carlo at alinoe.com Tue Jun 14 17:38:35 2011 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 15 Jun 2011 02:38:35 +0200 Subject: [opensource-dev] More proposals for draw distance slider icon (Mike Chase) In-Reply-To: <4DF7AD3A.6010101@gmail.com> References: <4DF7AD3A.6010101@gmail.com> Message-ID: <20110615023835.3127ce4f@hikaru.localdomain> On Tue, 14 Jun 2011 13:49:30 -0500 Daniel wrote: > For the icon, label it "DD" for draw distance. That will fit in > 16x16 pixels, and not conflict with other symbols. I like this idea. Made an icon for it: -- Carlo Wood -------------- next part -------------- A non-text attachment was scrubbed... Name: dd.png Type: image/png Size: 318 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/fa05e09a/attachment.png From opensourceobscure at gmail.com Wed Jun 15 00:32:23 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Wed, 15 Jun 2011 09:32:23 +0200 Subject: [opensource-dev] More proposals for draw distance slider icon (Mike Chase) In-Reply-To: <20110615023835.3127ce4f@hikaru.localdomain> References: <4DF7AD3A.6010101@gmail.com> <20110615023835.3127ce4f@hikaru.localdomain> Message-ID: On Wed, Jun 15, 2011 at 02:38, Carlo Wood wrote: > On Tue, 14 Jun 2011 13:49:30 -0500 > Daniel wrote: > >> For the icon, label it "DD" for draw distance. ?That will fit in >> 16x16 pixels, and not conflict with other symbols. > > I like this idea. Made an icon for it: unclear. Opensource Obscure -- http://twitter.com/oobscure - http://opensourceobscure.com/lol discuss Second Life Viewer 2: http://j.mp/slv2group From marinekelley at gmail.com Wed Jun 15 00:56:23 2011 From: marinekelley at gmail.com (Marine Kelley) Date: Wed, 15 Jun 2011 09:56:23 +0200 Subject: [opensource-dev] More proposals for draw distance slider icon (Mike Chase) In-Reply-To: References: <4DF7AD3A.6010101@gmail.com> <20110615023835.3127ce4f@hikaru.localdomain> Message-ID: How about a pair of round glasses in orthographic view, seen from a quarter profile ? Something like this (forgive the lack of alignment on non-fixed fonts) : / / O-O This icon is not used anywhere and has no special meaning, if you put them on you see better that if you remove them (if you're short-sighted that is), it would not be confused with search (as a magnifying glass or a pair of binoculars would) or the world map (as a globe would), and would be easy to draw in 16x16 because there is no filling to do, just thin strokes. Just my L$5 Marine On 15/06/2011, Opensource Obscure wrote: > On Wed, Jun 15, 2011 at 02:38, Carlo Wood wrote: >> On Tue, 14 Jun 2011 13:49:30 -0500 >> Daniel wrote: >> >>> For the icon, label it "DD" for draw distance. ?That will fit in >>> 16x16 pixels, and not conflict with other symbols. >> >> I like this idea. Made an icon for it: > > unclear. > > Opensource Obscure > -- > http://twitter.com/oobscure - http://opensourceobscure.com/lol > discuss Second Life Viewer 2: http://j.mp/slv2group > _______________________________________________ > 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 Jun 15 07:57:27 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 15 Jun 2011 14:57:27 -0000 Subject: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up. In-Reply-To: <20110613213958.2653.50981@domU-12-31-38-00-90-68.compute-1.internal> References: <20110613213958.2653.50981@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110615145727.3662.8137@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/152/#review747 ----------------------------------------------------------- Ship it! - Oz On June 13, 2011, 2:39 p.m., Thickbrick Sleaford wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/152/ > ----------------------------------------------------------- > > (Updated June 13, 2011, 2:39 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't send a AgentSetAppearance message. This can happen without the user being aware, leaving the avatar looking good on their screen, but not updated to the same outfit on other people's screens. The avatar will remain in that state until the user does something that causes a rebake (manually rebake or change outfit.) The solution here is to retry the upload after a small delay. > > What this diff changes: when a full-res upload fails, retry to upload it after a 5s delay, up to 5 times (in case the cap is available, last attempt is via the old asset store.) Also, some clearer log messages. This implements an old *FIX: comment: > // *FIX: retry upload after n seconds, asset server could be busy > > This isn't needed for low res uploads, because they don't block subsequent full-res uploads (mNeedsUpload isn't set to FALSE in LLTexLayerSetBuffer::doUpload in low-res uploads.) > > > This addresses bug VWR-24889. > http://jira.secondlife.com/browse/VWR-24889 > > > Diffs > ----- > > indra/newview/llassetuploadresponders.h df4801993ea4 > indra/newview/llassetuploadresponders.cpp df4801993ea4 > indra/newview/lltexlayer.h df4801993ea4 > indra/newview/lltexlayer.cpp df4801993ea4 > > Diff: http://codereview.secondlife.com/r/152/diff > > > Testing > ------- > > Attempted outfit changes using a problematic connection (not recently used outfits to avoid using cached bakes). Looked for "Baked full res texture upload for failed" log messages, observed the subsequent retries and successful upload for that region. Observed that eventually the fully-baked avatar is visible to other users. > > > Thanks, > > Thickbrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/7ee9349d/attachment.htm From oz at lindenlab.com Wed Jun 15 08:02:07 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 15 Jun 2011 15:02:07 -0000 Subject: [opensource-dev] Review Request: STORM-899 'No attachments worn' text on blank 'Attachments' accordion remains in English for all locales In-Reply-To: <20110607213237.6081.29399@domU-12-31-38-00-90-68.compute-1.internal> References: <20110607213237.6081.29399@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110615150207.3923.56679@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/326/#review748 ----------------------------------------------------------- Ship it! - Oz On June 7, 2011, 2:32 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/326/ > ----------------------------------------------------------- > > (Updated June 7, 2011, 2:32 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > 1. Launch viewer, change language to German for example. > 2. Re-login, open COF for edit. > 3. Open 'Attachments' accordion, delete all objects. > ===> > Actual: 'No attachments worn' text appears in English. > > > This addresses bug STORM-899. > http://jira.secondlife.com/browse/STORM-899 > > > Diffs > ----- > > doc/contributions.txt c0c940514b74 > indra/newview/llcofwearables.cpp c0c940514b74 > indra/newview/skins/default/xui/en/panel_cof_wearables.xml c0c940514b74 > indra/newview/skins/default/xui/en/strings.xml c0c940514b74 > > Diff: http://codereview.secondlife.com/r/326/diff > > > Testing > ------- > > Opened this tab with the viewer in English and also in French. I saw the same message, but that is because there is no translation for French, but it shows the call for a translation is working. > > What I am not sure of is if I made fix in the right way. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/320fa967/attachment-0001.htm From oz at lindenlab.com Wed Jun 15 08:07:37 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 15 Jun 2011 15:07:37 -0000 Subject: [opensource-dev] Review Request: STORM-787 Mute Gestures Button In-Reply-To: <20110612200915.2648.31481@domU-12-31-38-00-90-68.compute-1.internal> References: <20110612200915.2648.31481@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110615150737.2655.13531@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/336/#review749 ----------------------------------------------------------- Ship it! - Oz On June 12, 2011, 1:09 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/336/ > ----------------------------------------------------------- > > (Updated June 12, 2011, 1:09 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Added a checkbox control in Preferences->Sound and Media (see attached image in jira) to enable/disable sounds coming from gestures. > > There is a long writeup in the jira for reasons to have this. > > This control is linked to 1) the master volume control and 2) the sound effects control. If either of these is disabled (speaker has a red line through it) the checkbox is disabled. > > > This addresses bug STORM-787. > http://jira.secondlife.com/browse/STORM-787 > > > Diffs > ----- > > doc/contributions.txt 6a3e7e403bd1 > indra/newview/app_settings/settings.xml 6a3e7e403bd1 > indra/newview/llfloaterpreference.h 6a3e7e403bd1 > indra/newview/llfloaterpreference.cpp 6a3e7e403bd1 > indra/newview/llviewermessage.cpp 6a3e7e403bd1 > indra/newview/skins/default/xui/en/panel_preferences_sound.xml 6a3e7e403bd1 > > Diff: http://codereview.secondlife.com/r/336/diff > > > Testing > ------- > > Tested per test plan in jira. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/57e35fa0/attachment.htm From vsavchuk at productengine.com Wed Jun 15 08:50:07 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Wed, 15 Jun 2011 15:50:07 -0000 Subject: [opensource-dev] Review Request: STORM-1339 Crash in LLPanelPlaces::onTeleportButtonClicked Message-ID: <20110615155007.3651.95119@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/339/ ----------------------------------------------------------- Review request for Viewer. Summary ------- I could not reproduce the crash, so just adding NULL pointer checks in a couple of suspicious places. This addresses bug STORM-1339. http://jira.secondlife.com/browse/STORM-1339 Diffs ----- indra/newview/llpanellandmarks.cpp UNKNOWN indra/newview/llpanelplaces.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/339/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/5c93cb3e/attachment.htm From oz at lindenlab.com Wed Jun 15 09:00:42 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 15 Jun 2011 16:00:42 -0000 Subject: [opensource-dev] Review Request: STORM-1339 Crash in LLPanelPlaces::onTeleportButtonClicked In-Reply-To: <20110615155007.3651.95119@domU-12-31-38-00-90-68.compute-1.internal> References: <20110615155007.3651.95119@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110615160042.4024.11291@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/339/#review750 ----------------------------------------------------------- Ship it! - Oz On June 15, 2011, 8:50 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/339/ > ----------------------------------------------------------- > > (Updated June 15, 2011, 8:50 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > I could not reproduce the crash, so just adding NULL pointer checks in a couple of suspicious places. > > > This addresses bug STORM-1339. > http://jira.secondlife.com/browse/STORM-1339 > > > Diffs > ----- > > indra/newview/llpanellandmarks.cpp UNKNOWN > indra/newview/llpanelplaces.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/339/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/c0a063fc/attachment.htm From vsavchuk at productengine.com Wed Jun 15 09:11:49 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Wed, 15 Jun 2011 16:11:49 -0000 Subject: [opensource-dev] Review Request: STORM-899 'No attachments worn' text on blank 'Attachments' accordion remains in English for all locales In-Reply-To: <20110607213237.6081.29399@domU-12-31-38-00-90-68.compute-1.internal> References: <20110607213237.6081.29399@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110615161149.3681.64174@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/326/#review751 ----------------------------------------------------------- See minor points below. indra/newview/llcofwearables.cpp I suppose this can be done once in postBuild(), because the textbox only gets visible when the list is empty. indra/newview/skins/default/xui/en/strings.xml The section this string is in seems inappropriate. - Vadim On June 7, 2011, 2:32 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/326/ > ----------------------------------------------------------- > > (Updated June 7, 2011, 2:32 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > 1. Launch viewer, change language to German for example. > 2. Re-login, open COF for edit. > 3. Open 'Attachments' accordion, delete all objects. > ===> > Actual: 'No attachments worn' text appears in English. > > > This addresses bug STORM-899. > http://jira.secondlife.com/browse/STORM-899 > > > Diffs > ----- > > doc/contributions.txt c0c940514b74 > indra/newview/llcofwearables.cpp c0c940514b74 > indra/newview/skins/default/xui/en/panel_cof_wearables.xml c0c940514b74 > indra/newview/skins/default/xui/en/strings.xml c0c940514b74 > > Diff: http://codereview.secondlife.com/r/326/diff > > > Testing > ------- > > Opened this tab with the viewer in English and also in French. I saw the same message, but that is because there is no translation for French, but it shows the call for a translation is working. > > What I am not sure of is if I made fix in the right way. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/5c57a167/attachment.htm From jhwelch at gmail.com Wed Jun 15 10:04:05 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 15 Jun 2011 17:04:05 -0000 Subject: [opensource-dev] Review Request: STORM-899 'No attachments worn' text on blank 'Attachments' accordion remains in English for all locales In-Reply-To: <20110615161149.3681.64174@domU-12-31-38-00-90-68.compute-1.internal> References: <20110615161149.3681.64174@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110615170405.3651.44581@domU-12-31-38-00-90-68.compute-1.internal> > On June 15, 2011, 9:11 a.m., Vadim ProductEngine wrote: > > indra/newview/skins/default/xui/en/strings.xml, line 2095 > > > > > > The section this string is in seems inappropriate. I've moved this a bit farther down and created its own section, as per Vadim's jira comment other similar flatlist fixes may be necessary. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/326/#review751 ----------------------------------------------------------- On June 7, 2011, 2:32 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/326/ > ----------------------------------------------------------- > > (Updated June 7, 2011, 2:32 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > 1. Launch viewer, change language to German for example. > 2. Re-login, open COF for edit. > 3. Open 'Attachments' accordion, delete all objects. > ===> > Actual: 'No attachments worn' text appears in English. > > > This addresses bug STORM-899. > http://jira.secondlife.com/browse/STORM-899 > > > Diffs > ----- > > doc/contributions.txt c0c940514b74 > indra/newview/llcofwearables.cpp c0c940514b74 > indra/newview/skins/default/xui/en/panel_cof_wearables.xml c0c940514b74 > indra/newview/skins/default/xui/en/strings.xml c0c940514b74 > > Diff: http://codereview.secondlife.com/r/326/diff > > > Testing > ------- > > Opened this tab with the viewer in English and also in French. I saw the same message, but that is because there is no translation for French, but it shows the call for a translation is working. > > What I am not sure of is if I made fix in the right way. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/c9a6dfac/attachment-0001.htm From jhwelch at gmail.com Wed Jun 15 10:04:09 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 15 Jun 2011 17:04:09 -0000 Subject: [opensource-dev] Review Request: STORM-899 'No attachments worn' text on blank 'Attachments' accordion remains in English for all locales In-Reply-To: <20110607213237.6081.29399@domU-12-31-38-00-90-68.compute-1.internal> References: <20110607213237.6081.29399@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110615170409.2650.46819@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/326/ ----------------------------------------------------------- (Updated June 15, 2011, 10:04 a.m.) Review request for Viewer. Changes ------- Made changes per Vadim's comments. Summary ------- 1. Launch viewer, change language to German for example. 2. Re-login, open COF for edit. 3. Open 'Attachments' accordion, delete all objects. ===> Actual: 'No attachments worn' text appears in English. This addresses bug STORM-899. http://jira.secondlife.com/browse/STORM-899 Diffs (updated) ----- doc/contributions.txt c0c940514b74 indra/newview/llcofwearables.cpp c0c940514b74 indra/newview/skins/default/xui/en/panel_cof_wearables.xml c0c940514b74 indra/newview/skins/default/xui/en/strings.xml c0c940514b74 Diff: http://codereview.secondlife.com/r/326/diff Testing ------- Opened this tab with the viewer in English and also in French. I saw the same message, but that is because there is no translation for French, but it shows the call for a translation is working. What I am not sure of is if I made fix in the right way. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/12665815/attachment.htm From vsavchuk at productengine.com Wed Jun 15 10:22:38 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Wed, 15 Jun 2011 17:22:38 -0000 Subject: [opensource-dev] Review Request: STORM-899 'No attachments worn' text on blank 'Attachments' accordion remains in English for all locales In-Reply-To: <20110615170409.2650.46819@domU-12-31-38-00-90-68.compute-1.internal> References: <20110615170409.2650.46819@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110615172238.2652.7172@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/326/#review755 ----------------------------------------------------------- Ship it! Thanks. - Vadim On June 15, 2011, 10:04 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/326/ > ----------------------------------------------------------- > > (Updated June 15, 2011, 10:04 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > 1. Launch viewer, change language to German for example. > 2. Re-login, open COF for edit. > 3. Open 'Attachments' accordion, delete all objects. > ===> > Actual: 'No attachments worn' text appears in English. > > > This addresses bug STORM-899. > http://jira.secondlife.com/browse/STORM-899 > > > Diffs > ----- > > doc/contributions.txt c0c940514b74 > indra/newview/llcofwearables.cpp c0c940514b74 > indra/newview/skins/default/xui/en/panel_cof_wearables.xml c0c940514b74 > indra/newview/skins/default/xui/en/strings.xml c0c940514b74 > > Diff: http://codereview.secondlife.com/r/326/diff > > > Testing > ------- > > Opened this tab with the viewer in English and also in French. I saw the same message, but that is because there is no translation for French, but it shows the call for a translation is working. > > What I am not sure of is if I made fix in the right way. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/908caac7/attachment.htm From sllists at boroon.dasgupta.ch Wed Jun 15 12:37:52 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 15 Jun 2011 19:37:52 -0000 Subject: [opensource-dev] Review Request: STORM-899 'No attachments worn' text on blank 'Attachments' accordion remains in English for all locales In-Reply-To: <20110615170409.2650.46819@domU-12-31-38-00-90-68.compute-1.internal> References: <20110615170409.2650.46819@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110615193752.2650.15278@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/326/#review757 ----------------------------------------------------------- indra/newview/skins/default/xui/en/strings.xml Is it intentional that each of these 3 lines is indented differently? - Boroondas On June 15, 2011, 10:04 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/326/ > ----------------------------------------------------------- > > (Updated June 15, 2011, 10:04 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > 1. Launch viewer, change language to German for example. > 2. Re-login, open COF for edit. > 3. Open 'Attachments' accordion, delete all objects. > ===> > Actual: 'No attachments worn' text appears in English. > > > This addresses bug STORM-899. > http://jira.secondlife.com/browse/STORM-899 > > > Diffs > ----- > > doc/contributions.txt c0c940514b74 > indra/newview/llcofwearables.cpp c0c940514b74 > indra/newview/skins/default/xui/en/panel_cof_wearables.xml c0c940514b74 > indra/newview/skins/default/xui/en/strings.xml c0c940514b74 > > Diff: http://codereview.secondlife.com/r/326/diff > > > Testing > ------- > > Opened this tab with the viewer in English and also in French. I saw the same message, but that is because there is no translation for French, but it shows the call for a translation is working. > > What I am not sure of is if I made fix in the right way. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/4f6d637d/attachment.htm From jhwelch at gmail.com Wed Jun 15 12:50:34 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 15 Jun 2011 19:50:34 -0000 Subject: [opensource-dev] Review Request: STORM-899 'No attachments worn' text on blank 'Attachments' accordion remains in English for all locales In-Reply-To: <20110615170409.2650.46819@domU-12-31-38-00-90-68.compute-1.internal> References: <20110615170409.2650.46819@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110615195034.3964.60509@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/326/ ----------------------------------------------------------- (Updated June 15, 2011, 12:50 p.m.) Review request for Viewer. Changes ------- Changed tab to space per Boroondas' comment. Summary ------- 1. Launch viewer, change language to German for example. 2. Re-login, open COF for edit. 3. Open 'Attachments' accordion, delete all objects. ===> Actual: 'No attachments worn' text appears in English. This addresses bug STORM-899. http://jira.secondlife.com/browse/STORM-899 Diffs (updated) ----- doc/contributions.txt c0c940514b74 indra/newview/llcofwearables.cpp c0c940514b74 indra/newview/skins/default/xui/en/panel_cof_wearables.xml c0c940514b74 indra/newview/skins/default/xui/en/strings.xml c0c940514b74 Diff: http://codereview.secondlife.com/r/326/diff Testing ------- Opened this tab with the viewer in English and also in French. I saw the same message, but that is because there is no translation for French, but it shows the call for a translation is working. What I am not sure of is if I made fix in the right way. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110615/25e86852/attachment.htm From lee.ponzu at gmail.com Thu Jun 16 11:36:40 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Thu, 16 Jun 2011 14:36:40 -0400 Subject: [opensource-dev] Question about DD philosophy. Message-ID: I have sometimes wondered why this is not more automagic, or maybe why the magic approach doesn't work well enough. Suppose my DD is set to 256. Upon detecting a poor FPS, the viewer could remember the DD, and then reduce it temporarily to 32. As FPS becomes acceptable, it increases it little by little until it is 256 again. Is there not code sort of like that already in there? (I know, I could go look, but I have fallen way behind on the source code and the builds, so all I do now is kvetch from the outside). A similar approach would be to slowly adjust the DD to keep FPS acceptable. It seems like these DD slider changes are exactly giving the user a manual way to do this. Why not just have the viewer do it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110616/38a4bb43/attachment.htm From marinekelley at gmail.com Thu Jun 16 11:56:50 2011 From: marinekelley at gmail.com (Marine Kelley) Date: Thu, 16 Jun 2011 20:56:50 +0200 Subject: [opensource-dev] Question about DD philosophy. In-Reply-To: References: Message-ID: I think (correct me if I'm wrong) that everytime you increase your draw distance, your viewer requests all the prims to rez from the sim... Which means a lot more network traffic if it changes all the time (which would be the case if it were automatic). Besides I like to keep control over my draw distance. I vote for keeping it manual. Marine On 16/06/2011, Lee ponzu wrote: > I have sometimes wondered why this is not more automagic, or maybe why the > magic approach doesn't work well enough. > > Suppose my DD is set to 256. Upon detecting a poor FPS, the viewer could > remember the DD, and then reduce it temporarily to 32. As FPS becomes > acceptable, it increases it little by little until it is 256 again. Is > there not code sort of like that already in there? (I know, I could go > look, but I have fallen way behind on the source code and the builds, so all > I do now is kvetch from the outside). > > A similar approach would be to slowly adjust the DD to keep FPS acceptable. > > It seems like these DD slider changes are exactly giving the user a manual > way to do this. Why not just have the viewer do it? > From jhwelch at gmail.com Thu Jun 16 13:16:04 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Thu, 16 Jun 2011 16:16:04 -0400 Subject: [opensource-dev] Question about DD philosophy. In-Reply-To: References: Message-ID: At yesterday's meeting with Oz having a FPS auto-tune system was discussed. I am going to try to write up a description of how this could be implemented and once it is fleshed out will post it here for comments. -jonathan From log at lindenlab.com Thu Jun 16 13:32:49 2011 From: log at lindenlab.com (Log Linden) Date: Thu, 16 Jun 2011 20:32:49 -0000 Subject: [opensource-dev] Review Request: STORM-1320 Create a 3p-libndofdev-linux repo based on version 0.3 of Jan Ciger's linux libndofdev. Message-ID: <20110616203249.2650.83380@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/340/ ----------------------------------------------------------- Review request for Viewer, Oz Linden, Boroondas Gupte, and Altair Memo. Summary ------- Checked in version 0.3 of Jan Ciger's libndofdev drop-in replacement for linux. * Added cmake build configuration. * Added autobuild package configuration. * Created libndofdev.txt license file from ndofdev.c file header. * Added README to explain that this is only for use in the linux viewer. BUGFIXES: * OPEN-21 STORM-312 This version of libndofdev supports kernel versions >= 2.6.33. When reviewing, please provide extra scrutiny to autobuild.xml and CMakeLists.txt, since those are the files I actually edited. This addresses bugs OPEN-21, STORM-1320 and STORM-312. http://jira.secondlife.com/browse/OPEN-21 http://jira.secondlife.com/browse/STORM-1320 http://jira.secondlife.com/browse/STORM-312 Diffs ----- autobuild.xml PRE-CREATION libndofdev/CHANGELOG PRE-CREATION libndofdev/CMakeLists.txt PRE-CREATION libndofdev/LICENSES/libndofdev.txt PRE-CREATION libndofdev/README PRE-CREATION libndofdev/include/ndofdev_external.h PRE-CREATION libndofdev/ndofdev.c PRE-CREATION Diff: http://codereview.secondlife.com/r/340/diff Testing ------- This built successfully on TeamCity and the packaged library worked correctly when I extracted it into the packages directory of the viewer build tree ( build-linux-i686/packages ). My spacenavigator, which hasn't worked in six months, started working with the new build. Thanks, Log -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110616/3a7ec199/attachment.htm From vsavchuk at productengine.com Thu Jun 16 13:46:27 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Thu, 16 Jun 2011 20:46:27 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() Message-ID: <20110616204627.10141.42769@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/341/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. Attempt to sort active toasts in showToastsBottom() then triggered the crash. I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. So we'll just remove references to the toast whenever it's destroyed. This addresses bug STORM-1352. http://jira.secondlife.com/browse/STORM-1352 Diffs ----- indra/newview/llnearbychathandler.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/341/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110616/88487553/attachment.htm From sythos at gmail.com Thu Jun 16 13:47:04 2011 From: sythos at gmail.com (Altair Memo) Date: Thu, 16 Jun 2011 20:47:04 -0000 Subject: [opensource-dev] Review Request: STORM-1320 Create a 3p-libndofdev-linux repo based on version 0.3 of Jan Ciger's linux libndofdev. In-Reply-To: <20110616203249.2650.83380@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616203249.2650.83380@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110616204704.2655.621@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/340/#review758 ----------------------------------------------------------- Ship it! - Altair On June 16, 2011, 1:32 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/340/ > ----------------------------------------------------------- > > (Updated June 16, 2011, 1:32 p.m.) > > > Review request for Viewer, Oz Linden, Boroondas Gupte, and Altair Memo. > > > Summary > ------- > > Checked in version 0.3 of Jan Ciger's libndofdev drop-in replacement for linux. > * Added cmake build configuration. > * Added autobuild package configuration. > * Created libndofdev.txt license file from ndofdev.c file header. > * Added README to explain that this is only for use in the linux viewer. > > BUGFIXES: > * OPEN-21 STORM-312 This version of libndofdev supports kernel versions >= 2.6.33. > > When reviewing, please provide extra scrutiny to autobuild.xml and CMakeLists.txt, since those are the files I actually edited. > > > This addresses bugs OPEN-21, STORM-1320 and STORM-312. > http://jira.secondlife.com/browse/OPEN-21 > http://jira.secondlife.com/browse/STORM-1320 > http://jira.secondlife.com/browse/STORM-312 > > > Diffs > ----- > > autobuild.xml PRE-CREATION > libndofdev/CHANGELOG PRE-CREATION > libndofdev/CMakeLists.txt PRE-CREATION > libndofdev/LICENSES/libndofdev.txt PRE-CREATION > libndofdev/README PRE-CREATION > libndofdev/include/ndofdev_external.h PRE-CREATION > libndofdev/ndofdev.c PRE-CREATION > > Diff: http://codereview.secondlife.com/r/340/diff > > > Testing > ------- > > This built successfully on TeamCity and the packaged library worked correctly when I extracted it into the packages directory of the viewer build tree ( build-linux-i686/packages ). My spacenavigator, which hasn't worked in six months, started working with the new build. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110616/4ad29b64/attachment.htm From vsavchuk at productengine.com Thu Jun 16 13:52:44 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Thu, 16 Jun 2011 20:52:44 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() In-Reply-To: <20110616204627.10141.42769@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616204627.10141.42769@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110616205244.10191.77498@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/341/ ----------------------------------------------------------- (Updated June 16, 2011, 1:52 p.m.) Review request for Viewer. Changes ------- Added NULL checks to the sort functor. Summary ------- Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. Attempt to sort active toasts in showToastsBottom() then triggered the crash. I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. So we'll just remove references to the toast whenever it's destroyed. This addresses bug STORM-1352. http://jira.secondlife.com/browse/STORM-1352 Diffs (updated) ----- indra/newview/llnearbychathandler.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/341/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110616/e407554f/attachment.htm From sllists at boroon.dasgupta.ch Thu Jun 16 16:23:27 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 16 Jun 2011 23:23:27 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() In-Reply-To: <20110616205244.10191.77498@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616205244.10191.77498@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110616232327.2651.56191@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/341/#review759 ----------------------------------------------------------- indra/newview/llnearbychathandler.cpp This function's return type should be changed to bool, if it's intended for use with std::sort. (And that's how it's being used currently.) - Boroondas On June 16, 2011, 1:52 p.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/341/ > ----------------------------------------------------------- > > (Updated June 16, 2011, 1:52 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. > Attempt to sort active toasts in showToastsBottom() then triggered the crash. > > I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. > So we'll just remove references to the toast whenever it's destroyed. > > > This addresses bug STORM-1352. > http://jira.secondlife.com/browse/STORM-1352 > > > Diffs > ----- > > indra/newview/llnearbychathandler.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/341/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110616/706a07f4/attachment-0001.htm From sllists at boroon.dasgupta.ch Thu Jun 16 16:59:27 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 16 Jun 2011 23:59:27 -0000 Subject: [opensource-dev] Review Request: STORM-1320 Create a 3p-libndofdev-linux repo based on version 0.3 of Jan Ciger's linux libndofdev. In-Reply-To: <20110616203249.2650.83380@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616203249.2650.83380@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110616235927.10251.64369@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/340/#review760 ----------------------------------------------------------- Tested: I can produce a package with: autobuild install autobuild build autobuild package Haven't tested the resulting package, but it's content looks reasonable. autobuild.xml I guess it's not a problem that the paths in the package will collide with the paths of the non-linux libndofdev package, or is it? (If they were built from the same source, they'd collide too, wouldn't they?) libndofdev/CMakeLists.txt Jan Ciger's libndofdev comes with a Makefile. Why not use that? This lib is linux-specific, so we don't need a cross-platform build configuration for it. libndofdev/CMakeLists.txt If these flags are added unconditionally, how would one do a 64-bit build? Maybe check for WORD_SIZE, like the viewer build does. libndofdev/CMakeLists.txt Might be worth mentioning the non-linux libndofdev (and where to find it) in the error message. - Boroondas On June 16, 2011, 1:32 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/340/ > ----------------------------------------------------------- > > (Updated June 16, 2011, 1:32 p.m.) > > > Review request for Viewer, Oz Linden, Boroondas Gupte, and Altair Memo. > > > Summary > ------- > > Checked in version 0.3 of Jan Ciger's libndofdev drop-in replacement for linux. > * Added cmake build configuration. > * Added autobuild package configuration. > * Created libndofdev.txt license file from ndofdev.c file header. > * Added README to explain that this is only for use in the linux viewer. > > BUGFIXES: > * OPEN-21 STORM-312 This version of libndofdev supports kernel versions >= 2.6.33. > > When reviewing, please provide extra scrutiny to autobuild.xml and CMakeLists.txt, since those are the files I actually edited. > > > This addresses bugs OPEN-21, STORM-1320 and STORM-312. > http://jira.secondlife.com/browse/OPEN-21 > http://jira.secondlife.com/browse/STORM-1320 > http://jira.secondlife.com/browse/STORM-312 > > > Diffs > ----- > > autobuild.xml PRE-CREATION > libndofdev/CHANGELOG PRE-CREATION > libndofdev/CMakeLists.txt PRE-CREATION > libndofdev/LICENSES/libndofdev.txt PRE-CREATION > libndofdev/README PRE-CREATION > libndofdev/include/ndofdev_external.h PRE-CREATION > libndofdev/ndofdev.c PRE-CREATION > > Diff: http://codereview.secondlife.com/r/340/diff > > > Testing > ------- > > This built successfully on TeamCity and the packaged library worked correctly when I extracted it into the packages directory of the viewer build tree ( build-linux-i686/packages ). My spacenavigator, which hasn't worked in six months, started working with the new build. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110616/ab699ea5/attachment.htm From jhwelch at gmail.com Thu Jun 16 17:43:29 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 17 Jun 2011 00:43:29 -0000 Subject: [opensource-dev] Review Request: STORM-1320 Create a 3p-libndofdev-linux repo based on version 0.3 of Jan Ciger's linux libndofdev. In-Reply-To: <20110616235927.10251.64369@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616235927.10251.64369@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110617004329.10175.22436@domU-12-31-38-00-90-68.compute-1.internal> > On June 16, 2011, 4:59 p.m., Boroondas Gupte wrote: > > libndofdev/CMakeLists.txt, lines 27-30 > > > > > > Might be worth mentioning the non-linux libndofdev (and where to find it) in the error message. On windows I already get 4 lines such as: package pcre has no installation information configured for platform windows which is plenty of information for a package I have no need of; let's not put too much unnecessary text on the screen. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/340/#review760 ----------------------------------------------------------- On June 16, 2011, 1:32 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/340/ > ----------------------------------------------------------- > > (Updated June 16, 2011, 1:32 p.m.) > > > Review request for Viewer, Oz Linden, Boroondas Gupte, and Altair Memo. > > > Summary > ------- > > Checked in version 0.3 of Jan Ciger's libndofdev drop-in replacement for linux. > * Added cmake build configuration. > * Added autobuild package configuration. > * Created libndofdev.txt license file from ndofdev.c file header. > * Added README to explain that this is only for use in the linux viewer. > > BUGFIXES: > * OPEN-21 STORM-312 This version of libndofdev supports kernel versions >= 2.6.33. > > When reviewing, please provide extra scrutiny to autobuild.xml and CMakeLists.txt, since those are the files I actually edited. > > > This addresses bugs OPEN-21, STORM-1320 and STORM-312. > http://jira.secondlife.com/browse/OPEN-21 > http://jira.secondlife.com/browse/STORM-1320 > http://jira.secondlife.com/browse/STORM-312 > > > Diffs > ----- > > autobuild.xml PRE-CREATION > libndofdev/CHANGELOG PRE-CREATION > libndofdev/CMakeLists.txt PRE-CREATION > libndofdev/LICENSES/libndofdev.txt PRE-CREATION > libndofdev/README PRE-CREATION > libndofdev/include/ndofdev_external.h PRE-CREATION > libndofdev/ndofdev.c PRE-CREATION > > Diff: http://codereview.secondlife.com/r/340/diff > > > Testing > ------- > > This built successfully on TeamCity and the packaged library worked correctly when I extracted it into the packages directory of the viewer build tree ( build-linux-i686/packages ). My spacenavigator, which hasn't worked in six months, started working with the new build. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110617/45a51eb5/attachment-0001.htm From log at lindenlab.com Fri Jun 17 08:19:56 2011 From: log at lindenlab.com (Log Linden) Date: Fri, 17 Jun 2011 15:19:56 -0000 Subject: [opensource-dev] Review Request: STORM-1320 Create a 3p-libndofdev-linux repo based on version 0.3 of Jan Ciger's linux libndofdev. In-Reply-To: <20110616235927.10251.64369@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616235927.10251.64369@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110617151956.10251.36771@domU-12-31-38-00-90-68.compute-1.internal> > On June 16, 2011, 4:59 p.m., Boroondas Gupte wrote: > > libndofdev/CMakeLists.txt, lines 27-30 > > > > > > Might be worth mentioning the non-linux libndofdev (and where to find it) in the error message. > > Jonathan Yap wrote: > On windows I already get 4 lines such as: > package pcre has no installation information configured for platform windows > which is plenty of information for a package I have no need of; let's not put too much unnecessary text on the screen. Those messages are only be displayed during build configuration, and only if you try to build the package on windows or mac. They are there to alleviate confusion because we have two libndofdev packages, depending on the platform. Telling where to find the other library seems like a good idea. > On June 16, 2011, 4:59 p.m., Boroondas Gupte wrote: > > autobuild.xml, line 40 > > > > > > I guess it's not a problem that the paths in the package will collide with the paths of the non-linux libndofdev package, or is it? > > > > (If they were built from the same source, they'd collide too, wouldn't they?) The .a file in /lib has to collide anyway to work right. Autobuild install shouldn't install more than one of the packages. > On June 16, 2011, 4:59 p.m., Boroondas Gupte wrote: > > libndofdev/CMakeLists.txt, line 1 > > > > > > Jan Ciger's libndofdev comes with a Makefile. Why not use that? > > > > This lib is linux-specific, so we don't need a cross-platform build configuration for it. I would have needed to modify Jan's makefile to fit the autobuild package layout. I also used cmake because the other libndofdev library build also uses it. > On June 16, 2011, 4:59 p.m., Boroondas Gupte wrote: > > libndofdev/CMakeLists.txt, line 16 > > > > > > If these flags are added unconditionally, how would one do a 64-bit build? Maybe check for WORD_SIZE, like the viewer build does. I see m32 hard coded in several other libraries, including 3p-google-mock - Log ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/340/#review760 ----------------------------------------------------------- On June 16, 2011, 1:32 p.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/340/ > ----------------------------------------------------------- > > (Updated June 16, 2011, 1:32 p.m.) > > > Review request for Viewer, Oz Linden, Boroondas Gupte, and Altair Memo. > > > Summary > ------- > > Checked in version 0.3 of Jan Ciger's libndofdev drop-in replacement for linux. > * Added cmake build configuration. > * Added autobuild package configuration. > * Created libndofdev.txt license file from ndofdev.c file header. > * Added README to explain that this is only for use in the linux viewer. > > BUGFIXES: > * OPEN-21 STORM-312 This version of libndofdev supports kernel versions >= 2.6.33. > > When reviewing, please provide extra scrutiny to autobuild.xml and CMakeLists.txt, since those are the files I actually edited. > > > This addresses bugs OPEN-21, STORM-1320 and STORM-312. > http://jira.secondlife.com/browse/OPEN-21 > http://jira.secondlife.com/browse/STORM-1320 > http://jira.secondlife.com/browse/STORM-312 > > > Diffs > ----- > > autobuild.xml PRE-CREATION > libndofdev/CHANGELOG PRE-CREATION > libndofdev/CMakeLists.txt PRE-CREATION > libndofdev/LICENSES/libndofdev.txt PRE-CREATION > libndofdev/README PRE-CREATION > libndofdev/include/ndofdev_external.h PRE-CREATION > libndofdev/ndofdev.c PRE-CREATION > > Diff: http://codereview.secondlife.com/r/340/diff > > > Testing > ------- > > This built successfully on TeamCity and the packaged library worked correctly when I extracted it into the packages directory of the viewer build tree ( build-linux-i686/packages ). My spacenavigator, which hasn't worked in six months, started working with the new build. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110617/305f70b4/attachment.htm From nalates.u at gmail.com Fri Jun 17 08:21:58 2011 From: nalates.u at gmail.com (Nalates Urriah) Date: Fri, 17 Jun 2011 08:21:58 -0700 Subject: [opensource-dev] DD philosophy Message-ID: To consider implementing automatic(DD) Draw Distance changes one probably should consider all the possible ways this affects players, which is probably not the easiest thing to do. When shopping changing a DD probably would not be much of an issue, at least for me. However, I tend to enter a store and then cam around. I also tend to turn DD down when in a mall. Using 64m when things are a bit slow and even down to 32m when they remain slow. However when in a combat sim I do not want the DD to change. I set the DD depending on what is going on. I may turn off shaders to keep a high FPS. But, changing DD when I'm in combat would really piss me off. One is already clicking and key banging as fast as one can. Having to fight with DD to keep it as an acceptable distance would be extremely annoying. I would change away from any viewer that has automatic DD that degrades my combat experience. When I am using Kirsten's Viewer for Photography I often use maximum DD and graphics setting and tolerate low FPS, even 2 or 3 FPS is acceptable, for the sake of capturing a great image. An automatic DD change would also be extremely annoying in such a scenario. Any change to my rendering settings would be annoying. I'm not sure that FPS is the criteria that is most important to residents. I like higher FPS. I think once FPS is 15 or more performance is less important to residents and render quality becomes more important. That is rather subjective. Before making a change like adding automatic tuning for performance one needs to determine what people find acceptable. The blow back from the changes made to the initial SLV2 is an example of how irritate people. Changing the viewer settings at install times is reasonable. I don't hear people complaining. We can over ride those settings. Once we do, performance is on us. Changing my choices after that just irritates me and motivates people to use TPV's. -- Nalates Urriah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110617/dd224362/attachment.htm From log at lindenlab.com Fri Jun 17 08:32:55 2011 From: log at lindenlab.com (Log Linden) Date: Fri, 17 Jun 2011 15:32:55 -0000 Subject: [opensource-dev] Review Request: STORM-1320 Create a 3p-libndofdev-linux repo based on version 0.3 of Jan Ciger's linux libndofdev. In-Reply-To: <20110616203249.2650.83380@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616203249.2650.83380@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110617153255.10141.55059@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/340/ ----------------------------------------------------------- (Updated June 17, 2011, 8:32 a.m.) Review request for Viewer, Oz Linden, Boroondas Gupte, and Altair Memo. Changes ------- I incorporated the feedback I got here into a new revision. * Got rid of the hardcoded -m32 in CMakeLists.txt * Also got rid of hard coded cmake build type * Corrected the static library file location to lib/release * Added the new /lib/release folder to the autobuild manifest and removed /lib * Added the location of the other libndofdev library to the cmake warnings * Added a BuildParam to make the built package get uploaded to the public s3 The repo is also now up on bitbucket: http://bitbucket.org/lindenlab/3p-libndofdev-linux TC Build of this revision: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-libndofdev-linux/rev/233137/arch/Linux/installer/libndofdev-0.3-linux-20110617.tar.bz2 hash: 9bf7a96c1d2fadb180fda91740c945c6 I'll put up the viewer changeset shortly as a separate diff. Summary ------- Checked in version 0.3 of Jan Ciger's libndofdev drop-in replacement for linux. * Added cmake build configuration. * Added autobuild package configuration. * Created libndofdev.txt license file from ndofdev.c file header. * Added README to explain that this is only for use in the linux viewer. BUGFIXES: * OPEN-21 STORM-312 This version of libndofdev supports kernel versions >= 2.6.33. When reviewing, please provide extra scrutiny to autobuild.xml and CMakeLists.txt, since those are the files I actually edited. This addresses bugs OPEN-21, STORM-1320 and STORM-312. http://jira.secondlife.com/browse/OPEN-21 http://jira.secondlife.com/browse/STORM-1320 http://jira.secondlife.com/browse/STORM-312 Diffs (updated) ----- BuildParams PRE-CREATION autobuild.xml PRE-CREATION libndofdev/CHANGELOG PRE-CREATION libndofdev/CMakeLists.txt PRE-CREATION libndofdev/LICENSES/libndofdev.txt PRE-CREATION libndofdev/README PRE-CREATION libndofdev/include/ndofdev_external.h PRE-CREATION libndofdev/ndofdev.c PRE-CREATION Diff: http://codereview.secondlife.com/r/340/diff Testing ------- This built successfully on TeamCity and the packaged library worked correctly when I extracted it into the packages directory of the viewer build tree ( build-linux-i686/packages ). My spacenavigator, which hasn't worked in six months, started working with the new build. Thanks, Log -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110617/e10601f0/attachment-0001.htm From nexiim at gmail.com Fri Jun 17 08:33:06 2011 From: nexiim at gmail.com (Nexii Malthus) Date: Fri, 17 Jun 2011 16:33:06 +0100 Subject: [opensource-dev] Question about DD philosophy. In-Reply-To: References: Message-ID: Shouldn't 'network render' distance and graphics render distance be seperate kinda for this purpose? I could see graphics render distance auto-tune to FPS, but auto-tune should never touch the network distance controller, as that otherwise could cause havok. (As Marine explains) - Nexii On Thu, Jun 16, 2011 at 9:16 PM, Jonathan Welch wrote: > At yesterday's meeting with Oz having a FPS auto-tune system was > discussed. I am going to try to write up a description of how this > could be implemented and once it is fleshed out will post it here for > comments. > > -jonathan > _______________________________________________ > 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/20110617/de985ffc/attachment.htm From kf6kjg at gmail.com Fri Jun 17 09:27:59 2011 From: kf6kjg at gmail.com (Ricky) Date: Fri, 17 Jun 2011 09:27:59 -0700 Subject: [opensource-dev] DD philosophy In-Reply-To: References: Message-ID: This could be solvable in a manner that I've seen in some other programs: having the ability to state what your preference is. I've seen games and tool have a radio button set with one entry set to "high fps" and the other to "high detail" - or related terminology. Food for thought. Ricky Cron Stardust On Friday, June 17, 2011, Nalates Urriah wrote: > To consider implementing automatic(DD) Draw Distance changes one probably should consider all the possible ways this affects players, which is probably not the easiest thing to do. > When shopping changing a DD probably would not be much of an issue, at least for me. However, I tend to enter a store and then cam around. I also tend to turn DD down when in a mall. Using 64m when things are a bit slow and even down to 32m when they remain slow. > > However when in a combat sim I do not want the DD to change. I set the DD depending on what is going on. I may turn off shaders to keep a high FPS. But, changing DD when I'm in combat would really piss me off. One is already clicking and key banging as fast as one can. Having to fight with DD to keep it as an acceptable distance would be extremely annoying. I would change away from any viewer that has automatic DD that degrades my combat experience. > > When I am using Kirsten's Viewer for Photography I often use maximum DD and graphics setting and tolerate low FPS, even 2 or 3 FPS is acceptable, for the sake of capturing a great image. An automatic DD change would also be extremely annoying in such a scenario. Any change to my rendering settings would be annoying. > > I'm not sure that FPS is the criteria that is most important to residents. I like higher FPS. I think once FPS is 15 or more?performance?is less important to residents and render quality becomes more important. That is rather subjective. Before making a change like adding automatic tuning for performance one needs to determine what people find acceptable. The blow back from the changes made to the initial SLV2 is an example of how?irritate?people. > > Changing the viewer settings at install times is reasonable. I don't hear people complaining. We can over ride those settings. Once we do, performance is on us. Changing my choices after that just irritates me and motivates people to use TPV's. > > -- > Nalates Urriah > > From hitomi.tiponi at yahoo.co.uk Fri Jun 17 09:41:37 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Fri, 17 Jun 2011 17:41:37 +0100 (BST) Subject: [opensource-dev] DD Philosophy Message-ID: <443874.48527.qm@web23903.mail.ird.yahoo.com> Please no automatic DD - there are two many variables and differing circumstances for it ever to work.? Much better to work on other ways of improving fps e.g. selective updating of avatar movement. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110617/defdcaec/attachment.htm From sllists at boroon.dasgupta.ch Fri Jun 17 09:42:55 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 17 Jun 2011 16:42:55 -0000 Subject: [opensource-dev] Review Request: STORM-1320 Create a 3p-libndofdev-linux repo based on version 0.3 of Jan Ciger's linux libndofdev. In-Reply-To: <20110617153255.10141.55059@domU-12-31-38-00-90-68.compute-1.internal> References: <20110617153255.10141.55059@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110617164255.2652.9340@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/340/#review763 ----------------------------------------------------------- Ship it! My remaining comments are mere bike-shedding, thus giving "Ship it!". libndofdev/CMakeLists.txt Thanks for making this a bit future-proofer. :-) ADD_DEFINITION actually adds definitions, keeping previously added ones, doesn't it? So we could take the '-pipe' out of the conditional code: if (WORD_SIZE EQUAL 32) ADD_DEFINITIONS("-m32") elseif (WORD_SIZE EQUAL 64) ADD_DEFINITIONS("-m64") endif (WORD_SIZE EQUAL 32) ADD_DEFINITIONS("-pipe") Dunno if that's better though ... if in doubt, keep your version. (I also thought about replacing the whole block by ADD_DEFINITIONS("-m${WORD_SIZE} -pipe") but I guess an if-elseif is clearer.) libndofdev/CMakeLists.txt Good message texts! Though, end the second sentence with a period rather than arbitrary whitespace. - Boroondas On June 17, 2011, 8:32 a.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/340/ > ----------------------------------------------------------- > > (Updated June 17, 2011, 8:32 a.m.) > > > Review request for Viewer, Oz Linden, Boroondas Gupte, and Altair Memo. > > > Summary > ------- > > Checked in version 0.3 of Jan Ciger's libndofdev drop-in replacement for linux. > * Added cmake build configuration. > * Added autobuild package configuration. > * Created libndofdev.txt license file from ndofdev.c file header. > * Added README to explain that this is only for use in the linux viewer. > > BUGFIXES: > * OPEN-21 STORM-312 This version of libndofdev supports kernel versions >= 2.6.33. > > When reviewing, please provide extra scrutiny to autobuild.xml and CMakeLists.txt, since those are the files I actually edited. > > > This addresses bugs OPEN-21, STORM-1320 and STORM-312. > http://jira.secondlife.com/browse/OPEN-21 > http://jira.secondlife.com/browse/STORM-1320 > http://jira.secondlife.com/browse/STORM-312 > > > Diffs > ----- > > BuildParams PRE-CREATION > autobuild.xml PRE-CREATION > libndofdev/CHANGELOG PRE-CREATION > libndofdev/CMakeLists.txt PRE-CREATION > libndofdev/LICENSES/libndofdev.txt PRE-CREATION > libndofdev/README PRE-CREATION > libndofdev/include/ndofdev_external.h PRE-CREATION > libndofdev/ndofdev.c PRE-CREATION > > Diff: http://codereview.secondlife.com/r/340/diff > > > Testing > ------- > > This built successfully on TeamCity and the packaged library worked correctly when I extracted it into the packages directory of the viewer build tree ( build-linux-i686/packages ). My spacenavigator, which hasn't worked in six months, started working with the new build. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110617/e866cae0/attachment-0001.htm From zha.ewry at gmail.com Fri Jun 17 09:45:48 2011 From: zha.ewry at gmail.com (Zha Ewry) Date: Fri, 17 Jun 2011 12:45:48 -0400 Subject: [opensource-dev] DD philosophy In-Reply-To: References: Message-ID: I second pretty much all of these thoughts. I think any implementation of an Automatic DD would have to include a way to say "turn this off" I tune my experience to what I'm doing. low frame rates are completely acceptable when I want to see something completely and am not moving. Higher ones may be needed for combat, or exploring a large 3D model. I'll also point out that Draw distance is only one of several controls one can use to improve FPS, and any such control is going to be impacted by any of those changes as well. I fiddle with particle density, draw distance, and number of avatar imposters routinely. I've dialed down other bits of visual candy when I cared more FPS than pretty, or so I could explicitly dial up Draw Distance, or water reflections, or specific shaders. I think something where you could turn off the capability, and also set a target FPS would be very handy. Default it to something reasonable, and then let people how have strong opinions over-ride them. ~ Zha On Fri, Jun 17, 2011 at 11:21 AM, Nalates Urriah wrote: > To consider implementing automatic(DD) Draw Distance changes one probably > should consider all the possible ways this affects players, which is > probably not the easiest thing to do. > > When shopping changing a DD probably would not be much of an issue, at > least for me. However, I tend to enter a store and then cam around. I also > tend to turn DD down when in a mall. Using 64m when things are a bit slow > and even down to 32m when they remain slow. > > However when in a combat sim I do not want the DD to change. I set the DD > depending on what is going on. I may turn off shaders to keep a high FPS. > But, changing DD when I'm in combat would really piss me off. One is already > clicking and key banging as fast as one can. Having to fight with DD to keep > it as an acceptable distance would be extremely annoying. I would change > away from any viewer that has automatic DD that degrades my combat > experience. > > When I am using Kirsten's Viewer for Photography I often use maximum DD and > graphics setting and tolerate low FPS, even 2 or 3 FPS is acceptable, for > the sake of capturing a great image. An automatic DD change would also be > extremely annoying in such a scenario. Any change to my rendering settings > would be annoying. > > I'm not sure that FPS is the criteria that is most important to residents. > I like higher FPS. I think once FPS is 15 or more performance is less > important to residents and render quality becomes more important. That is > rather subjective. Before making a change like adding automatic tuning for > performance one needs to determine what people find acceptable. The blow > back from the changes made to the initial SLV2 is an example of > how irritate people. > > Changing the viewer settings at install times is reasonable. I don't hear > people complaining. We can over ride those settings. Once we do, performance > is on us. Changing my choices after that just irritates me and motivates > people to use TPV's. > > -- > Nalates Urriah > > _______________________________________________ > 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/20110617/2d246a8d/attachment.htm From Lance.Corrimal at eregion.de Fri Jun 17 10:25:51 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 17 Jun 2011 19:25:51 +0200 Subject: [opensource-dev] DD philosophy In-Reply-To: References: Message-ID: <201106171925.51242.Lance.Corrimal@eregion.de> Am Freitag, 17. Juni 2011 schrieb Zha Ewry: > I think any implementation of an Automatic DD would have to include > a way to say "turn this off". exactly. LC From log at lindenlab.com Fri Jun 17 10:45:10 2011 From: log at lindenlab.com (Log Linden) Date: Fri, 17 Jun 2011 17:45:10 -0000 Subject: [opensource-dev] Review Request: Update libndofdev in the linux viewer. This fixes the spacenavigator in linux. Message-ID: <20110617174510.3969.10636@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/342/ ----------------------------------------------------------- Review request for Viewer. Summary ------- I have updated the libndofdev library used by the viewer for spacenavigator support in Linux to version 0.3. The other two platforms should be unaffected. This patch is to fix the problem where the spacenavigator light turns on and the buttons work when you start second life, but the joystick itself does nothing. This addresses bugs OPEN-21, STORM-1320 and STORM-312. http://jira.secondlife.com/browse/OPEN-21 http://jira.secondlife.com/browse/STORM-1320 http://jira.secondlife.com/browse/STORM-312 Diffs ----- autobuild.xml dc5af272d23f Diff: http://codereview.secondlife.com/r/342/diff Testing ------- I have done local builds and the spacenavigator works for me with the new library. Autobuild install works correctly when fetching the new package. If you want to test, try this on a machine with a kernel of at least 2.6.33. Another way to tell that your machine should be fixed by this change is to run dmesg | grep Logitech and look for "fixing up rel/abs in Logitech report descriptor" in the output. Thanks, Log -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110617/66256412/attachment.htm From jhwelch at gmail.com Fri Jun 17 13:27:01 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 17 Jun 2011 16:27:01 -0400 Subject: [opensource-dev] Volunteer wanted: Wiki Skinning reorganization Message-ID: There are two top-level wiki entries for skinning: https://wiki.secondlife.com/wiki/Skinning_How_To https://wiki.secondlife.com/wiki/Skinning_HowTo I just created links to all the subsections in each of them and so discovered there are two categories with very similar names. There seems to be a mashup of V1 and V2 entries and sure could use some reorganization and cleanup. If you are looking for a project and know something about wiki formatting then reorganizing and cleaning up these entries is for you! -jonathan From lillie.yiyuan at gmail.com Fri Jun 17 15:08:25 2011 From: lillie.yiyuan at gmail.com (Lillian Yiyuan) Date: Fri, 17 Jun 2011 18:08:25 -0400 Subject: [opensource-dev] DD Philosophy In-Reply-To: <443874.48527.qm@web23903.mail.ird.yahoo.com> References: <443874.48527.qm@web23903.mail.ird.yahoo.com> Message-ID: Suggestion, have a version of the current advanced graphics settings, with "min" and "max" levels for each of the current options, and a fps target, as well as having a drop down for the priority of each. So for example, I might set DD to min 64m max of 256m, and a priority of "low," meaning that the viewer should reduce DD to keep fps. I might have particle settings, and set that with a priority of low, as well as min and max number of avatars to render and so on. On 6/17/11, Hitomi Tiponi wrote: > Please no automatic DD - there are two many variables and differing > circumstances for it ever to work.? Much better to work on other ways of > improving fps e.g. selective updating of avatar movement. > From sllists at boroon.dasgupta.ch Fri Jun 17 15:10:25 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 17 Jun 2011 22:10:25 -0000 Subject: [opensource-dev] Review Request: Update libndofdev in the linux viewer. This fixes the spacenavigator in linux. In-Reply-To: <20110617174510.3969.10636@domU-12-31-38-00-90-68.compute-1.internal> References: <20110617174510.3969.10636@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110617221025.2655.60468@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/342/#review764 ----------------------------------------------------------- Ship it! - Boroondas On June 17, 2011, 10:45 a.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/342/ > ----------------------------------------------------------- > > (Updated June 17, 2011, 10:45 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > I have updated the libndofdev library used by the viewer for spacenavigator support in Linux to version 0.3. The other two platforms should be unaffected. This patch is to fix the problem where the spacenavigator light turns on and the buttons work when you start second life, but the joystick itself does nothing. > > > This addresses bugs OPEN-21, STORM-1320 and STORM-312. > http://jira.secondlife.com/browse/OPEN-21 > http://jira.secondlife.com/browse/STORM-1320 > http://jira.secondlife.com/browse/STORM-312 > > > Diffs > ----- > > autobuild.xml dc5af272d23f > > Diff: http://codereview.secondlife.com/r/342/diff > > > Testing > ------- > > I have done local builds and the spacenavigator works for me with the new library. Autobuild install works correctly when fetching the new package. If you want to test, try this on a machine with a kernel of at least 2.6.33. Another way to tell that your machine should be fixed by this change is to run dmesg | grep Logitech and look for "fixing up rel/abs in Logitech report descriptor" in the output. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110617/e5b6500a/attachment.htm From jhwelch at gmail.com Sat Jun 18 04:12:44 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Sat, 18 Jun 2011 11:12:44 -0000 Subject: [opensource-dev] Review Request: STORM-1392 Add Nearby Voice to the Communicate menu Message-ID: <20110618111244.10175.89907@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/346/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Add Nearby Voice to the Communicate menu. This is currently activated via the flyout button next to the Speak button. This addresses bug STORM-1392. http://jira.secondlife.com/browse/STORM-1392 Diffs ----- doc/contributions.txt dc5af272d23f indra/newview/llbottomtray.cpp dc5af272d23f indra/newview/skins/default/xui/en/menu_viewer.xml dc5af272d23f Diff: http://codereview.secondlife.com/r/346/diff Testing ------- Clicking menu entry toggles appearance/disappearance of Nearby Voice floater. Noted that this menu entry is grayed out when voice is off or otherwise not available. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/0a2edb9b/attachment.htm From sllists at boroon.dasgupta.ch Sat Jun 18 04:24:08 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 18 Jun 2011 11:24:08 -0000 Subject: [opensource-dev] Review Request: STORM-1392 Add Nearby Voice to the Communicate menu In-Reply-To: <20110618111244.10175.89907@domU-12-31-38-00-90-68.compute-1.internal> References: <20110618111244.10175.89907@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110618112408.10175.39305@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/346/#review771 ----------------------------------------------------------- indra/newview/llbottomtray.cpp Wouldn't it be better to set the initial disabledness for all three items here in the XUI-XML with https://wiki.secondlife.com/wiki/Skinning_HowTo/Common_XUI_attributes#enabled rather than in the CPP code? (Assuming that subsequent setEnabled(voice_status) will override it in either case, so that it can still be toggled.) - Boroondas On June 18, 2011, 4:12 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/346/ > ----------------------------------------------------------- > > (Updated June 18, 2011, 4:12 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Add Nearby Voice to the Communicate menu. This is currently activated via the flyout button next to the Speak button. > > > This addresses bug STORM-1392. > http://jira.secondlife.com/browse/STORM-1392 > > > Diffs > ----- > > doc/contributions.txt dc5af272d23f > indra/newview/llbottomtray.cpp dc5af272d23f > indra/newview/skins/default/xui/en/menu_viewer.xml dc5af272d23f > > Diff: http://codereview.secondlife.com/r/346/diff > > > Testing > ------- > > Clicking menu entry toggles appearance/disappearance of Nearby Voice floater. > > Noted that this menu entry is grayed out when voice is off or otherwise not available. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/b97b01e3/attachment-0001.htm From nexiim at gmail.com Sat Jun 18 04:51:40 2011 From: nexiim at gmail.com (Nexii Malthus) Date: Sat, 18 Jun 2011 12:51:40 +0100 Subject: [opensource-dev] DD Philosophy In-Reply-To: References: <443874.48527.qm@web23903.mail.ird.yahoo.com> Message-ID: Here's another suggestion, Take away the network portion of Draw Distance and make it Network Distance. That is, the value that is sent to the sim and that affects how many objects are tracked by the client must be a separate setting and nothing to do with actual rendering. Draw Distance should really only have to do with rendering and LOD. People in a combat sim would choose to have high network distance but a low render distance. Actually being able to control the actual render distance would help control FPS more precisely. (Network distance could then be adjusted to the amount of RAM available) - Nexii On Fri, Jun 17, 2011 at 11:08 PM, Lillian Yiyuan wrote: > Suggestion, have a version of the current advanced graphics settings, > with "min" and "max" levels for each of the current options, and a fps > target, as well as having a drop down for the priority of each. So for > example, I might set DD to min 64m max of 256m, and a priority of > "low," meaning that the viewer should reduce DD to keep fps. I might > have particle settings, and set that with a priority of low, as well > as min and max number of avatars to render and so on. > > > On 6/17/11, Hitomi Tiponi wrote: > > Please no automatic DD - there are two many variables and differing > > circumstances for it ever to work. Much better to work on other ways of > > improving fps e.g. selective updating of avatar movement. > > > _______________________________________________ > 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/20110618/b2383db5/attachment.htm From jhwelch at gmail.com Sat Jun 18 05:54:49 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Sat, 18 Jun 2011 12:54:49 -0000 Subject: [opensource-dev] Review Request: STORM-1392 Add Nearby Voice to the Communicate menu In-Reply-To: <20110618112408.10175.39305@domU-12-31-38-00-90-68.compute-1.internal> References: <20110618112408.10175.39305@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110618125449.10251.34118@domU-12-31-38-00-90-68.compute-1.internal> > On June 18, 2011, 4:24 a.m., Boroondas Gupte wrote: > > indra/newview/llbottomtray.cpp, lines 570-574 > > > > > > Wouldn't it be better to set the initial disabledness for all three items here in the XUI-XML with https://wiki.secondlife.com/wiki/Skinning_HowTo/Common_XUI_attributes#enabled rather than in the CPP code? > > > > (Assuming that subsequent setEnabled(voice_status) will override it in either case, so that it can still be toggled.) Code refactoring this area is a good idea but is outside the narrow scope of this jira. If some Linden thinks this should be done I will make the changes. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/346/#review771 ----------------------------------------------------------- On June 18, 2011, 4:12 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/346/ > ----------------------------------------------------------- > > (Updated June 18, 2011, 4:12 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Add Nearby Voice to the Communicate menu. This is currently activated via the flyout button next to the Speak button. > > > This addresses bug STORM-1392. > http://jira.secondlife.com/browse/STORM-1392 > > > Diffs > ----- > > doc/contributions.txt dc5af272d23f > indra/newview/llbottomtray.cpp dc5af272d23f > indra/newview/skins/default/xui/en/menu_viewer.xml dc5af272d23f > > Diff: http://codereview.secondlife.com/r/346/diff > > > Testing > ------- > > Clicking menu entry toggles appearance/disappearance of Nearby Voice floater. > > Noted that this menu entry is grayed out when voice is off or otherwise not available. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/94d117c8/attachment.htm From sllists at boroon.dasgupta.ch Sat Jun 18 05:56:38 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 18 Jun 2011 12:56:38 -0000 Subject: [opensource-dev] Review Request: STORM-1392 Add Nearby Voice to the Communicate menu In-Reply-To: <20110618112408.10175.39305@domU-12-31-38-00-90-68.compute-1.internal> References: <20110618112408.10175.39305@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110618125638.10191.28562@domU-12-31-38-00-90-68.compute-1.internal> > On June 18, 2011, 4:24 a.m., Boroondas Gupte wrote: > > indra/newview/llbottomtray.cpp, lines 570-574 > > > > > > Wouldn't it be better to set the initial disabledness for all three items here in the XUI-XML with https://wiki.secondlife.com/wiki/Skinning_HowTo/Common_XUI_attributes#enabled rather than in the CPP code? > > > > (Assuming that subsequent setEnabled(voice_status) will override it in either case, so that it can still be toggled.) > > Jonathan Yap wrote: > Code refactoring this area is a good idea but is outside the narrow scope of this jira. If some Linden thinks this should be done I will make the changes. You're right. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/346/#review771 ----------------------------------------------------------- On June 18, 2011, 4:12 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/346/ > ----------------------------------------------------------- > > (Updated June 18, 2011, 4:12 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Add Nearby Voice to the Communicate menu. This is currently activated via the flyout button next to the Speak button. > > > This addresses bug STORM-1392. > http://jira.secondlife.com/browse/STORM-1392 > > > Diffs > ----- > > doc/contributions.txt dc5af272d23f > indra/newview/llbottomtray.cpp dc5af272d23f > indra/newview/skins/default/xui/en/menu_viewer.xml dc5af272d23f > > Diff: http://codereview.secondlife.com/r/346/diff > > > Testing > ------- > > Clicking menu entry toggles appearance/disappearance of Nearby Voice floater. > > Noted that this menu entry is grayed out when voice is off or otherwise not available. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/525bb29c/attachment-0001.htm From sllists at boroon.dasgupta.ch Sat Jun 18 05:56:44 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 18 Jun 2011 12:56:44 -0000 Subject: [opensource-dev] Review Request: STORM-1392 Add Nearby Voice to the Communicate menu In-Reply-To: <20110618111244.10175.89907@domU-12-31-38-00-90-68.compute-1.internal> References: <20110618111244.10175.89907@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110618125644.3651.43984@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/346/#review774 ----------------------------------------------------------- Ship it! - Boroondas On June 18, 2011, 4:12 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/346/ > ----------------------------------------------------------- > > (Updated June 18, 2011, 4:12 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Add Nearby Voice to the Communicate menu. This is currently activated via the flyout button next to the Speak button. > > > This addresses bug STORM-1392. > http://jira.secondlife.com/browse/STORM-1392 > > > Diffs > ----- > > doc/contributions.txt dc5af272d23f > indra/newview/llbottomtray.cpp dc5af272d23f > indra/newview/skins/default/xui/en/menu_viewer.xml dc5af272d23f > > Diff: http://codereview.secondlife.com/r/346/diff > > > Testing > ------- > > Clicking menu entry toggles appearance/disappearance of Nearby Voice floater. > > Noted that this menu entry is grayed out when voice is off or otherwise not available. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/9a0eb549/attachment.htm From jhwelch at gmail.com Sat Jun 18 06:06:18 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Sat, 18 Jun 2011 09:06:18 -0400 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: Message-ID: There is an updated version of the draw distance review viewer here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-1/rev/233253/index.html Changes include slightly better artwork, re-repositioning of the icon's location, and if you exceed 280m a notification (which you can suppress) appears alerting you that your performance may suffer. Notification processing is done after you move your mouse away from the slider. The only other tester than myself (Oz) reported that this notification appeared minutes after it should have. Why this would be the case is a mystery to me. If you would like to test this and have this issue please report it here. From wolfpup67 at earthlink.net Sat Jun 18 06:36:25 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Sat, 18 Jun 2011 09:36:25 -0400 Subject: [opensource-dev] DD Philosophy In-Reply-To: References: <443874.48527.qm@web23903.mail.ird.yahoo.com> Message-ID: <001801cc2dbc$b8962150$29c263f0$@net> If you do that those with 'poor' network connection but 'excellent' video cards might 'suffer' as now there would be a lot of network traffic retrieving all that information even if their draw distance is set to a short distance. Also if you base it on the amount of memory then someone like me that has a video card with 1GB of onboard vid mem and 4GB of system mem might end up pulling information for an area covering from anywhere to a few sims to a few hundred depending on their complexity. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Nexii Malthus Sent: Saturday, June 18, 2011 7:52 AM To: Lillian Yiyuan Cc: Hitomi Tiponi; Opensource_dev Subject: Re: [opensource-dev] DD Philosophy Here's another suggestion, Take away the network portion of Draw Distance and make it Network Distance. That is, the value that is sent to the sim and that affects how many objects are tracked by the client must be a separate setting and nothing to do with actual rendering. Draw Distance should really only have to do with rendering and LOD. People in a combat sim would choose to have high network distance but a low render distance. Actually being able to control the actual render distance would help control FPS more precisely. (Network distance could then be adjusted to the amount of RAM available) - Nexii On Fri, Jun 17, 2011 at 11:08 PM, Lillian Yiyuan wrote: Suggestion, have a version of the current advanced graphics settings, with "min" and "max" levels for each of the current options, and a fps target, as well as having a drop down for the priority of each. So for example, I might set DD to min 64m max of 256m, and a priority of "low," meaning that the viewer should reduce DD to keep fps. I might have particle settings, and set that with a priority of low, as well as min and max number of avatars to render and so on. On 6/17/11, Hitomi Tiponi wrote: > Please no automatic DD - there are two many variables and differing > circumstances for it ever to work. Much better to work on other ways of > improving fps e.g. selective updating of avatar movement. > _______________________________________________ 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 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1382 / Virus Database: 1513/3711 - Release Date: 06/18/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/faeb222b/attachment.htm From serpentu at gmail.com Sat Jun 18 07:59:58 2011 From: serpentu at gmail.com (Vaalith Jinn) Date: Sat, 18 Jun 2011 14:59:58 -0000 Subject: [opensource-dev] Review Request: Local Bitmap Browser implementation. Message-ID: <20110618145958.4024.26771@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/347/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Local Bitmap Browser is a mechanism to locally load images into the viewer, track them and optionally (per each image) have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. This change affects build menu by adding a way to open the floater there. This change also affects the texture picker - adding tabs that lets the user choose between the "Server" (regular inventory) and "Local" tabs (list of locally added files). This addresses bug https://jira.secondlife.com/browse/STORM-64. http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/STORM-64 Diffs ----- doc/contributions.txt 6a3e7e403bd1 indra/llmath/llvolumemgr.h 6a3e7e403bd1 indra/llmath/llvolumemgr.cpp 6a3e7e403bd1 indra/newview/CMakeLists.txt 6a3e7e403bd1 indra/newview/llfloaterlocalbitmap.h PRE-CREATION indra/newview/llfloaterlocalbitmap.cpp PRE-CREATION indra/newview/lltexturectrl.h 6a3e7e403bd1 indra/newview/lltexturectrl.cpp 6a3e7e403bd1 indra/newview/llviewerfloaterreg.cpp 6a3e7e403bd1 indra/newview/llviewerobjectlist.h 6a3e7e403bd1 indra/newview/llviewertexturelist.h 6a3e7e403bd1 indra/newview/llvovolume.h 6a3e7e403bd1 indra/newview/skins/default/xui/en/floater_local_bitmap.xml PRE-CREATION indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 6a3e7e403bd1 indra/newview/skins/default/xui/en/menu_viewer.xml 6a3e7e403bd1 Diff: http://codereview.secondlife.com/r/347/diff Testing ------- Texture/Sculptmap/Avatar Layer show. Texture/Sculptmap/Avatar Layer update. Multiple sculpties update. Opening multiple browser floaters works correctly. (two possible since one can be opened from menu above, one from texture picker. all of them + texture picker play nice.) Tested adding over 200 images at the same time. Thanks, Vaalith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/549f383b/attachment.htm From serpentu at gmail.com Sat Jun 18 08:04:47 2011 From: serpentu at gmail.com (Vaalith Jinn) Date: Sat, 18 Jun 2011 15:04:47 -0000 Subject: [opensource-dev] Review Request: Local Bitmap Browser implementation. In-Reply-To: <20110618145958.4024.26771@domU-12-31-38-00-90-68.compute-1.internal> References: <20110618145958.4024.26771@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110618150447.3681.36306@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/347/ ----------------------------------------------------------- (Updated June 18, 2011, 8:04 a.m.) Review request for Viewer. Summary ------- Local Bitmap Browser is a mechanism to locally load images into the viewer, track them and optionally (per each image) have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. This change affects build menu by adding a way to open the floater there. This change also affects the texture picker - adding tabs that lets the user choose between the "Server" (regular inventory) and "Local" tabs (list of locally added files). This addresses bug STORM-64. http://jira.secondlife.com/browse/STORM-64 Diffs ----- doc/contributions.txt 6a3e7e403bd1 indra/llmath/llvolumemgr.h 6a3e7e403bd1 indra/llmath/llvolumemgr.cpp 6a3e7e403bd1 indra/newview/CMakeLists.txt 6a3e7e403bd1 indra/newview/llfloaterlocalbitmap.h PRE-CREATION indra/newview/llfloaterlocalbitmap.cpp PRE-CREATION indra/newview/lltexturectrl.h 6a3e7e403bd1 indra/newview/lltexturectrl.cpp 6a3e7e403bd1 indra/newview/llviewerfloaterreg.cpp 6a3e7e403bd1 indra/newview/llviewerobjectlist.h 6a3e7e403bd1 indra/newview/llviewertexturelist.h 6a3e7e403bd1 indra/newview/llvovolume.h 6a3e7e403bd1 indra/newview/skins/default/xui/en/floater_local_bitmap.xml PRE-CREATION indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 6a3e7e403bd1 indra/newview/skins/default/xui/en/menu_viewer.xml 6a3e7e403bd1 Diff: http://codereview.secondlife.com/r/347/diff Testing ------- Texture/Sculptmap/Avatar Layer show. Texture/Sculptmap/Avatar Layer update. Multiple sculpties update. Opening multiple browser floaters works correctly. (two possible since one can be opened from menu above, one from texture picker. all of them + texture picker play nice.) Tested adding over 200 images at the same time. Thanks, Vaalith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/8f5ac56e/attachment-0001.htm From sllists at boroon.dasgupta.ch Sat Jun 18 08:41:12 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 18 Jun 2011 15:41:12 -0000 Subject: [opensource-dev] Review Request: Local Bitmap Browser implementation. In-Reply-To: <20110618150447.3681.36306@domU-12-31-38-00-90-68.compute-1.internal> References: <20110618150447.3681.36306@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110618154112.10191.28232@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/347/#review775 ----------------------------------------------------------- indra/newview/CMakeLists.txt Please use 4 spaces for indentation instead of a tab, here, to be consistent with the surrounding lines. indra/newview/CMakeLists.txt same here - Boroondas On June 18, 2011, 8:04 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/347/ > ----------------------------------------------------------- > > (Updated June 18, 2011, 8:04 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Local Bitmap Browser is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects build menu by adding a way to open the floater there. > This change also affects the texture picker - adding tabs that lets the user choose between the "Server" (regular inventory) and "Local" tabs (list of locally added files). > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 6a3e7e403bd1 > indra/llmath/llvolumemgr.h 6a3e7e403bd1 > indra/llmath/llvolumemgr.cpp 6a3e7e403bd1 > indra/newview/CMakeLists.txt 6a3e7e403bd1 > indra/newview/llfloaterlocalbitmap.h PRE-CREATION > indra/newview/llfloaterlocalbitmap.cpp PRE-CREATION > indra/newview/lltexturectrl.h 6a3e7e403bd1 > indra/newview/lltexturectrl.cpp 6a3e7e403bd1 > indra/newview/llviewerfloaterreg.cpp 6a3e7e403bd1 > indra/newview/llviewerobjectlist.h 6a3e7e403bd1 > indra/newview/llviewertexturelist.h 6a3e7e403bd1 > indra/newview/llvovolume.h 6a3e7e403bd1 > indra/newview/skins/default/xui/en/floater_local_bitmap.xml PRE-CREATION > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 6a3e7e403bd1 > indra/newview/skins/default/xui/en/menu_viewer.xml 6a3e7e403bd1 > > Diff: http://codereview.secondlife.com/r/347/diff > > > Testing > ------- > > Texture/Sculptmap/Avatar Layer show. > Texture/Sculptmap/Avatar Layer update. > Multiple sculpties update. > Opening multiple browser floaters works correctly. (two possible since one can be opened from menu above, one from texture picker. all of them + texture picker play nice.) > Tested adding over 200 images at the same time. > > > Thanks, > > Vaalith > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/1b94fb12/attachment.htm From lee.ponzu at gmail.com Sat Jun 18 09:44:10 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Sat, 18 Jun 2011 12:44:10 -0400 Subject: [opensource-dev] Question about DD philosophy. In-Reply-To: References: Message-ID: I can see the merit of all the objections to automating DD in this and the other thread. I am not trying to be stubborn here. However, the objections have all been "expert power user" in nature, rather than "Faster, Funner, Easier" or whatever mantra was. 1. Certainly, adding a way to disable automatic anything is ideal. Of course, there are already lots of automatic performance enhancers, are there not? Can we disable all of them? 2. It is also not a question of Auto vs Manual. There could be a continuum between the two, and each factor---objects, textures, distance, shadows---could be separate. Anyway, I look forward to hearing the FPS Management proposal fron Nexii and others who actually know how the viewer works, as opposed to random ideas from me 8-) On Fri, Jun 17, 2011 at 11:33 AM, Nexii Malthus wrote: > Shouldn't 'network render' distance and graphics render distance be > seperate kinda for this purpose? > > I could see graphics render distance auto-tune to FPS, but auto-tune should > never touch the network distance controller, as that otherwise could cause > havok. (As Marine explains) > > - Nexii > > On Thu, Jun 16, 2011 at 9:16 PM, Jonathan Welch wrote: > >> At yesterday's meeting with Oz having a FPS auto-tune system was >> discussed. I am going to try to write up a description of how this >> could be implemented and once it is fleshed out will post it here for >> comments. >> >> -jonathan >> _______________________________________________ >> 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 >> > > > _______________________________________________ > 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/20110618/4763ee8d/attachment.htm From lee.ponzu at gmail.com Sat Jun 18 09:48:34 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Sat, 18 Jun 2011 12:48:34 -0400 Subject: [opensource-dev] Question about DD philosophy. In-Reply-To: References: Message-ID: On Thu, Jun 16, 2011 at 2:56 PM, Marine Kelley wrote: > > Besides I like to keep control over my draw distance. I vote for > keeping it manual. > Note that my much over-simplified heuristic (from my much-oversimplified mind 8-) still gives complete control over MAX DD. As for re-requesting all the prims on DD change, I guess that would have to change, and if that is difficult, then that is a problem. ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/ed8e166f/attachment.htm From lee.ponzu at gmail.com Sat Jun 18 10:00:04 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Sat, 18 Jun 2011 13:00:04 -0400 Subject: [opensource-dev] Is it just me? Avatar textures downloading last. Message-ID: Wow!! Shadows are nice! However, and unrelated to shadows, I began to notice last night that while my scenes had all downloaded, the avatars around me were still all gray. Their objects were OK, it was just their skin and cloth final bake that is missing. They do show up after several minutes, but long after everything else. I was using 2.7.4. however, I think I noticed this starting about a week ago, when I was using the Jun 10 latest development build. I also see it on my Macbook pro, which has a slightly better gpu (n9400). I saw the discussion of retrying to upload one's own texture. Could that fix, if it is even in yet, have had this effect? I don't think so, but perhaps... Anyway, if I see this again, should I start a Jira? Or maybe there is one there already. ponzu = Second Life 2.7.4 (232938) Jun 15 2011 12:44:34 (Second Life Development) Release Notes CPU: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (2400 MHz) Memory: 3072 MB OS Version: Mac OS X 10.6.7 Darwin 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 Graphics Card Vendor: ATI Technologies Inc. Graphics Card: ATI Radeon HD 2600 PRO OpenGL Engine OpenGL Version: 2.1 ATI-1.6.26 libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1 J2C Decoder Version: KDU v6.4.1 Audio Driver Version: FMOD version 3.750000 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Not Connected Built with GCC version 40001 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/c8f65caa/attachment-0001.htm From lee.ponzu at gmail.com Sat Jun 18 10:09:09 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Sat, 18 Jun 2011 13:09:09 -0400 Subject: [opensource-dev] Restating the DD question (was Re: DD Philosophy Message-ID: Is it cost effective to add *more automation* to the task of helping most users achieve their *desired level of FPS* funner, faster, and easier without ruining the ability users with special needs or knowledge to retain manual control? On Fri, Jun 17, 2011 at 12:41 PM, Hitomi Tiponi wrote: > Please no automatic DD - there are two many variables and differing > circumstances for it ever to work. Much better to work on other ways of > improving fps e.g. selective updating of avatar movement. > > _______________________________________________ > 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/20110618/6509728e/attachment.htm From fleep513 at gmail.com Sat Jun 18 10:25:06 2011 From: fleep513 at gmail.com (Fleep Tuque) Date: Sat, 18 Jun 2011 13:25:06 -0400 Subject: [opensource-dev] Second Life Community Convention 2011 Message-ID: With apologies for cross posting, and just a note that we are still seeking a Track Leader for the Development & Open Source track. If you might be interested, Track Leaders receive a complimentary convention registration and small travel stipend to help with costs. Apply at http://www.slconvention.org/staff/open-staff-positions/ Thanks! - Fleep -== Second Life Community Convention 2011 ==- When: August 12 - 14, 2011 Where: Oakland, CA | Oakland Marriott City Center REGISTER NOW! http://www.slconvention.org/registration/ WEBSITE: http://slconvention.org The Second Life Community Convention is three days of exciting activities, events, musical performances, machinima screenings, panels, workshops, and much more that showcases the abundant creativity of Second Life Residents. SLCC is organized BY Resident FOR Residents, and we invite you to join the fun! SUBMIT A PROPOSAL The Call for Proposals is up, and with five new track themes and fun presentation formats, you have the opportunity to share your hard work and creativity with the community that will most appreciate your efforts. Don?t want to give a full presentation? Consider doing a Speed Sparks session of 20 slides in 5 minutes to share the gist of your idea in a fast-paced presentation style that was a huge hit last year! This year?s convention tracks will include: Artistic & Creative Expression Commerce & Marketing Developers & Open Source Public Sector & Education Social Experience & Communities You may submit your proposal at: http://www.slconvention.org/program/call-for-proposals/ VOLUNTEER IN OAKLAND SLCC Volunteers are convention attendees who are very committed to making the Second Life Community Convention a true community experience while helping to ensure our convention runs smoothly. Volunteers help with many important aspects of the convention including registration assistance, helping direct convention flow and attendees, assisting in track and content management, along with many of the ?on the ground? logistical items necessary for the convention. Be a volunteer! Sign up at: http://www.slconvention.org/staff/oakland-volunteer-application/ VOLUNTEER IN SECOND LIFE Volunteers in Second Life help with running all of the virtual activities related to SLCC, including helping build, script, and design the virtual conference facilities, moderating panels and helping synch video streams with the team in Oakland, greeting and helping audience members who attend in Second Life, and much more! Volunteer in Second Life! Sign up at: http://www.slconvention.org/staff/in-world-volunteer-application/ SPONSOR SLCC FOR AS LOW AS $50 USD! Sponsorship opportunities are available for the 7th annual Second Life Community Convention. Sponsors have the opportunity to reach a highly coveted target demographic of tech-savvy early adopters, virtual world developers and thought leaders, online community organizers, and the most innovative and dedicated Second Life residents. Get your name or business out to the Second Life community! Sponsorship packages begin at $50 USD and go up to $10,000 USD, with benefits including free convention passes, logos included on the Tshirt and bags, logos on convention signage, display tables, logos on the website and in-world kiosk, and much more! Sponsor SLCC today! See http://www.slconvention.org/sponsors/call-for-sponsors/ for more information! HELP US SPREAD THE WORD Even if you can't attend SLCC this year, we hope you'll help us spread the word by posting, blogging, and forwarding this announcement to your various groups, communities, and listservs. SLCC is run FOR residents BY residents and that means we don't have big fancy advertising budgets! Thanks so much for your interest and help with the Second Life Community Convention 2011. We are very excited about this year's convention, and we hope to see you in Oakland! Sincerely, Joyce Bettencourt (SL: Rhiannon Chatnoir) Chris Collins (SL: Fleep Tuque) Donna Meyer (SL: Misty Rhodes) Kathey Fatica (SL: Katydid Something) Second Life Community Convention 2011 Oakland, CA | August 12-14, 2011 Organized by AvaCon, Inc. (774) 654-0010 info at avacon.org http://slconvention.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/9d2536af/attachment.htm From robertltux at gmail.com Sat Jun 18 11:00:35 2011 From: robertltux at gmail.com (Robert Martin) Date: Sat, 18 Jun 2011 14:00:35 -0400 Subject: [opensource-dev] Question about DD philosophy. In-Reply-To: References: Message-ID: What i would think should happen is 1 a very clear set of controls (a set of sliders with a number input box would be good) 2 a way to control any kind of auto set function (min max and OFF maybe) 3 a very clearly stated wiki page on this function to explain what is going on btw it is a function of some TPVs to have the DD pop to a low level and then ratchet to the set distance in steps. one thing that i don't understand is why you can be at 4000 meters in an untextured skybox and still within seconds get GROUND TEXTURES and other objects on the sim before the contents of the skybox or attachments on the client avatar (this even happens with a very short draw distances). -- Robert L Martin From hitomi.tiponi at yahoo.co.uk Sat Jun 18 13:38:37 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Sat, 18 Jun 2011 21:38:37 +0100 (BST) Subject: [opensource-dev] Review viewer -- draw distance slider Message-ID: <686840.98995.qm@web23902.mail.ird.yahoo.com> Seems to work fine Jonathan. I had no trouble with the notification lagging. >There is an updated version of the draw distance review viewer here: >http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-1/rev/233253/index.html >l ... > The only other tester than myself (Oz) reported that this notification > appeared minutes after it should have. Why this would be the case is > a mystery to me. If you would like to test this and have this issue > please report it here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/af573b7c/attachment.htm From lee.ponzu at gmail.com Sat Jun 18 13:43:00 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Sat, 18 Jun 2011 16:43:00 -0400 Subject: [opensource-dev] Is it just me? Avatar textures downloading last. In-Reply-To: References: Message-ID: Extra symptom. So, there I am, and the avatars are all rendered as expected, when --blink-- one of them turns gray, like the texture got lost. No, she didn't change to an all gray skin and outfit. 8-) ponzu On Sat, Jun 18, 2011 at 1:00 PM, Lee ponzu wrote: > Wow!! Shadows are nice! > > However, and unrelated to shadows, I began to notice last night that while > my scenes had all downloaded, the avatars around me were still all gray. > Their objects were OK, it was just their skin and cloth final bake that is > missing. They do show up after several minutes, but long after everything > else. > > I was using 2.7.4. however, I think I noticed this starting about a week > ago, when I was using the Jun 10 latest development build. I also see it on > my Macbook pro, which has a slightly better gpu (n9400). > > I saw the discussion of retrying to upload one's own texture. Could that > fix, if it is even in yet, have had this effect? I don't think so, but > perhaps... > > Anyway, if I see this again, should I start a Jira? Or maybe there is one > there already. > > ponzu > > = > > Second Life 2.7.4 (232938) Jun 15 2011 12:44:34 (Second Life Development) > Release Notes > > CPU: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (2400 MHz) > Memory: 3072 MB > OS Version: Mac OS X 10.6.7 Darwin 10.7.0 Darwin Kernel Version 10.7.0: Sat > Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 > Graphics Card Vendor: ATI Technologies Inc. > Graphics Card: ATI Radeon HD 2600 PRO OpenGL Engine > > OpenGL Version: 2.1 ATI-1.6.26 > > libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1 > J2C Decoder Version: KDU v6.4.1 > Audio Driver Version: FMOD version 3.750000 > Qt Webkit Version: 4.7.1 (version number hard-coded) > Voice Server Version: Not Connected > Built with GCC version 40001 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110618/5ac37b07/attachment.htm From oz at lindenlab.com Sun Jun 19 03:49:19 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sun, 19 Jun 2011 06:49:19 -0400 Subject: [opensource-dev] Draw Distance will not be automated Message-ID: <4DFDD42F.3070400@lindenlab.com> This has gotten a bit out of hand... We are absolutely not going to automate draw distance. This got started as a speculative discussion that forked off of the draw distance slider in which I asked whether or not it might be possible to create a system that _if_explicitly_requested_, some smart software could look at what factors in a users configuration might be changed to improve FPS and advise the user on changes that might improve performance. While DD might be one such parameter, the system I asked about would not be an interesting contribution at all if it were the only factor, and I never envisioned a system that would actually change anything automatically - it would inform and educate the user as to what settings changes might be made to improve performance. From oz at lindenlab.com Sun Jun 19 03:55:57 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sun, 19 Jun 2011 06:55:57 -0400 Subject: [opensource-dev] Is it just me? Avatar textures downloading last. In-Reply-To: References: Message-ID: <4DFDD5BD.3090907@lindenlab.com> On 2011-06-18 16:43, Lee ponzu wrote: > Extra symptom. So, there I am, and the avatars are all rendered as > expected, when --blink-- one of them turns gray, like the texture got > lost. No, she didn't change to an all gray skin and outfit. 8-) This is, unfortunately, not new behavior. I've seen it on and off for at least a couple of months but have not been able to pin it down. If we could organize an effort to 1) improve the instrumentation around avatar bakes, and then 2) hunt down the problems and stomp them, it would be a major win. I'd really like it to be true that by the end of 2011 no one in SL needs to have the "what do I look like to you" conversation any more. From carlo at alinoe.com Sun Jun 19 05:07:31 2011 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 19 Jun 2011 14:07:31 +0200 Subject: [opensource-dev] Draw Distance will not be automated In-Reply-To: <4DFDD42F.3070400@lindenlab.com> References: <4DFDD42F.3070400@lindenlab.com> Message-ID: <20110619140731.438527e1@hikaru.localdomain> Draw distance never makes a significant difference for me. Strange actually, cause I think it should... But it's not a very important factor it seems :/ Something that seems to correlate a lot with a low FPS is the number of avatars that have to be rendered. On Sun, 19 Jun 2011 06:49:19 -0400 "Oz Linden (Scott Lawrence)" wrote: > This has gotten a bit out of hand... We are absolutely not going to > automate draw distance. > > This got started as a speculative discussion that forked off of the > draw distance slider in which I asked whether or not it might be > possible to create a system that _if_explicitly_requested_, some > smart software could look at what factors in a users configuration > might be changed to improve FPS and advise the user on changes that > might improve performance. While DD might be one such parameter, > the system I asked about would not be an interesting contribution at > all if it were the only factor, and I never envisioned a system that > would actually change anything automatically - it would inform and > educate the user as to what settings changes might be made to improve > performance. > > > _______________________________________________ > 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 -- Carlo Wood From Lance.Corrimal at eregion.de Sun Jun 19 05:15:57 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 19 Jun 2011 14:15:57 +0200 Subject: [opensource-dev] Draw Distance will not be automated In-Reply-To: <20110619140731.438527e1@hikaru.localdomain> References: <4DFDD42F.3070400@lindenlab.com> <20110619140731.438527e1@hikaru.localdomain> Message-ID: <201106191416.05708.Lance.Corrimal@eregion.de> Am Sonntag, 19. Juni 2011 schrieb Carlo Wood: > Something that seems to correlate a lot with a low FPS > is the number of avatars that have to be rendered. for me a big factor on FPS is the number of textures that the client is still waiting for... the more grey, the more lag. bye, LC From secret.argent at gmail.com Sun Jun 19 16:36:46 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 19 Jun 2011 18:36:46 -0500 Subject: [opensource-dev] DD Philosophy In-Reply-To: <443874.48527.qm@web23903.mail.ird.yahoo.com> References: <443874.48527.qm@web23903.mail.ird.yahoo.com> Message-ID: On 2011-06-17, at 11:41, Hitomi Tiponi wrote: > Please no automatic DD - there are two many variables and differing circumstances for it ever to work. Much better to work on other ways of improving fps e.g. selective updating of avatar movement. Me too. At the very least, make it a non-default option. I adjust DD based on network traffic and rez times more than FPS. Also, that "DD" logo someone suggested... isn't that TM Marvel or whoever owns Daredevil? :) From secret.argent at gmail.com Sun Jun 19 16:41:12 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 19 Jun 2011 18:41:12 -0500 Subject: [opensource-dev] Question about DD philosophy. In-Reply-To: References: Message-ID: <0AE1C612-6BBA-465C-966E-C36CB7DDE919@gmail.com> On 2011-06-18, at 13:00, Robert Martin wrote: > > one thing that i don't understand is why you can be at 4000 meters in > an untextured skybox and still within seconds get GROUND TEXTURES and > other objects on the sim before the contents of the skybox or > attachments on the client avatar (this even happens with a very short > draw distances). https://jira.secondlife.com/browse/SVC-2413? From trilobyte550m at gmail.com Sun Jun 19 23:35:29 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Sun, 19 Jun 2011 23:35:29 -0700 Subject: [opensource-dev] Review viewer -- draw distance slider In-Reply-To: References: Message-ID: <0D6B397D-5719-4B84-9468-E59475585C97@web-pass.com> Sorry for the late response, I've just gotten the chance to test this as well. Looks and works great, seems intuitive. I love the popup notification (as well as the ability to choose not to see it again next time). I also experienced a short delay on the Mac client, though the delay was only a few seconds. TriloByte Zanzibar On Jun 18, 2011, at 6:06 AM, Jonathan Welch wrote: > There is an updated version of the draw distance review viewer here: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-1/rev/233253/index.html > > Changes include slightly better artwork, re-repositioning of the > icon's location, and if you exceed 280m a notification (which you can > suppress) appears alerting you that your performance may suffer. > Notification processing is done after you move your mouse away from > the slider. > > The only other tester than myself (Oz) reported that this notification > appeared minutes after it should have. Why this would be the case is > a mystery to me. If you would like to test this and have this issue > please report it here. > _______________________________________________ > 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 sllists at boroon.dasgupta.ch Mon Jun 20 06:35:20 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 20 Jun 2011 13:35:20 -0000 Subject: [opensource-dev] Review Request: VWR-26066: request LLFloaterWorldMap child "zoom slider" with correct type to get rid of warning when opening map flaoter Message-ID: <20110620133520.19655.66561@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/350/ ----------------------------------------------------------- Review request for Viewer. Summary ------- To reproduce 1. Start the viewer from a terminal, or make the debug console visible after logging in 2. Open the map e.g. by pressing Ctrl-m or by clicking the Map button (can be made visible from the bottom bar context menu) Expected * Map opens * Debug console or terminal displays INFO: openFloater: Opening floater worldmap (and no warning) Observed * Map opens * Debug console or terminal displays INFO: openFloater: Opening floater worldmap WARNING: getChild: Found child named "zoom slider" but of wrong type 12LLSliderCtrl, expecting P8LLSlider This is due to requesting the child control with the wrong type, which this change fixes. This addresses bug VWR-26066. http://jira.secondlife.com/browse/VWR-26066 Diffs ----- doc/contributions.txt 848ad0e546f8 indra/newview/llfloaterworldmap.cpp 848ad0e546f8 Diff: http://codereview.secondlife.com/r/350/diff Testing ------- Merged this fix with e67da2c6e312 and built (linux 64 standalone) * Warning gone * Map still works, no perceptible change in behavior noticed. Not tested: Merging with v-d tip, as I can't build that. (But I know from downloaded test builds that it is affected by this bug.) Thanks, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/d677f423/attachment.htm From vsavchuk at productengine.com Mon Jun 20 06:55:52 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 20 Jun 2011 13:55:52 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() In-Reply-To: <20110616205244.10191.77498@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616205244.10191.77498@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620135552.19651.14926@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/341/ ----------------------------------------------------------- (Updated June 20, 2011, 6:55 a.m.) Review request for Viewer. Changes ------- Changed sort functor return type to bool. Although it was not strictly necessary, because according to http://www.sgi.com/tech/stl/BinaryPredicate.html "The result type must be convertible to bool", and int is. Summary ------- Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. Attempt to sort active toasts in showToastsBottom() then triggered the crash. I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. So we'll just remove references to the toast whenever it's destroyed. This addresses bug STORM-1352. http://jira.secondlife.com/browse/STORM-1352 Diffs (updated) ----- indra/newview/llnearbychathandler.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/341/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/3fb8ef16/attachment.htm From vsavchuk at productengine.com Mon Jun 20 07:22:07 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 20 Jun 2011 14:22:07 -0000 Subject: [opensource-dev] Review Request: VWR-26066: request LLFloaterWorldMap child "zoom slider" with correct type to get rid of warning when opening map flaoter In-Reply-To: <20110620133520.19655.66561@domU-12-31-38-00-90-68.compute-1.internal> References: <20110620133520.19655.66561@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620142207.19649.53190@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/350/#review776 ----------------------------------------------------------- Ship it! - Vadim On June 20, 2011, 6:35 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/350/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 6:35 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > To reproduce > > 1. Start the viewer from a terminal, or make the debug console visible after logging in > 2. Open the map e.g. by pressing Ctrl-m or by clicking the Map button (can be made visible from the bottom bar context menu) > > Expected > > * Map opens > * Debug console or terminal displays > > INFO: openFloater: Opening floater worldmap > > (and no warning) > > Observed > > * Map opens > * Debug console or terminal displays > > INFO: openFloater: Opening floater worldmap > WARNING: getChild: Found child named "zoom slider" but of wrong type 12LLSliderCtrl, expecting P8LLSlider > > > This is due to requesting the child control with the wrong type, which this change fixes. > > > This addresses bug VWR-26066. > http://jira.secondlife.com/browse/VWR-26066 > > > Diffs > ----- > > doc/contributions.txt 848ad0e546f8 > indra/newview/llfloaterworldmap.cpp 848ad0e546f8 > > Diff: http://codereview.secondlife.com/r/350/diff > > > Testing > ------- > > Merged this fix with e67da2c6e312 and built (linux 64 standalone) > * Warning gone > * Map still works, no perceptible change in behavior noticed. > > Not tested: Merging with v-d tip, as I can't build that. (But I know from downloaded test builds that it is affected by this bug.) > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/a2c706db/attachment-0001.htm From vsavchuk at productengine.com Mon Jun 20 09:49:43 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 20 Jun 2011 16:49:43 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110609165620.6514.70030@domU-12-31-38-00-90-68.compute-1.internal> References: <20110609165620.6514.70030@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620164943.19649.96194@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/333/#review778 ----------------------------------------------------------- Seems to work for me, although I'd appreciate if you used a more straightforward (=less error prone) logic. indra/newview/llvoicevivox.cpp Inconsistent spacing around "if" conditions. Please use "if (cond)" with no extra or missing spaces. This also applies to other changes in the patch. indra/newview/llvoicevivox.cpp It's unclear to me why you set voice to enabled here. I think it should be set to enabled only when we're sure the parcel supports it. indra/newview/llvoicevivox.cpp What if region caps never arrive? The string may grow infinitely. Also I don't like using region name as a marked that region caps haven't arrived yet -- that's a hack. indra/newview/llvoicevivox.cpp This could be written shorter: mRegionHasVoice = enabled; - Vadim On June 9, 2011, 9:56 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 9:56 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt a36a329e77cc > indra/newview/llvoicevivox.h a36a329e77cc > indra/newview/llvoicevivox.cpp a36a329e77cc > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/cde4e5ce/attachment.htm From sllists at boroon.dasgupta.ch Mon Jun 20 10:01:18 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 20 Jun 2011 17:01:18 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() In-Reply-To: <20110620135552.19651.14926@domU-12-31-38-00-90-68.compute-1.internal> References: <20110620135552.19651.14926@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620170118.19649.96125@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/341/#review779 ----------------------------------------------------------- You third diff file (STORM-1352_2.diff) seems to be incremental instead of total. Please always use total diffs on RB, so that the full change can be seen and differences between versions of the change can be viewed to compare. indra/newview/llnearbychathandler.cpp On second thought, wouldn't it be good to at least issue a warning here if one of the get()s returns NULL? We might be sorting stuff that isn't there, which is clearly a sign that something's fishy. - Boroondas On June 20, 2011, 6:55 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/341/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 6:55 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. > Attempt to sort active toasts in showToastsBottom() then triggered the crash. > > I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. > So we'll just remove references to the toast whenever it's destroyed. > > > This addresses bug STORM-1352. > http://jira.secondlife.com/browse/STORM-1352 > > > Diffs > ----- > > indra/newview/llnearbychathandler.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/341/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/5567c554/attachment-0001.htm From oz at lindenlab.com Mon Jun 20 10:55:05 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 20 Jun 2011 17:55:05 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() In-Reply-To: <20110616232327.2651.56191@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616232327.2651.56191@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620175505.19652.73095@domU-12-31-38-00-90-68.compute-1.internal> > On June 16, 2011, 4:23 p.m., Boroondas Gupte wrote: > > indra/newview/llnearbychathandler.cpp, lines 375-382 > > > > > > This function's return type should be changed to bool, if it's intended for use with std::sort. (And that's how it's being used currently.) and better yet... there's no excuse in a routine this small for multiple returns. Add a local variable and use the else clause. bool inOrder; if ( .... test ... ) { inOrder = false; } else { ... calc ... inOrder = v1 > v2; } return inOrder; any half way decent optimizer will put that bool in register anyway, so there is no performance difference at all and the code is much clearer and easier to put breakpoints and logging into. - Oz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/341/#review759 ----------------------------------------------------------- On June 20, 2011, 6:55 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/341/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 6:55 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. > Attempt to sort active toasts in showToastsBottom() then triggered the crash. > > I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. > So we'll just remove references to the toast whenever it's destroyed. > > > This addresses bug STORM-1352. > http://jira.secondlife.com/browse/STORM-1352 > > > Diffs > ----- > > indra/newview/llnearbychathandler.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/341/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/539279e1/attachment.htm From sllists at boroon.dasgupta.ch Mon Jun 20 12:44:49 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 20 Jun 2011 19:44:49 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() In-Reply-To: <20110616232327.2651.56191@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616232327.2651.56191@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620194449.24973.3203@domU-12-31-38-00-90-68.compute-1.internal> > On June 16, 2011, 4:23 p.m., Boroondas Gupte wrote: > > indra/newview/llnearbychathandler.cpp, lines 375-382 > > > > > > This function's return type should be changed to bool, if it's intended for use with std::sort. (And that's how it's being used currently.) > > Oz Linden wrote: > and better yet... there's no excuse in a routine this small for multiple returns. > Add a local variable and use the else clause. > > bool inOrder; > if ( .... test ... ) > { > inOrder = false; > } > else > { > ... calc ... > inOrder = v1 > v2; > } > return inOrder; > > any half way decent optimizer will put that bool in register anyway, so there is no performance difference at all and the code is much clearer and easier to put breakpoints and logging into. > I must say I find the version with two returns perfectly readable, maybe specifically because the routine is short. One doesn't easily miss that there are multiple returns, other than one might when looking at a screen-filling routine. Though, if you do it with if-else, maybe handle the usual case before the special case (i.e. test for first.get() && second.get). Also, I'd prefer it the variable to store the return value would be initialized upon definition, which can even save the else-clause: bool inOrder = false; // default return value, in case one or both toasts don't exist if ( .... positive test ... ) { ... calc ... inOrder = v1 > v2; } return inOrder; And while I'm bike-shedding, we could get rid of the multiple get() calls (although those are probably cheap): LLToast* toast_1 = first.get(); LLToast* toast_2 = second.get(); bool inOrder = false; // default return value, in case one or both toasts don't exist if (toast_1 && toast_2) // Toasts might already be gone, see STORM-1352. { inOrder = toast_1->getTimeLeftToLive() > toast_2->getTimeLeftToLive(); } return inOrder; - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/341/#review759 ----------------------------------------------------------- On June 20, 2011, 6:55 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/341/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 6:55 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. > Attempt to sort active toasts in showToastsBottom() then triggered the crash. > > I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. > So we'll just remove references to the toast whenever it's destroyed. > > > This addresses bug STORM-1352. > http://jira.secondlife.com/browse/STORM-1352 > > > Diffs > ----- > > indra/newview/llnearbychathandler.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/341/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/d47c6e8d/attachment.htm From vsavchuk at productengine.com Mon Jun 20 14:19:42 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 20 Jun 2011 21:19:42 -0000 Subject: [opensource-dev] Review Request: Local Bitmap Browser implementation. In-Reply-To: <20110618150447.3681.36306@domU-12-31-38-00-90-68.compute-1.internal> References: <20110618150447.3681.36306@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620211942.20869.21898@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/347/#review780 ----------------------------------------------------------- Briefly tested. Works well and looks like a great feature. But I'm not a fan of the code design: each class knows too much about the others. I started describing specific design flaws but gave up: there are too many of them. Please consider improving encapsulation and adding more comments. Thanks. indra/newview/llfloaterlocalbitmap.h Please move this to the .cpp. indra/newview/llfloaterlocalbitmap.h Move to the .cpp file. indra/newview/llfloaterlocalbitmap.h Consider using enums instead. indra/newview/llfloaterlocalbitmap.h Please drop the "Bool" suffix: a method name should describe what it does, not what type it returns. indra/newview/llfloaterlocalbitmap.h spelling indra/newview/llfloaterlocalbitmap.h Does this class implement a browser? Looks more like some kind of helper/manager class. If so, I'd rename it. indra/newview/llfloaterlocalbitmap.h What is this floater for? Isn't it enough to have the "Local" tab in the texture picker? indra/newview/llfloaterlocalbitmap.h Inconsistent indentation. Use tabs everywhere in C++ code. indra/newview/llfloaterlocalbitmap.h A better description would not hurt. indra/newview/llfloaterlocalbitmap.cpp Using LLSingleton would be safer. indra/newview/llfloaterlocalbitmap.cpp No need to to use this for accessing members: this is why they have a distinctive naming style. indra/newview/llfloaterlocalbitmap.cpp Inconsistent spaces here and there. Please use the following style: "if (cond)". This is how most of our code is written. indra/newview/llfloaterlocalbitmap.cpp Am I right assuming that viewer_texture manages life time of raw_image? indra/newview/llfloaterlocalbitmap.cpp delete raw_image if decoding fails? indra/newview/llfloaterlocalbitmap.cpp Please follow the coding standard: http://wiki.secondlife.com/wiki/Coding_standard#Braces indra/newview/llfloaterlocalbitmap.cpp Memory leak? Shouldn't we delete the "unit" if it's not valid? indra/newview/llfloaterlocalbitmap.cpp 1. Any reason not to pass vector by reference? 2. Why should LLLocalBitmapBrowser know about some external scroll lists and their columns? I think it should just be passed a list of image IDs. indra/newview/llfloaterlocalbitmap.cpp I think this check should be moved to LLLocalBitmapBrowserTimer::start() for better encapsulation. indra/newview/llfloaterlocalbitmap.cpp same here indra/newview/llfloaterlocalbitmap.cpp Looks like this code was written a long time ago. We now avoid using void* in favor of boost::bind(). indra/newview/llfloaterlocalbitmap.cpp same here and below indra/newview/llfloaterlocalbitmap.cpp This naming style is reserved for static members. indra/newview/llfloaterlocalbitmap.cpp same here indra/newview/lltexturectrl.cpp You can just omit the second argument or pass LLSD(). NULL leads to gcc compilation error. indra/newview/lltexturectrl.cpp Looks like too much copy&paste. Please try reusing this code in both overridden methods. indra/newview/skins/default/xui/en/floater_texture_ctrl.xml Mixed tabs and spaces (here and below). - Vadim On June 18, 2011, 8:04 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/347/ > ----------------------------------------------------------- > > (Updated June 18, 2011, 8:04 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Local Bitmap Browser is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects build menu by adding a way to open the floater there. > This change also affects the texture picker - adding tabs that lets the user choose between the "Server" (regular inventory) and "Local" tabs (list of locally added files). > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 6a3e7e403bd1 > indra/llmath/llvolumemgr.h 6a3e7e403bd1 > indra/llmath/llvolumemgr.cpp 6a3e7e403bd1 > indra/newview/CMakeLists.txt 6a3e7e403bd1 > indra/newview/llfloaterlocalbitmap.h PRE-CREATION > indra/newview/llfloaterlocalbitmap.cpp PRE-CREATION > indra/newview/lltexturectrl.h 6a3e7e403bd1 > indra/newview/lltexturectrl.cpp 6a3e7e403bd1 > indra/newview/llviewerfloaterreg.cpp 6a3e7e403bd1 > indra/newview/llviewerobjectlist.h 6a3e7e403bd1 > indra/newview/llviewertexturelist.h 6a3e7e403bd1 > indra/newview/llvovolume.h 6a3e7e403bd1 > indra/newview/skins/default/xui/en/floater_local_bitmap.xml PRE-CREATION > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 6a3e7e403bd1 > indra/newview/skins/default/xui/en/menu_viewer.xml 6a3e7e403bd1 > > Diff: http://codereview.secondlife.com/r/347/diff > > > Testing > ------- > > Texture/Sculptmap/Avatar Layer show. > Texture/Sculptmap/Avatar Layer update. > Multiple sculpties update. > Opening multiple browser floaters works correctly. (two possible since one can be opened from menu above, one from texture picker. all of them + texture picker play nice.) > Tested adding over 200 images at the same time. > > > Thanks, > > Vaalith > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/f2458166/attachment-0001.htm From lee.ponzu at gmail.com Mon Jun 20 14:20:55 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Mon, 20 Jun 2011 17:20:55 -0400 Subject: [opensource-dev] Is it just me? Avatar textures downloading last. In-Reply-To: <4DFDD5BD.3090907@lindenlab.com> References: <4DFDD5BD.3090907@lindenlab.com> Message-ID: If I can help gather any data let me know. On Sun, Jun 19, 2011 at 6:55 AM, Oz Linden (Scott Lawrence) < oz at lindenlab.com> wrote: > On 2011-06-18 16:43, Lee ponzu wrote: > > Extra symptom. So, there I am, and the avatars are all rendered as > > expected, when --blink-- one of them turns gray, like the texture got > > lost. No, she didn't change to an all gray skin and outfit. 8-) > > This is, unfortunately, not new behavior. I've seen it on and off for > at least a couple of months but have not been able to pin it down. > > If we could organize an effort to 1) improve the instrumentation around > avatar bakes, and then 2) hunt down the problems and stomp them, it > would be a major win. > > I'd really like it to be true that by the end of 2011 no one in SL needs > to have the "what do I look like to you" conversation any more. > > > _______________________________________________ > 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/20110620/0113fb97/attachment.htm From vsavchuk at productengine.com Mon Jun 20 14:22:16 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 20 Jun 2011 21:22:16 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() In-Reply-To: <20110620170118.19649.96125@domU-12-31-38-00-90-68.compute-1.internal> References: <20110620170118.19649.96125@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620212216.24972.33590@domU-12-31-38-00-90-68.compute-1.internal> > On June 20, 2011, 10:01 a.m., Boroondas Gupte wrote: > > You third diff file (STORM-1352_2.diff) seems to be incremental instead of total. Please always use total diffs on RB, so that the full change can be seen and differences between versions of the change can be viewed to compare. Ok. > On June 20, 2011, 10:01 a.m., Boroondas Gupte wrote: > > indra/newview/llnearbychathandler.cpp, lines 375-382 > > > > > > On second thought, wouldn't it be good to at least issue a warning here if one of the get()s returns NULL? We might be sorting stuff that isn't there, which is clearly a sign that something's fishy. Right, I'll add a warning. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/341/#review779 ----------------------------------------------------------- On June 20, 2011, 6:55 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/341/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 6:55 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. > Attempt to sort active toasts in showToastsBottom() then triggered the crash. > > I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. > So we'll just remove references to the toast whenever it's destroyed. > > > This addresses bug STORM-1352. > http://jira.secondlife.com/browse/STORM-1352 > > > Diffs > ----- > > indra/newview/llnearbychathandler.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/341/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/b02f2f8f/attachment.htm From vsavchuk at productengine.com Mon Jun 20 14:24:22 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 20 Jun 2011 21:24:22 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() In-Reply-To: <20110616232327.2651.56191@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616232327.2651.56191@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620212422.24113.56116@domU-12-31-38-00-90-68.compute-1.internal> > On June 16, 2011, 4:23 p.m., Boroondas Gupte wrote: > > indra/newview/llnearbychathandler.cpp, lines 375-382 > > > > > > This function's return type should be changed to bool, if it's intended for use with std::sort. (And that's how it's being used currently.) > > Oz Linden wrote: > and better yet... there's no excuse in a routine this small for multiple returns. > Add a local variable and use the else clause. > > bool inOrder; > if ( .... test ... ) > { > inOrder = false; > } > else > { > ... calc ... > inOrder = v1 > v2; > } > return inOrder; > > any half way decent optimizer will put that bool in register anyway, so there is no performance difference at all and the code is much clearer and easier to put breakpoints and logging into. > > > Boroondas Gupte wrote: > I must say I find the version with two returns perfectly readable, maybe specifically because the routine is short. One doesn't easily miss that there are multiple returns, other than one might when looking at a screen-filling routine. > > Though, if you do it with if-else, maybe handle the usual case before the special case (i.e. test for first.get() && second.get). Also, I'd prefer it the variable to store the return value would be initialized upon definition, which can even save the else-clause: > > bool inOrder = false; // default return value, in case one or both toasts don't exist > > if ( .... positive test ... ) > { > ... calc ... > inOrder = v1 > v2; > } > > return inOrder; > > And while I'm bike-shedding, we could get rid of the multiple get() calls (although those are probably cheap): > > LLToast* toast_1 = first.get(); > LLToast* toast_2 = second.get(); > > bool inOrder = false; // default return value, in case one or both toasts don't exist > > if (toast_1 && toast_2) // Toasts might already be gone, see STORM-1352. > { > inOrder = toast_1->getTimeLeftToLive() > toast_2->getTimeLeftToLive(); > } > > return inOrder; Oz, I'm not a fan of the endless-indentation-single-return style, especially when it comes to a simple case of handling illegal arguments. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/341/#review759 ----------------------------------------------------------- On June 20, 2011, 6:55 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/341/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 6:55 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. > Attempt to sort active toasts in showToastsBottom() then triggered the crash. > > I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. > So we'll just remove references to the toast whenever it's destroyed. > > > This addresses bug STORM-1352. > http://jira.secondlife.com/browse/STORM-1352 > > > Diffs > ----- > > indra/newview/llnearbychathandler.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/341/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/b0317042/attachment-0001.htm From vsavchuk at productengine.com Mon Jun 20 14:36:39 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 20 Jun 2011 21:36:39 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() In-Reply-To: <20110616232327.2651.56191@domU-12-31-38-00-90-68.compute-1.internal> References: <20110616232327.2651.56191@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620213639.19648.59862@domU-12-31-38-00-90-68.compute-1.internal> > On June 16, 2011, 4:23 p.m., Boroondas Gupte wrote: > > indra/newview/llnearbychathandler.cpp, lines 375-382 > > > > > > This function's return type should be changed to bool, if it's intended for use with std::sort. (And that's how it's being used currently.) > > Oz Linden wrote: > and better yet... there's no excuse in a routine this small for multiple returns. > Add a local variable and use the else clause. > > bool inOrder; > if ( .... test ... ) > { > inOrder = false; > } > else > { > ... calc ... > inOrder = v1 > v2; > } > return inOrder; > > any half way decent optimizer will put that bool in register anyway, so there is no performance difference at all and the code is much clearer and easier to put breakpoints and logging into. > > > Boroondas Gupte wrote: > I must say I find the version with two returns perfectly readable, maybe specifically because the routine is short. One doesn't easily miss that there are multiple returns, other than one might when looking at a screen-filling routine. > > Though, if you do it with if-else, maybe handle the usual case before the special case (i.e. test for first.get() && second.get). Also, I'd prefer it the variable to store the return value would be initialized upon definition, which can even save the else-clause: > > bool inOrder = false; // default return value, in case one or both toasts don't exist > > if ( .... positive test ... ) > { > ... calc ... > inOrder = v1 > v2; > } > > return inOrder; > > And while I'm bike-shedding, we could get rid of the multiple get() calls (although those are probably cheap): > > LLToast* toast_1 = first.get(); > LLToast* toast_2 = second.get(); > > bool inOrder = false; // default return value, in case one or both toasts don't exist > > if (toast_1 && toast_2) // Toasts might already be gone, see STORM-1352. > { > inOrder = toast_1->getTimeLeftToLive() > toast_2->getTimeLeftToLive(); > } > > return inOrder; > > Vadim ProductEngine wrote: > Oz, I'm not a fan of the endless-indentation-single-return style, especially when it comes to a simple case of handling illegal arguments. Boroondas, as far as I remember, there cannot be many active toasts, so no need to write more code here to save a microsecond. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/341/#review759 ----------------------------------------------------------- On June 20, 2011, 6:55 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/341/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 6:55 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. > Attempt to sort active toasts in showToastsBottom() then triggered the crash. > > I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. > So we'll just remove references to the toast whenever it's destroyed. > > > This addresses bug STORM-1352. > http://jira.secondlife.com/browse/STORM-1352 > > > Diffs > ----- > > indra/newview/llnearbychathandler.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/341/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/90f20359/attachment.htm From vsavchuk at productengine.com Mon Jun 20 15:29:18 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 20 Jun 2011 22:29:18 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() In-Reply-To: <20110620135552.19651.14926@domU-12-31-38-00-90-68.compute-1.internal> References: <20110620135552.19651.14926@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620222918.24974.80199@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/341/ ----------------------------------------------------------- (Updated June 20, 2011, 3:29 p.m.) Review request for Viewer. Changes ------- Issue a warning if a NULL chat toast is encountered. I'm not doing that in the sort functor to make sure we print only one warning per invalid item. Summary ------- Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. Attempt to sort active toasts in showToastsBottom() then triggered the crash. I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. So we'll just remove references to the toast whenever it's destroyed. This addresses bug STORM-1352. http://jira.secondlife.com/browse/STORM-1352 Diffs (updated) ----- indra/newview/llnearbychathandler.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/341/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/6b148eba/attachment.htm From sllists at boroon.dasgupta.ch Mon Jun 20 15:41:54 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 20 Jun 2011 22:41:54 -0000 Subject: [opensource-dev] Review Request: STORM-1352 Crash in LLNearbyChatScreenChannel::showToastsBottom() In-Reply-To: <20110620222918.24974.80199@domU-12-31-38-00-90-68.compute-1.internal> References: <20110620222918.24974.80199@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620224154.24977.58643@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/341/#review786 ----------------------------------------------------------- Ship it! - Boroondas On June 20, 2011, 3:29 p.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/341/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 3:29 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Apparently, a nearby chat toast got somehow destroyed while still remaining in the list of active toasts. > Attempt to sort active toasts in showToastsBottom() then triggered the crash. > > I don't know how to reproduce the crash, i.e. force destroying a toast in a way that its onClose() method (which would remove references to the toast) isn't called. > So we'll just remove references to the toast whenever it's destroyed. > > > This addresses bug STORM-1352. > http://jira.secondlife.com/browse/STORM-1352 > > > Diffs > ----- > > indra/newview/llnearbychathandler.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/341/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/ae86d3a7/attachment-0001.htm From vsavchuk at productengine.com Mon Jun 20 15:46:50 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 20 Jun 2011 22:46:50 -0000 Subject: [opensource-dev] Review Request: Enable watchdog timer for Beta crash hunting. In-Reply-To: <20110614215015.4024.95308@domU-12-31-38-00-90-68.compute-1.internal> References: <20110614215015.4024.95308@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110620224650.20870.67662@domU-12-31-38-00-90-68.compute-1.internal> > On June 14, 2011, 2:50 p.m., Alain Linden wrote: > > indra/newview/app_settings/settings.xml, line 12409 > > > > > > I presume this means trigger the watchdog after 20 seconds of 'freeze'. > > Jenn wrote: > :) yes Has this patch been submitted? If so, please close the review request. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/337/#review743 ----------------------------------------------------------- On June 14, 2011, 2:50 p.m., Jenn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/337/ > ----------------------------------------------------------- > > (Updated June 14, 2011, 2:50 p.m.) > > > Review request for Viewer, Alain Linden, Richard Nelson, and Nat Goodspeed. > > > Summary > ------- > > Enable watchdog timer for Beta release to get tracebacks for classes of crashes for which we currently have little data. > > Setting timer to 20 seconds. Will either disable or make longer for deployment to the Release channel. > > > Diffs > ----- > > indra/newview/app_settings/settings.xml a7c507c7e0f8 > > Diff: http://codereview.secondlife.com/r/337/diff > > > Testing > ------- > > > Thanks, > > Jenn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/5463f41d/attachment.htm From sllists at boroon.dasgupta.ch Mon Jun 20 16:24:12 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 20 Jun 2011 23:24:12 -0000 Subject: [opensource-dev] Review Request: OPEN-99: use -march=pentium3 and -march=pentium4 only for 32 bit builds Message-ID: <20110620232412.24977.44841@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/351/ ----------------------------------------------------------- Review request for Viewer. Summary ------- These flags prevent building for 64-bit (both standalone or non-standalone), so only use them for 32-bit builds. This addresses bug OPEN-99. http://jira.secondlife.com/browse/OPEN-99 Diffs ----- doc/contributions.txt e8f2a53c3d6e indra/cmake/00-Common.cmake e8f2a53c3d6e Diff: http://codereview.secondlife.com/r/351/diff Testing ------- Tried a non-standalone 64-bit build (without using 64-bit prebuilts, though): Fails with [ 11%] Building CXX object llcommon/CMakeFiles/llcommon.dir/u64.o Linking CXX shared library libllcommon.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible ${SRC_DIR}/build-linux-i686/packages/lib/release/libbreakpad_client.so when searching for -lbreakpad_client /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible ${SRC_DIR}/build-linux-i686/packages/lib/release/libaprutil-1.so when searching for -laprutil-1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible ${SRC_DIR}/build-linux-i686/packages/lib/release/libaprutil-1.a when searching for -laprutil-1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible ${SRC_DIR}/build-linux-i686/packages/lib/release/libdb-5.1.so when searching for -ldb-5.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -ldb-5.1 collect2: ld returned 1 exit status make[2]: *** [llcommon/libllcommon.so] Error 1 make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2 make: *** [all] Error 2 ERROR: building default configuration returned 2 For more information: try re-running your command with --verbose or --debug Tried a standalone 64-bit build (after merging OPEN-38 changes): Fails with [ 13%] Building CXX object llcharacter/CMakeFiles/llcharacter.dir/llvisualparam.o Linking CXX static library libllcharacter.a [ 13%] Built target llcharacter Scanning dependencies of target INTEGRATION_TEST_bitpack [ 13%] Building CXX object llcommon/CMakeFiles/INTEGRATION_TEST_bitpack.dir/tests/bitpack_test.o c++: CMakeFiles/INTEGRATION_TEST_bitpack.dir/tests/bitpack_test.o: No such file or directory make[2]: *** [llcommon/CMakeFiles/INTEGRATION_TEST_bitpack.dir/tests/bitpack_test.o] Error 1 make[1]: *** [llcommon/CMakeFiles/INTEGRATION_TEST_bitpack.dir/all] Error 2 make: *** [all] Error 2 ERROR: building default configuration returned 2 For more information: try re-running your command with --verbose or --debug (Both errors occur much later in the build process than the one that'd occur without this change.) Tried a non-standalone 32-bit build: Fails on https://jira.secondlife.com/browse/OPEN-23 , just as without this change. Thanks, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110620/4c855d3f/attachment.htm From monty at lindenlab.com Mon Jun 20 16:46:02 2011 From: monty at lindenlab.com (Monty Brandenberg) Date: Mon, 20 Jun 2011 19:46:02 -0400 Subject: [opensource-dev] Is it just me? Avatar textures downloading last. In-Reply-To: References: <4DFDD5BD.3090907@lindenlab.com> Message-ID: <4DFFDBBA.7090201@lindenlab.com> On 6/20/2011 5:20 PM, Lee ponzu wrote: > If I can help gather any data let me know. Jira + description of events with timeline + logfile From thickbrick.sleaford at gmail.com Mon Jun 20 17:03:57 2011 From: thickbrick.sleaford at gmail.com (Thickbrick Sleaford) Date: Tue, 21 Jun 2011 03:03:57 +0300 Subject: [opensource-dev] Is it just me? Avatar textures downloading last. In-Reply-To: References: Message-ID: <201106210303.58294.thickbrick.sleaford@gmail.com> On Saturday 18 June 2011 20:00:04 Lee ponzu wrote: > However, and unrelated to shadows, I began to notice last night that while > my scenes had all downloaded, the avatars around me were still all gray. > Their objects were OK, it was just their skin and cloth final bake that is > missing. They do show up after several minutes, but long after everything > else. > I've noticed avatar bakes taking very long to un-gray too, when trying the SL v2 viewer recently after not using it for a long-ish while. This is especially noticeable in crowded areas. Looking at the texture console, it looks like any fetch that is using udp (i.e. bakes, since they can not be fetched via http) is always at the bottom of the list, and usually gets bumped out quickly. I haven't tested this, but I get the feeling that the udp fetches are starved out of processing by the regular http fetches. If I stay a while in a gray people gathering, and then relog, the once-gray people have at least one discard level of their bakes quickly decoded, probably from cache. This makes me think that this is a prioritization issue, possibly caused by the quick turn-around of http textures. -- Thickbrick From squire at lindenlab.com Mon Jun 20 20:21:20 2011 From: squire at lindenlab.com (Squire Linden) Date: Tue, 21 Jun 2011 03:21:20 -0000 Subject: [opensource-dev] Review Request: Changes to fix CHOP-662. Message-ID: <20110621032120.19649.47155@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/357/ ----------------------------------------------------------- Review request for Viewer, Oz Linden, Seth ProductEngine, and Alain Linden. Summary ------- Changes to fix CHOP-662. CHOP-662 was caused by the recent addition of lldiriterator.cpp which is used to iterate over directories. It takes a mask in the form of a glob string to use as a pattern for which files to iterate over. Unfortunately, as originally implemented, it converted the glob to a regex pattern without escaping any legal glob characters which are illegal regex characters. As a result if the passed in mask was an illegal regex it would fail and llerrs would cause a crash. In CHOP-662 this happens whenever a group name has, e.g. a '+' character at the beginning. When logging in the viewer would attempt to load the group chat log file which would result in a glob starting with a '+' character and in turn to an illegal regex in lldiriterator. Also, the chat code was doing nothing to ensure that illegal glob characters were not being passed to the lldiriterator constructor. This addresses bug CHOP-662. http://jira.secondlife.com/browse/CHOP-662 Diffs ----- doc/contributions.txt e8f2a53c3d6e indra/llvfs/CMakeLists.txt e8f2a53c3d6e indra/llvfs/lldiriterator.cpp e8f2a53c3d6e indra/llvfs/tests/lldiriterator_test.cpp PRE-CREATION indra/newview/lllogchat.cpp e8f2a53c3d6e Diff: http://codereview.secondlife.com/r/357/diff Testing ------- Added a unit test for lldiriterator which checks for construction failures on examples of the most common group names which were causing the crashes. Thanks, Squire -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/578005de/attachment-0001.htm From sllists at boroon.dasgupta.ch Tue Jun 21 01:43:52 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 21 Jun 2011 08:43:52 -0000 Subject: [opensource-dev] Review Request: Changes to fix CHOP-662. In-Reply-To: <20110621032120.19649.47155@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621032120.19649.47155@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621084352.24972.94522@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/357/#review788 ----------------------------------------------------------- doc/contributions.txt Please indent issue keys in this file with a single tab, rather than four spaces. doc/contributions.txt Current and past practice is that only volunteers are listed in doc/contributions.txt, not LL employees or contractors (like PE employees). I'm not against changing that practice (or getting rid of the file altogether, now that changeset committers better reflect the change authors), but this should probably be discussed first. indra/llvfs/lldiriterator.cpp The glob_to_regex funcion looks like it might be useful outside the context of LLDirIterator or even file systems, so maybe it should reside in a source file of its own, or together with other string manipulation stuff. indra/llvfs/lldiriterator.cpp +1 for documentation. Bonus points if you turn this into doxygen. Further, start the first sentence with a capital letter and end the last with a period. indra/llvfs/lldiriterator.cpp Not related to your change, but I'd find '* 2' more readable than a left-shift. A decent compiler should produce the same code from both, so for performance, it should not matter. indra/llvfs/lldiriterator.cpp The second comment line here doesn't start a new sentence, thus should start with a lower case letter. Both lines together are a sentence, so end the second line with a period. indra/llvfs/lldiriterator.cpp Indent the regex+= line with 4 tabs and the default line with 3 tabs, to be consistent with surrounding lines. indra/llvfs/lldiriterator.cpp Consider surrounding the += operator by a space on each side. (Also in occurrences above.) indra/newview/lllogchat.cpp Not introduced by your change, but getting more apparent as more characters get converted to '_': Is it intended that this can lead to filename 'collisions'? I just tried on Aditi and founded groups *Boroondas* and >Boroondas<, and indeed, chat in both gets logged to the same file. - Boroondas On June 20, 2011, 8:21 p.m., Squire Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/357/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 8:21 p.m.) > > > Review request for Viewer, Oz Linden, Seth ProductEngine, and Alain Linden. > > > Summary > ------- > > Changes to fix CHOP-662. CHOP-662 was caused by the recent addition of lldiriterator.cpp which is used to iterate over directories. It takes a mask in the form of a glob string to use as a pattern for which files to iterate over. > > Unfortunately, as originally implemented, it converted the glob to a regex pattern without escaping any legal glob characters which are illegal regex characters. As a result if the passed in mask was an illegal regex it would fail and llerrs would cause a crash. > > In CHOP-662 this happens whenever a group name has, e.g. a '+' character at the beginning. When logging in the viewer would attempt to load the group chat log file which would result in a glob starting with a '+' character and in turn to an illegal regex in lldiriterator. > > Also, the chat code was doing nothing to ensure that illegal glob characters were not being passed to the lldiriterator constructor. > > > This addresses bug CHOP-662. > http://jira.secondlife.com/browse/CHOP-662 > > > Diffs > ----- > > doc/contributions.txt e8f2a53c3d6e > indra/llvfs/CMakeLists.txt e8f2a53c3d6e > indra/llvfs/lldiriterator.cpp e8f2a53c3d6e > indra/llvfs/tests/lldiriterator_test.cpp PRE-CREATION > indra/newview/lllogchat.cpp e8f2a53c3d6e > > Diff: http://codereview.secondlife.com/r/357/diff > > > Testing > ------- > > Added a unit test for lldiriterator which checks for construction failures on examples of the most common group names which were causing the crashes. > > > Thanks, > > Squire > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/eeece539/attachment-0001.htm From armin.weatherwax at googlemail.com Tue Jun 21 02:52:27 2011 From: armin.weatherwax at googlemail.com (ArminWeatherHax Resident) Date: Tue, 21 Jun 2011 09:52:27 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110609204814.6077.92537@domU-12-31-38-00-90-68.compute-1.internal> References: <20110609204814.6077.92537@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621095227.20869.2256@domU-12-31-38-00-90-68.compute-1.internal> > On June 9, 2011, 1:48 p.m., Altair Memo wrote: > > indra/newview/llvoicevivox.cpp, line 785 > > > > > > not sure is a nice choice remove the warn, a resident lose the only way to know if all work fine I'll add a comment and rename mRegionHasVoice to mRegionHasVoiceCap to be more clear, and add a warning when the cap response arrived with empty ParcelVoiceInfoRequest. - ArminWeatherHax ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/333/#review738 ----------------------------------------------------------- On June 9, 2011, 9:56 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 9:56 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt a36a329e77cc > indra/newview/llvoicevivox.h a36a329e77cc > indra/newview/llvoicevivox.cpp a36a329e77cc > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/ac68e99d/attachment.htm From armin.weatherwax at googlemail.com Tue Jun 21 02:52:37 2011 From: armin.weatherwax at googlemail.com (ArminWeatherHax Resident) Date: Tue, 21 Jun 2011 09:52:37 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110620164943.19649.96194@domU-12-31-38-00-90-68.compute-1.internal> References: <20110620164943.19649.96194@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621095237.19654.3974@domU-12-31-38-00-90-68.compute-1.internal> > On June 20, 2011, 9:49 a.m., Vadim ProductEngine wrote: > > indra/newview/llvoicevivox.cpp, lines 4485-4488 > > > > > > What if region caps never arrive? > > The string may grow infinitely. > > > > Also I don't like using region name as a marked that region caps haven't arrived yet -- that's a hack. The state engine resets the string if it was changed, but you are right, it's not nice. I'll go for adding LLVivoxVoiceClient::parcelChanged() to LLViewerParcelMgr::addAgentParcelChangedCallback which will make the whole patch more straightforward. - ArminWeatherHax ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/333/#review778 ----------------------------------------------------------- On June 9, 2011, 9:56 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 9:56 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt a36a329e77cc > indra/newview/llvoicevivox.h a36a329e77cc > indra/newview/llvoicevivox.cpp a36a329e77cc > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/5a0626d1/attachment.htm From sllists at boroon.dasgupta.ch Tue Jun 21 03:14:31 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 21 Jun 2011 10:14:31 -0000 Subject: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer) In-Reply-To: <20110525215518.20621.90962@domU-12-31-38-00-90-68.compute-1.internal> References: <20110525215518.20621.90962@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621101431.19653.30718@domU-12-31-38-00-90-68.compute-1.internal> > On May 25, 2011, 2:55 p.m., Altair Memo wrote: > > work fine with both 1.45 from 3p-libs both custom 1.46 prebuilt libs (non-standalone) Have you actually reviewed the code change or just tested the result? - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/313/#review714 ----------------------------------------------------------- On May 25, 2011, 1:25 p.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/313/ > ----------------------------------------------------------- > > (Updated May 25, 2011, 1:25 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Context: We are currently using Boost 1.45, which already comes with the new Boost Filesystem Library API (Version 3) but still defaults to the old one (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will be the last one to come with V2. The Boost Filesystem Library documentation recommends "Existing code should be moved to Version 3 as soon as convenient. New code should be written for Version 3. Version 2 is deprecated, and will not be included in Boost releases 1.48 and later." > > This change overrides the default, so that the V3 API is used, and makes the necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever we feel like it.) > > Note: I only changed stuff that the compiler complained about. If the new API also changes semantic of still-compiling library usage, more changes might be necessary. > > > This addresses bug OPEN-67. > http://jira.secondlife.com/browse/OPEN-67 > > > Diffs > ----- > > doc/contributions.txt 959f9340da92 > indra/llvfs/lldiriterator.cpp 959f9340da92 > > Diff: http://codereview.secondlife.com/r/313/diff > > > Testing > ------- > > * Compiled Viewer (standalone) with Boost 1.45 > * Started Viewer > * Logged in > > * Compiled Viewer (standalone) with Boost 1.46 > * Started Viewer > * Logged in > > Not tested: > * non-standalone > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/9029e13b/attachment-0001.htm From sythos at gmail.com Tue Jun 21 03:31:19 2011 From: sythos at gmail.com (Francesco "Sythos") Date: Tue, 21 Jun 2011 12:31:19 +0200 Subject: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer) In-Reply-To: <20110621101431.19653.30718@domU-12-31-38-00-90-68.compute-1.internal> References: <20110525215518.20621.90962@domU-12-31-38-00-90-68.compute-1.internal> <20110621101431.19653.30718@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <265373161897189337@unknownmsgid> Well... I'm sorry but for me is quite hard remember what i've done yesterday... Got focus about what i've done 1 month ago is impissible... If i recall correctly i've already used this patch in KV, i can check deeper asap @ home this evening -- Sent by iPhone Il giorno 21/giu/2011, alle ore 12:14, "Boroondas Gupte" < sllists at boroon.dasgupta.ch> ha scritto: This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/313/ On May 25th, 2011, 2:55 p.m., *Altair Memo* wrote: work fine with both 1.45 from 3p-libs both custom 1.46 prebuilt libs (non-standalone) Have you actually reviewed the code change or just tested the result? - Boroondas On May 25th, 2011, 1:25 p.m., Boroondas Gupte wrote: Review request for Viewer. By Boroondas Gupte. *Updated May 25, 2011, 1:25 p.m.* Description Context: We are currently using Boost 1.45, which already comes with the new Boost Filesystem Library API (Version 3) but still defaults to the old one (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will be the last one to come with V2. The Boost Filesystem Library documentation recommends "Existing code should be moved to Version 3 as soon as convenient. New code should be written for Version 3. Version 2 is deprecated, and will not be included in Boost releases 1.48 and later." This change overrides the default, so that the V3 API is used, and makes the necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever we feel like it.) Note: I only changed stuff that the compiler complained about. If the new API also changes semantic of still-compiling library usage, more changes might be necessary. Testing * Compiled Viewer (standalone) with Boost 1.45 * Started Viewer * Logged in * Compiled Viewer (standalone) with Boost 1.46 * Started Viewer * Logged in Not tested: * non-standalone *Bugs: * OPEN-67 Diffs - doc/contributions.txt (959f9340da92) - indra/llvfs/lldiriterator.cpp (959f9340da92) View Diff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/08d2f975/attachment.htm From vsavchuk at productengine.com Tue Jun 21 06:23:56 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 21 Jun 2011 13:23:56 -0000 Subject: [opensource-dev] Review Request: Local Bitmap Browser implementation. In-Reply-To: <20110620211942.20869.21898@domU-12-31-38-00-90-68.compute-1.internal> References: <20110620211942.20869.21898@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621132356.19654.61386@domU-12-31-38-00-90-68.compute-1.internal> > On June 20, 2011, 2:19 p.m., Vadim ProductEngine wrote: > > indra/newview/llfloaterlocalbitmap.h, lines 79-80 > > > > > > Consider using enums instead. Or rather typed constants. > On June 20, 2011, 2:19 p.m., Vadim ProductEngine wrote: > > indra/newview/llfloaterlocalbitmap.cpp, line 90 > > > > > > No need to to use this for accessing members: this is why they have a distinctive naming style. I meant no need to use "this". - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/347/#review780 ----------------------------------------------------------- On June 18, 2011, 8:04 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/347/ > ----------------------------------------------------------- > > (Updated June 18, 2011, 8:04 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Local Bitmap Browser is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects build menu by adding a way to open the floater there. > This change also affects the texture picker - adding tabs that lets the user choose between the "Server" (regular inventory) and "Local" tabs (list of locally added files). > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 6a3e7e403bd1 > indra/llmath/llvolumemgr.h 6a3e7e403bd1 > indra/llmath/llvolumemgr.cpp 6a3e7e403bd1 > indra/newview/CMakeLists.txt 6a3e7e403bd1 > indra/newview/llfloaterlocalbitmap.h PRE-CREATION > indra/newview/llfloaterlocalbitmap.cpp PRE-CREATION > indra/newview/lltexturectrl.h 6a3e7e403bd1 > indra/newview/lltexturectrl.cpp 6a3e7e403bd1 > indra/newview/llviewerfloaterreg.cpp 6a3e7e403bd1 > indra/newview/llviewerobjectlist.h 6a3e7e403bd1 > indra/newview/llviewertexturelist.h 6a3e7e403bd1 > indra/newview/llvovolume.h 6a3e7e403bd1 > indra/newview/skins/default/xui/en/floater_local_bitmap.xml PRE-CREATION > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 6a3e7e403bd1 > indra/newview/skins/default/xui/en/menu_viewer.xml 6a3e7e403bd1 > > Diff: http://codereview.secondlife.com/r/347/diff > > > Testing > ------- > > Texture/Sculptmap/Avatar Layer show. > Texture/Sculptmap/Avatar Layer update. > Multiple sculpties update. > Opening multiple browser floaters works correctly. (two possible since one can be opened from menu above, one from texture picker. all of them + texture picker play nice.) > Tested adding over 200 images at the same time. > > > Thanks, > > Vaalith > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/ffec6d25/attachment.htm From Aleric.Inglewood at gmail.com Tue Jun 21 06:56:06 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Tue, 21 Jun 2011 13:56:06 -0000 Subject: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer) In-Reply-To: <20110525202505.20619.33404@domU-12-31-38-00-90-68.compute-1.internal> References: <20110525202505.20619.33404@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621135606.20869.5001@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/313/#review793 ----------------------------------------------------------- indra/llvfs/lldiriterator.cpp What is your reasoning to use native() here and not string()? - Aleric On May 25, 2011, 1:25 p.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/313/ > ----------------------------------------------------------- > > (Updated May 25, 2011, 1:25 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Context: We are currently using Boost 1.45, which already comes with the new Boost Filesystem Library API (Version 3) but still defaults to the old one (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will be the last one to come with V2. The Boost Filesystem Library documentation recommends "Existing code should be moved to Version 3 as soon as convenient. New code should be written for Version 3. Version 2 is deprecated, and will not be included in Boost releases 1.48 and later." > > This change overrides the default, so that the V3 API is used, and makes the necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever we feel like it.) > > Note: I only changed stuff that the compiler complained about. If the new API also changes semantic of still-compiling library usage, more changes might be necessary. > > > This addresses bug OPEN-67. > http://jira.secondlife.com/browse/OPEN-67 > > > Diffs > ----- > > doc/contributions.txt 959f9340da92 > indra/llvfs/lldiriterator.cpp 959f9340da92 > > Diff: http://codereview.secondlife.com/r/313/diff > > > Testing > ------- > > * Compiled Viewer (standalone) with Boost 1.45 > * Started Viewer > * Logged in > > * Compiled Viewer (standalone) with Boost 1.46 > * Started Viewer > * Logged in > > Not tested: > * non-standalone > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/86e29545/attachment-0001.htm From sllists at boroon.dasgupta.ch Tue Jun 21 07:19:35 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 21 Jun 2011 14:19:35 -0000 Subject: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer) In-Reply-To: <20110621135606.20869.5001@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621135606.20869.5001@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621141935.19655.91966@domU-12-31-38-00-90-68.compute-1.internal> > On June 21, 2011, 6:56 a.m., Aleric Inglewood wrote: > > indra/llvfs/lldiriterator.cpp, line 123 > > > > > > What is your reasoning to use native() here and not string()? I tried to stick to a 1:1 replacement. The old boost::filesystem::path::filename() has return type string_type, and boost::filesystem::path::native(), too, so that seemed like the natural replacement to me. As we save the result in a std::string, my reasoning might not make too much sense, though. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/313/#review793 ----------------------------------------------------------- On May 25, 2011, 1:25 p.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/313/ > ----------------------------------------------------------- > > (Updated May 25, 2011, 1:25 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Context: We are currently using Boost 1.45, which already comes with the new Boost Filesystem Library API (Version 3) but still defaults to the old one (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will be the last one to come with V2. The Boost Filesystem Library documentation recommends "Existing code should be moved to Version 3 as soon as convenient. New code should be written for Version 3. Version 2 is deprecated, and will not be included in Boost releases 1.48 and later." > > This change overrides the default, so that the V3 API is used, and makes the necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever we feel like it.) > > Note: I only changed stuff that the compiler complained about. If the new API also changes semantic of still-compiling library usage, more changes might be necessary. > > > This addresses bug OPEN-67. > http://jira.secondlife.com/browse/OPEN-67 > > > Diffs > ----- > > doc/contributions.txt 959f9340da92 > indra/llvfs/lldiriterator.cpp 959f9340da92 > > Diff: http://codereview.secondlife.com/r/313/diff > > > Testing > ------- > > * Compiled Viewer (standalone) with Boost 1.45 > * Started Viewer > * Logged in > > * Compiled Viewer (standalone) with Boost 1.46 > * Started Viewer > * Logged in > > Not tested: > * non-standalone > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/d6d1407f/attachment.htm From alain at lindenlab.com Tue Jun 21 07:57:54 2011 From: alain at lindenlab.com (Alain Linden) Date: Tue, 21 Jun 2011 14:57:54 -0000 Subject: [opensource-dev] Review Request: Changes to fix CHOP-662. In-Reply-To: <20110621032120.19649.47155@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621032120.19649.47155@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621145754.19651.86627@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/357/#review795 ----------------------------------------------------------- Ship it! indra/llvfs/tests/lldiriterator_test.cpp Personally, I dislike referencing jira items in code comments. Its referencing something ephemeral in something that will long out live it. - Alain On June 20, 2011, 8:21 p.m., Squire Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/357/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 8:21 p.m.) > > > Review request for Viewer, Oz Linden, Seth ProductEngine, and Alain Linden. > > > Summary > ------- > > Changes to fix CHOP-662. CHOP-662 was caused by the recent addition of lldiriterator.cpp which is used to iterate over directories. It takes a mask in the form of a glob string to use as a pattern for which files to iterate over. > > Unfortunately, as originally implemented, it converted the glob to a regex pattern without escaping any legal glob characters which are illegal regex characters. As a result if the passed in mask was an illegal regex it would fail and llerrs would cause a crash. > > In CHOP-662 this happens whenever a group name has, e.g. a '+' character at the beginning. When logging in the viewer would attempt to load the group chat log file which would result in a glob starting with a '+' character and in turn to an illegal regex in lldiriterator. > > Also, the chat code was doing nothing to ensure that illegal glob characters were not being passed to the lldiriterator constructor. > > > This addresses bug CHOP-662. > http://jira.secondlife.com/browse/CHOP-662 > > > Diffs > ----- > > doc/contributions.txt e8f2a53c3d6e > indra/llvfs/CMakeLists.txt e8f2a53c3d6e > indra/llvfs/lldiriterator.cpp e8f2a53c3d6e > indra/llvfs/tests/lldiriterator_test.cpp PRE-CREATION > indra/newview/lllogchat.cpp e8f2a53c3d6e > > Diff: http://codereview.secondlife.com/r/357/diff > > > Testing > ------- > > Added a unit test for lldiriterator which checks for construction failures on examples of the most common group names which were causing the crashes. > > > Thanks, > > Squire > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/390e4c3f/attachment.htm From sllists at boroon.dasgupta.ch Tue Jun 21 08:02:12 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 21 Jun 2011 15:02:12 -0000 Subject: [opensource-dev] Review Request: Changes to fix CHOP-662. In-Reply-To: <20110621145754.19651.86627@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621145754.19651.86627@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621150212.19648.26096@domU-12-31-38-00-90-68.compute-1.internal> > On June 21, 2011, 7:57 a.m., Alain Linden wrote: > > indra/llvfs/tests/lldiriterator_test.cpp, line 46 > > > > > > Personally, I dislike referencing jira items in code comments. Its referencing something ephemeral in something that will long out live it. In general I'd agree, but here my interpretation was that this test was inspired by a specific issue. Should in that case the whole issue description be copied into the comment? - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/357/#review795 ----------------------------------------------------------- On June 20, 2011, 8:21 p.m., Squire Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/357/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 8:21 p.m.) > > > Review request for Viewer, Oz Linden, Seth ProductEngine, and Alain Linden. > > > Summary > ------- > > Changes to fix CHOP-662. CHOP-662 was caused by the recent addition of lldiriterator.cpp which is used to iterate over directories. It takes a mask in the form of a glob string to use as a pattern for which files to iterate over. > > Unfortunately, as originally implemented, it converted the glob to a regex pattern without escaping any legal glob characters which are illegal regex characters. As a result if the passed in mask was an illegal regex it would fail and llerrs would cause a crash. > > In CHOP-662 this happens whenever a group name has, e.g. a '+' character at the beginning. When logging in the viewer would attempt to load the group chat log file which would result in a glob starting with a '+' character and in turn to an illegal regex in lldiriterator. > > Also, the chat code was doing nothing to ensure that illegal glob characters were not being passed to the lldiriterator constructor. > > > This addresses bug CHOP-662. > http://jira.secondlife.com/browse/CHOP-662 > > > Diffs > ----- > > doc/contributions.txt e8f2a53c3d6e > indra/llvfs/CMakeLists.txt e8f2a53c3d6e > indra/llvfs/lldiriterator.cpp e8f2a53c3d6e > indra/llvfs/tests/lldiriterator_test.cpp PRE-CREATION > indra/newview/lllogchat.cpp e8f2a53c3d6e > > Diff: http://codereview.secondlife.com/r/357/diff > > > Testing > ------- > > Added a unit test for lldiriterator which checks for construction failures on examples of the most common group names which were causing the crashes. > > > Thanks, > > Squire > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/8d33aac5/attachment-0001.htm From vsavchuk at productengine.com Tue Jun 21 08:22:33 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 21 Jun 2011 15:22:33 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110620164943.19649.96194@domU-12-31-38-00-90-68.compute-1.internal> References: <20110620164943.19649.96194@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621152233.20870.73200@domU-12-31-38-00-90-68.compute-1.internal> > On June 20, 2011, 9:49 a.m., Vadim ProductEngine wrote: > > indra/newview/llvoicevivox.cpp, lines 4485-4488 > > > > > > What if region caps never arrive? > > The string may grow infinitely. > > > > Also I don't like using region name as a marked that region caps haven't arrived yet -- that's a hack. > > ArminWeatherHax Resident wrote: > The state engine resets the string if it was changed, but you are right, it's not nice. I'll go for adding LLVivoxVoiceClient::parcelChanged() to LLViewerParcelMgr::addAgentParcelChangedCallback which will make the whole patch more straightforward. Sounds good. BTW, while working on Windlight Region Settings I added a "capabilities received" signal in LLViewerRegion, which might be of use here as well. That code hasn't been integrated yet, but if you want I can send you the patch. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/333/#review778 ----------------------------------------------------------- On June 9, 2011, 9:56 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 9:56 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt a36a329e77cc > indra/newview/llvoicevivox.h a36a329e77cc > indra/newview/llvoicevivox.cpp a36a329e77cc > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/9b33072c/attachment.htm From vsavchuk at productengine.com Tue Jun 21 08:33:54 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 21 Jun 2011 15:33:54 -0000 Subject: [opensource-dev] Review Request: VWR-25965 LLDirIterator fixes in the viewer cache migration and VFS fallback. In-Reply-To: <20110607184234.6077.32210@domU-12-31-38-00-90-68.compute-1.internal> References: <20110607184234.6077.32210@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621153354.19655.16849@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/324/ ----------------------------------------------------------- (Updated June 21, 2011, 8:33 a.m.) Review request for Viewer. Changes ------- Fixed the ticker number. Summary ------- This removes additional leading delimiters in llappviewer needed due to the STORM-477 changes. This change should fix the fallback used when the viewer cannot find a VFS with the salt it expects to find and instead looks for any VFS data file in the cache directory to use. It also fixes cache directory migration code that runs on Mac and Windows every time the viewer is updated. This addresses bug VWR-25965. http://jira.secondlife.com/browse/VWR-25965 Diffs ----- indra/newview/llappviewer.cpp 1d4d568986e3 Diff: http://codereview.secondlife.com/r/324/diff Testing ------- Test Plan: https://jira.secondlife.com/browse/VWR-25965?focusedCommentId=264386 I ran Case 1 on Linux and Case 2 on Mac and Windows. Everything worked as expected. Thanks, Log -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/6b86435d/attachment.htm From alain at lindenlab.com Tue Jun 21 08:40:22 2011 From: alain at lindenlab.com (Alain Linden) Date: Tue, 21 Jun 2011 15:40:22 -0000 Subject: [opensource-dev] Review Request: Changes to fix CHOP-662. In-Reply-To: <20110621145754.19651.86627@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621145754.19651.86627@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621154022.19652.34783@domU-12-31-38-00-90-68.compute-1.internal> > On June 21, 2011, 7:57 a.m., Alain Linden wrote: > > indra/llvfs/tests/lldiriterator_test.cpp, line 46 > > > > > > Personally, I dislike referencing jira items in code comments. Its referencing something ephemeral in something that will long out live it. > > Boroondas Gupte wrote: > In general I'd agree, but here my interpretation was that this test was inspired by a specific issue. Should in that case the whole issue description be copied into the comment? The way I see it, the code remains long after the jira is dead and forgotten. As much as possible, code commentary should stand alone. This test makes sense regardless of what jira inspired it, so why bother mentioning it? Years from now a developer reading this code won't care about the jira. That's my opinion. - Alain ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/357/#review795 ----------------------------------------------------------- On June 20, 2011, 8:21 p.m., Squire Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/357/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 8:21 p.m.) > > > Review request for Viewer, Oz Linden, Seth ProductEngine, and Alain Linden. > > > Summary > ------- > > Changes to fix CHOP-662. CHOP-662 was caused by the recent addition of lldiriterator.cpp which is used to iterate over directories. It takes a mask in the form of a glob string to use as a pattern for which files to iterate over. > > Unfortunately, as originally implemented, it converted the glob to a regex pattern without escaping any legal glob characters which are illegal regex characters. As a result if the passed in mask was an illegal regex it would fail and llerrs would cause a crash. > > In CHOP-662 this happens whenever a group name has, e.g. a '+' character at the beginning. When logging in the viewer would attempt to load the group chat log file which would result in a glob starting with a '+' character and in turn to an illegal regex in lldiriterator. > > Also, the chat code was doing nothing to ensure that illegal glob characters were not being passed to the lldiriterator constructor. > > > This addresses bug CHOP-662. > http://jira.secondlife.com/browse/CHOP-662 > > > Diffs > ----- > > doc/contributions.txt e8f2a53c3d6e > indra/llvfs/CMakeLists.txt e8f2a53c3d6e > indra/llvfs/lldiriterator.cpp e8f2a53c3d6e > indra/llvfs/tests/lldiriterator_test.cpp PRE-CREATION > indra/newview/lllogchat.cpp e8f2a53c3d6e > > Diff: http://codereview.secondlife.com/r/357/diff > > > Testing > ------- > > Added a unit test for lldiriterator which checks for construction failures on examples of the most common group names which were causing the crashes. > > > Thanks, > > Squire > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/d0d9e65f/attachment-0001.htm From alain at lindenlab.com Tue Jun 21 08:53:09 2011 From: alain at lindenlab.com (Alain Linden) Date: Tue, 21 Jun 2011 15:53:09 -0000 Subject: [opensource-dev] Review Request: Check for null ptr to hopefully prevent crash in LLToolPie Message-ID: <20110621155309.24977.89721@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/359/ ----------------------------------------------------------- Review request for Viewer, Oz Linden and Vadim ProductEngine. Summary ------- checking for null gAgentAvatarp should hopefully prevent the crash. I can't reproduce it so I don't know for sure. This addresses bug EXP-825. http://jira.secondlife.com/browse/EXP-825 Diffs ----- indra/newview/lltoolpie.cpp e8f2a53c3d6e Diff: http://codereview.secondlife.com/r/359/diff Testing ------- Thanks, Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/69c2248e/attachment.htm From armin.weatherwax at googlemail.com Tue Jun 21 10:33:35 2011 From: armin.weatherwax at googlemail.com (ArminWeatherHax Resident) Date: Tue, 21 Jun 2011 17:33:35 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110620164943.19649.96194@domU-12-31-38-00-90-68.compute-1.internal> References: <20110620164943.19649.96194@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621173335.24113.47724@domU-12-31-38-00-90-68.compute-1.internal> > On June 20, 2011, 9:49 a.m., Vadim ProductEngine wrote: > > indra/newview/llvoicevivox.cpp, lines 4485-4488 > > > > > > What if region caps never arrive? > > The string may grow infinitely. > > > > Also I don't like using region name as a marked that region caps haven't arrived yet -- that's a hack. > > ArminWeatherHax Resident wrote: > The state engine resets the string if it was changed, but you are right, it's not nice. I'll go for adding LLVivoxVoiceClient::parcelChanged() to LLViewerParcelMgr::addAgentParcelChangedCallback which will make the whole patch more straightforward. > > Vadim ProductEngine wrote: > Sounds good. > > BTW, while working on Windlight Region Settings I added a "capabilities received" signal in LLViewerRegion, which might be of use here as well. That code hasn't been integrated yet, but if you want I can send you the patch. Currently I have a new state which rechecks capabilitiesReceived until true, and was about to add a comment to it that a callback would be much better - so yes please about sending that patch :) > On June 20, 2011, 9:49 a.m., Vadim ProductEngine wrote: > > indra/newview/llvoicevivox.cpp, line 557 > > > > > > Inconsistent spacing around "if" conditions. > > > > Please use "if (cond)" with no extra or missing spaces. > > > > This also applies to other changes in the patch. "if[space](cond)" - is that right? - ArminWeatherHax ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/333/#review778 ----------------------------------------------------------- On June 9, 2011, 9:56 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 9:56 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt a36a329e77cc > indra/newview/llvoicevivox.h a36a329e77cc > indra/newview/llvoicevivox.cpp a36a329e77cc > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/f95c224e/attachment.htm From vsavchuk at productengine.com Tue Jun 21 10:35:08 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 21 Jun 2011 17:35:08 -0000 Subject: [opensource-dev] Review Request: Check for null ptr to hopefully prevent crash in LLToolPie In-Reply-To: <20110621155309.24977.89721@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621155309.24977.89721@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621173508.19654.75221@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/359/#review800 ----------------------------------------------------------- Ship it! The check certainly will not hurt. - Vadim On June 21, 2011, 8:53 a.m., Alain Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/359/ > ----------------------------------------------------------- > > (Updated June 21, 2011, 8:53 a.m.) > > > Review request for Viewer, Oz Linden and Vadim ProductEngine. > > > Summary > ------- > > checking for null gAgentAvatarp should hopefully prevent the crash. I can't reproduce it so I don't know for sure. > > > This addresses bug EXP-825. > http://jira.secondlife.com/browse/EXP-825 > > > Diffs > ----- > > indra/newview/lltoolpie.cpp e8f2a53c3d6e > > Diff: http://codereview.secondlife.com/r/359/diff > > > Testing > ------- > > > Thanks, > > Alain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/cd214b21/attachment.htm From slitovchuk at productengine.com Tue Jun 21 10:47:55 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Tue, 21 Jun 2011 17:47:55 -0000 Subject: [opensource-dev] Review Request: Changes to fix CHOP-662. In-Reply-To: <20110621145754.19651.86627@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621145754.19651.86627@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621174755.20869.36754@domU-12-31-38-00-90-68.compute-1.internal> > On June 21, 2011, 7:57 a.m., Alain Linden wrote: > > indra/llvfs/tests/lldiriterator_test.cpp, line 46 > > > > > > Personally, I dislike referencing jira items in code comments. Its referencing something ephemeral in something that will long out live it. > > Boroondas Gupte wrote: > In general I'd agree, but here my interpretation was that this test was inspired by a specific issue. Should in that case the whole issue description be copied into the comment? > > Alain Linden wrote: > The way I see it, the code remains long after the jira is dead and forgotten. As much as possible, code commentary should stand alone. This test makes sense regardless of what jira inspired it, so why bother mentioning it? Years from now a developer reading this code won't care about the jira. That's my opinion. There is a test file where LLDirIterator is used: llvfs\tests\lldir_test.cpp. May be this unit test could be placed there? - Seth ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/357/#review795 ----------------------------------------------------------- On June 20, 2011, 8:21 p.m., Squire Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/357/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 8:21 p.m.) > > > Review request for Viewer, Oz Linden, Seth ProductEngine, and Alain Linden. > > > Summary > ------- > > Changes to fix CHOP-662. CHOP-662 was caused by the recent addition of lldiriterator.cpp which is used to iterate over directories. It takes a mask in the form of a glob string to use as a pattern for which files to iterate over. > > Unfortunately, as originally implemented, it converted the glob to a regex pattern without escaping any legal glob characters which are illegal regex characters. As a result if the passed in mask was an illegal regex it would fail and llerrs would cause a crash. > > In CHOP-662 this happens whenever a group name has, e.g. a '+' character at the beginning. When logging in the viewer would attempt to load the group chat log file which would result in a glob starting with a '+' character and in turn to an illegal regex in lldiriterator. > > Also, the chat code was doing nothing to ensure that illegal glob characters were not being passed to the lldiriterator constructor. > > > This addresses bug CHOP-662. > http://jira.secondlife.com/browse/CHOP-662 > > > Diffs > ----- > > doc/contributions.txt e8f2a53c3d6e > indra/llvfs/CMakeLists.txt e8f2a53c3d6e > indra/llvfs/lldiriterator.cpp e8f2a53c3d6e > indra/llvfs/tests/lldiriterator_test.cpp PRE-CREATION > indra/newview/lllogchat.cpp e8f2a53c3d6e > > Diff: http://codereview.secondlife.com/r/357/diff > > > Testing > ------- > > Added a unit test for lldiriterator which checks for construction failures on examples of the most common group names which were causing the crashes. > > > Thanks, > > Squire > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/9545ebba/attachment-0001.htm From vsavchuk at productengine.com Tue Jun 21 10:50:07 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 21 Jun 2011 17:50:07 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110620164943.19649.96194@domU-12-31-38-00-90-68.compute-1.internal> References: <20110620164943.19649.96194@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621175007.24975.16920@domU-12-31-38-00-90-68.compute-1.internal> > On June 20, 2011, 9:49 a.m., Vadim ProductEngine wrote: > > indra/newview/llvoicevivox.cpp, line 557 > > > > > > Inconsistent spacing around "if" conditions. > > > > Please use "if (cond)" with no extra or missing spaces. > > > > This also applies to other changes in the patch. > > ArminWeatherHax Resident wrote: > "if[space](cond)" - is that right? Yes. > On June 20, 2011, 9:49 a.m., Vadim ProductEngine wrote: > > indra/newview/llvoicevivox.cpp, lines 4485-4488 > > > > > > What if region caps never arrive? > > The string may grow infinitely. > > > > Also I don't like using region name as a marked that region caps haven't arrived yet -- that's a hack. > > ArminWeatherHax Resident wrote: > The state engine resets the string if it was changed, but you are right, it's not nice. I'll go for adding LLVivoxVoiceClient::parcelChanged() to LLViewerParcelMgr::addAgentParcelChangedCallback which will make the whole patch more straightforward. > > Vadim ProductEngine wrote: > Sounds good. > > BTW, while working on Windlight Region Settings I added a "capabilities received" signal in LLViewerRegion, which might be of use here as well. That code hasn't been integrated yet, but if you want I can send you the patch. > > ArminWeatherHax Resident wrote: > Currently I have a new state which rechecks capabilitiesReceived until true, and was about to add a comment to it that a callback would be much better - so yes please about sending that patch :) Sent. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/333/#review778 ----------------------------------------------------------- On June 9, 2011, 9:56 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 9:56 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt a36a329e77cc > indra/newview/llvoicevivox.h a36a329e77cc > indra/newview/llvoicevivox.cpp a36a329e77cc > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/b15908c3/attachment.htm From slitovchuk at productengine.com Tue Jun 21 10:54:29 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Tue, 21 Jun 2011 17:54:29 -0000 Subject: [opensource-dev] Review Request: Changes to fix CHOP-662. In-Reply-To: <20110621032120.19649.47155@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621032120.19649.47155@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621175429.24113.7722@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/357/#review803 ----------------------------------------------------------- Ship it! The glob to regex conversion was not initially supposed to accept user input as its argument that's why it lacked the checks for valid glob expressions. But now it looks like these checks are necessary for this case. - Seth On June 20, 2011, 8:21 p.m., Squire Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/357/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 8:21 p.m.) > > > Review request for Viewer, Oz Linden, Seth ProductEngine, and Alain Linden. > > > Summary > ------- > > Changes to fix CHOP-662. CHOP-662 was caused by the recent addition of lldiriterator.cpp which is used to iterate over directories. It takes a mask in the form of a glob string to use as a pattern for which files to iterate over. > > Unfortunately, as originally implemented, it converted the glob to a regex pattern without escaping any legal glob characters which are illegal regex characters. As a result if the passed in mask was an illegal regex it would fail and llerrs would cause a crash. > > In CHOP-662 this happens whenever a group name has, e.g. a '+' character at the beginning. When logging in the viewer would attempt to load the group chat log file which would result in a glob starting with a '+' character and in turn to an illegal regex in lldiriterator. > > Also, the chat code was doing nothing to ensure that illegal glob characters were not being passed to the lldiriterator constructor. > > > This addresses bug CHOP-662. > http://jira.secondlife.com/browse/CHOP-662 > > > Diffs > ----- > > doc/contributions.txt e8f2a53c3d6e > indra/llvfs/CMakeLists.txt e8f2a53c3d6e > indra/llvfs/lldiriterator.cpp e8f2a53c3d6e > indra/llvfs/tests/lldiriterator_test.cpp PRE-CREATION > indra/newview/lllogchat.cpp e8f2a53c3d6e > > Diff: http://codereview.secondlife.com/r/357/diff > > > Testing > ------- > > Added a unit test for lldiriterator which checks for construction failures on examples of the most common group names which were causing the crashes. > > > Thanks, > > Squire > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/e4f32b61/attachment.htm From Aleric.Inglewood at gmail.com Tue Jun 21 15:02:41 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Tue, 21 Jun 2011 22:02:41 -0000 Subject: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer) In-Reply-To: <20110621135606.20869.5001@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621135606.20869.5001@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621220241.19651.78991@domU-12-31-38-00-90-68.compute-1.internal> > On June 21, 2011, 6:56 a.m., Aleric Inglewood wrote: > > indra/llvfs/lldiriterator.cpp, line 123 > > > > > > What is your reasoning to use native() here and not string()? > > Boroondas Gupte wrote: > I tried to stick to a 1:1 replacement. The old boost::filesystem::path::filename() has return type string_type, and boost::filesystem::path::native(), too, so that seemed like the natural replacement to me. As we save the result in a std::string, my reasoning might not make too much sense, though. No that makes no sense at all, since boost::filesystem::path::native::string() also returns a std::string. So, still the same question: why mIter->path().filename().native() and not mIter->path().filename().string()? - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/313/#review793 ----------------------------------------------------------- On May 25, 2011, 1:25 p.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/313/ > ----------------------------------------------------------- > > (Updated May 25, 2011, 1:25 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Context: We are currently using Boost 1.45, which already comes with the new Boost Filesystem Library API (Version 3) but still defaults to the old one (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will be the last one to come with V2. The Boost Filesystem Library documentation recommends "Existing code should be moved to Version 3 as soon as convenient. New code should be written for Version 3. Version 2 is deprecated, and will not be included in Boost releases 1.48 and later." > > This change overrides the default, so that the V3 API is used, and makes the necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever we feel like it.) > > Note: I only changed stuff that the compiler complained about. If the new API also changes semantic of still-compiling library usage, more changes might be necessary. > > > This addresses bug OPEN-67. > http://jira.secondlife.com/browse/OPEN-67 > > > Diffs > ----- > > doc/contributions.txt 959f9340da92 > indra/llvfs/lldiriterator.cpp 959f9340da92 > > Diff: http://codereview.secondlife.com/r/313/diff > > > Testing > ------- > > * Compiled Viewer (standalone) with Boost 1.45 > * Started Viewer > * Logged in > > * Compiled Viewer (standalone) with Boost 1.46 > * Started Viewer > * Logged in > > Not tested: > * non-standalone > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/78c53a5f/attachment.htm From Aleric.Inglewood at gmail.com Tue Jun 21 15:03:15 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Tue, 21 Jun 2011 22:03:15 -0000 Subject: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer) In-Reply-To: <20110621135606.20869.5001@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621135606.20869.5001@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621220315.19648.51271@domU-12-31-38-00-90-68.compute-1.internal> > On June 21, 2011, 6:56 a.m., Aleric Inglewood wrote: > > indra/llvfs/lldiriterator.cpp, line 123 > > > > > > What is your reasoning to use native() here and not string()? > > Boroondas Gupte wrote: > I tried to stick to a 1:1 replacement. The old boost::filesystem::path::filename() has return type string_type, and boost::filesystem::path::native(), too, so that seemed like the natural replacement to me. As we save the result in a std::string, my reasoning might not make too much sense, though. > > Aleric Inglewood wrote: > No that makes no sense at all, since boost::filesystem::path::native::string() also returns a std::string. > So, still the same question: why mIter->path().filename().native() and not mIter->path().filename().string()? > I meant boost::filesystem::path::string() - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/313/#review793 ----------------------------------------------------------- On May 25, 2011, 1:25 p.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/313/ > ----------------------------------------------------------- > > (Updated May 25, 2011, 1:25 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Context: We are currently using Boost 1.45, which already comes with the new Boost Filesystem Library API (Version 3) but still defaults to the old one (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will be the last one to come with V2. The Boost Filesystem Library documentation recommends "Existing code should be moved to Version 3 as soon as convenient. New code should be written for Version 3. Version 2 is deprecated, and will not be included in Boost releases 1.48 and later." > > This change overrides the default, so that the V3 API is used, and makes the necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever we feel like it.) > > Note: I only changed stuff that the compiler complained about. If the new API also changes semantic of still-compiling library usage, more changes might be necessary. > > > This addresses bug OPEN-67. > http://jira.secondlife.com/browse/OPEN-67 > > > Diffs > ----- > > doc/contributions.txt 959f9340da92 > indra/llvfs/lldiriterator.cpp 959f9340da92 > > Diff: http://codereview.secondlife.com/r/313/diff > > > Testing > ------- > > * Compiled Viewer (standalone) with Boost 1.45 > * Started Viewer > * Logged in > > * Compiled Viewer (standalone) with Boost 1.46 > * Started Viewer > * Logged in > > Not tested: > * non-standalone > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/266906a2/attachment.htm From sllists at boroon.dasgupta.ch Tue Jun 21 15:35:19 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 21 Jun 2011 22:35:19 -0000 Subject: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer) In-Reply-To: <20110621135606.20869.5001@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621135606.20869.5001@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110621223519.19653.32120@domU-12-31-38-00-90-68.compute-1.internal> > On June 21, 2011, 6:56 a.m., Aleric Inglewood wrote: > > indra/llvfs/lldiriterator.cpp, line 123 > > > > > > What is your reasoning to use native() here and not string()? > > Boroondas Gupte wrote: > I tried to stick to a 1:1 replacement. The old boost::filesystem::path::filename() has return type string_type, and boost::filesystem::path::native(), too, so that seemed like the natural replacement to me. As we save the result in a std::string, my reasoning might not make too much sense, though. > > Aleric Inglewood wrote: > No that makes no sense at all, since boost::filesystem::path::native::string() also returns a std::string. > So, still the same question: why mIter->path().filename().native() and not mIter->path().filename().string()? > > > Aleric Inglewood wrote: > I meant boost::filesystem::path::string() The reason I've given above is the only one I had. If that one doesn't make sense, no reason is left for preferring mIter->path().filename().native() over mIter->path().filename().string(), AFAIK. However, I also see no reason to prefer mIter->path().filename().string() over mIter->path().filename().native(). >From the documentation, it seems they should give the exactly same data: the path's (here: the filename's) content as std::string with OS-native directory-separator characters (which shouldn't occur in a path that's just a filename). What could make sense is to use mIter->path().filename().generic_string(), so that the (effectless for pure filenames) '/' --> '\' conversion doesn't have to be executed on Windows. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/313/#review793 ----------------------------------------------------------- On May 25, 2011, 1:25 p.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/313/ > ----------------------------------------------------------- > > (Updated May 25, 2011, 1:25 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Context: We are currently using Boost 1.45, which already comes with the new Boost Filesystem Library API (Version 3) but still defaults to the old one (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will be the last one to come with V2. The Boost Filesystem Library documentation recommends "Existing code should be moved to Version 3 as soon as convenient. New code should be written for Version 3. Version 2 is deprecated, and will not be included in Boost releases 1.48 and later." > > This change overrides the default, so that the V3 API is used, and makes the necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever we feel like it.) > > Note: I only changed stuff that the compiler complained about. If the new API also changes semantic of still-compiling library usage, more changes might be necessary. > > > This addresses bug OPEN-67. > http://jira.secondlife.com/browse/OPEN-67 > > > Diffs > ----- > > doc/contributions.txt 959f9340da92 > indra/llvfs/lldiriterator.cpp 959f9340da92 > > Diff: http://codereview.secondlife.com/r/313/diff > > > Testing > ------- > > * Compiled Viewer (standalone) with Boost 1.45 > * Started Viewer > * Logged in > > * Compiled Viewer (standalone) with Boost 1.46 > * Started Viewer > * Logged in > > Not tested: > * non-standalone > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110621/2f82f8b9/attachment-0001.htm From oz at lindenlab.com Wed Jun 22 03:34:51 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 22 Jun 2011 10:34:51 -0000 Subject: [opensource-dev] Review Request: Changes to fix CHOP-662. In-Reply-To: <20110621032120.19649.47155@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621032120.19649.47155@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110622103451.19649.17466@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/357/#review809 ----------------------------------------------------------- doc/contributions.txt Lindens should not be added here (much as we're glad to have your help, Squire) - Oz On June 20, 2011, 8:21 p.m., Squire Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/357/ > ----------------------------------------------------------- > > (Updated June 20, 2011, 8:21 p.m.) > > > Review request for Viewer, Oz Linden, Seth ProductEngine, and Alain Linden. > > > Summary > ------- > > Changes to fix CHOP-662. CHOP-662 was caused by the recent addition of lldiriterator.cpp which is used to iterate over directories. It takes a mask in the form of a glob string to use as a pattern for which files to iterate over. > > Unfortunately, as originally implemented, it converted the glob to a regex pattern without escaping any legal glob characters which are illegal regex characters. As a result if the passed in mask was an illegal regex it would fail and llerrs would cause a crash. > > In CHOP-662 this happens whenever a group name has, e.g. a '+' character at the beginning. When logging in the viewer would attempt to load the group chat log file which would result in a glob starting with a '+' character and in turn to an illegal regex in lldiriterator. > > Also, the chat code was doing nothing to ensure that illegal glob characters were not being passed to the lldiriterator constructor. > > > This addresses bug CHOP-662. > http://jira.secondlife.com/browse/CHOP-662 > > > Diffs > ----- > > doc/contributions.txt e8f2a53c3d6e > indra/llvfs/CMakeLists.txt e8f2a53c3d6e > indra/llvfs/lldiriterator.cpp e8f2a53c3d6e > indra/llvfs/tests/lldiriterator_test.cpp PRE-CREATION > indra/newview/lllogchat.cpp e8f2a53c3d6e > > Diff: http://codereview.secondlife.com/r/357/diff > > > Testing > ------- > > Added a unit test for lldiriterator which checks for construction failures on examples of the most common group names which were causing the crashes. > > > Thanks, > > Squire > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110622/1691d88b/attachment.htm From oz at lindenlab.com Wed Jun 22 08:35:04 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 22 Jun 2011 15:35:04 -0000 Subject: [opensource-dev] Review Request: Check for null ptr to hopefully prevent crash in LLToolPie In-Reply-To: <20110621155309.24977.89721@domU-12-31-38-00-90-68.compute-1.internal> References: <20110621155309.24977.89721@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110622153504.19650.68595@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/359/#review810 ----------------------------------------------------------- Ship it! Whether that's the crash or not, it's obviously a good idea - Oz On June 21, 2011, 8:53 a.m., Alain Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/359/ > ----------------------------------------------------------- > > (Updated June 21, 2011, 8:53 a.m.) > > > Review request for Viewer, Oz Linden and Vadim ProductEngine. > > > Summary > ------- > > checking for null gAgentAvatarp should hopefully prevent the crash. I can't reproduce it so I don't know for sure. > > > This addresses bug EXP-825. > http://jira.secondlife.com/browse/EXP-825 > > > Diffs > ----- > > indra/newview/lltoolpie.cpp e8f2a53c3d6e > > Diff: http://codereview.secondlife.com/r/359/diff > > > Testing > ------- > > > Thanks, > > Alain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110622/12337e02/attachment.htm From sllists at boroon.dasgupta.ch Wed Jun 22 13:19:36 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 22 Jun 2011 20:19:36 -0000 Subject: [opensource-dev] Review Request: OPEN-99: use -march=pentium3 and -march=pentium4 only for 32 bit builds In-Reply-To: <20110620232412.24977.44841@domU-12-31-38-00-90-68.compute-1.internal> References: <20110620232412.24977.44841@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110622201936.24978.40203@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/351/ ----------------------------------------------------------- (Updated June 22, 2011, 1:19 p.m.) Review request for Viewer. Changes ------- In 'Testing Done': Replaced output for standalone 64-bit build with reference to OPEN-100. Noted that failure of 64-bit build using 32-bit prebuilts is expected. Summary ------- These flags prevent building for 64-bit (both standalone or non-standalone), so only use them for 32-bit builds. This addresses bug OPEN-99. http://jira.secondlife.com/browse/OPEN-99 Diffs ----- doc/contributions.txt e8f2a53c3d6e indra/cmake/00-Common.cmake e8f2a53c3d6e Diff: http://codereview.secondlife.com/r/351/diff Testing (updated) ------- Tried a non-standalone 64-bit build (without using 64-bit prebuilts, though): Fails with [ 11%] Building CXX object llcommon/CMakeFiles/llcommon.dir/u64.o Linking CXX shared library libllcommon.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible ${SRC_DIR}/build-linux-i686/packages/lib/release/libbreakpad_client.so when searching for -lbreakpad_client /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible ${SRC_DIR}/build-linux-i686/packages/lib/release/libaprutil-1.so when searching for -laprutil-1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible ${SRC_DIR}/build-linux-i686/packages/lib/release/libaprutil-1.a when searching for -laprutil-1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible ${SRC_DIR}/build-linux-i686/packages/lib/release/libdb-5.1.so when searching for -ldb-5.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -ldb-5.1 collect2: ld returned 1 exit status make[2]: *** [llcommon/libllcommon.so] Error 1 make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2 make: *** [all] Error 2 ERROR: building default configuration returned 2 For more information: try re-running your command with --verbose or --debug (This is, off course, expected. Will have to produce my own 64bit prebuilts for local use.) Tried a standalone 64-bit build (after merging OPEN-38 changes): Fails by hitting https://jira.secondlife.com/browse/OPEN-100 (Both errors occur much later in the build process than the one that'd occur without this change.) Tried a non-standalone 32-bit build: Fails on https://jira.secondlife.com/browse/OPEN-23 , just as without this change. Thanks, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110622/39428600/attachment.htm From oz at lindenlab.com Wed Jun 22 13:39:02 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 22 Jun 2011 20:39:02 -0000 Subject: [opensource-dev] Review Request: Local Bitmap Browser implementation. In-Reply-To: <20110618150447.3681.36306@domU-12-31-38-00-90-68.compute-1.internal> References: <20110618150447.3681.36306@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110622203902.19651.40134@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/347/#review811 ----------------------------------------------------------- indra/llmath/llvolumemgr.cpp Unnecessary early returns. LLVolume* vol = NULL; if ( lod <= NUM_LODS && ! mVolumeLODs[lod].isNull() ) { vol = mVolumeLODs[lod]; } return vol; indra/newview/llfloaterlocalbitmap.cpp (many instances of this throughout) All these clauses should reverse the sense of the tests and only have a single break at the end of each case clause. The use of early returns is unhelpful when debugging - set a variable and return at the bottom. indra/newview/llfloaterlocalbitmap.cpp What's wrong with combining these ifs and not needing the continues? I know this is getting repetitious.... indra/newview/llfloaterlocalbitmap.cpp Nice logging ! indra/newview/llfloaterlocalbitmap.cpp Really a global comment... don't put braces all on one line, please. See https://wiki.secondlife.com/wiki/Coding_Standard#Braces - Oz On June 18, 2011, 8:04 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/347/ > ----------------------------------------------------------- > > (Updated June 18, 2011, 8:04 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Local Bitmap Browser is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects build menu by adding a way to open the floater there. > This change also affects the texture picker - adding tabs that lets the user choose between the "Server" (regular inventory) and "Local" tabs (list of locally added files). > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 6a3e7e403bd1 > indra/llmath/llvolumemgr.h 6a3e7e403bd1 > indra/llmath/llvolumemgr.cpp 6a3e7e403bd1 > indra/newview/CMakeLists.txt 6a3e7e403bd1 > indra/newview/llfloaterlocalbitmap.h PRE-CREATION > indra/newview/llfloaterlocalbitmap.cpp PRE-CREATION > indra/newview/lltexturectrl.h 6a3e7e403bd1 > indra/newview/lltexturectrl.cpp 6a3e7e403bd1 > indra/newview/llviewerfloaterreg.cpp 6a3e7e403bd1 > indra/newview/llviewerobjectlist.h 6a3e7e403bd1 > indra/newview/llviewertexturelist.h 6a3e7e403bd1 > indra/newview/llvovolume.h 6a3e7e403bd1 > indra/newview/skins/default/xui/en/floater_local_bitmap.xml PRE-CREATION > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 6a3e7e403bd1 > indra/newview/skins/default/xui/en/menu_viewer.xml 6a3e7e403bd1 > > Diff: http://codereview.secondlife.com/r/347/diff > > > Testing > ------- > > Texture/Sculptmap/Avatar Layer show. > Texture/Sculptmap/Avatar Layer update. > Multiple sculpties update. > Opening multiple browser floaters works correctly. (two possible since one can be opened from menu above, one from texture picker. all of them + texture picker play nice.) > Tested adding over 200 images at the same time. > > > Thanks, > > Vaalith > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110622/91bef788/attachment-0001.htm From trilobyte550m at gmail.com Wed Jun 22 21:10:09 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 22 Jun 2011 21:10:09 -0700 Subject: [opensource-dev] Highlight Transparent Broken? Message-ID: Is it just me, or is Advanced -> Highlighting and Visibility -> Highlight Transparent broken? I convinced my girlfriend to try the development viewer on her machine, and she pointed it out (it's not a feature I use much). Normally, when enabled, it should highlight any.all prims with transparency in red, and in build 233586 (mac client) it doesn't appear to be doing anything. Is this happening to anyone else? TriloByte Zanzibar From lee.ponzu at gmail.com Wed Jun 22 22:06:05 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Thu, 23 Jun 2011 01:06:05 -0400 Subject: [opensource-dev] Is it just me? Avatar textures downloading last. In-Reply-To: <201106210303.58294.thickbrick.sleaford@gmail.com> References: <201106210303.58294.thickbrick.sleaford@gmail.com> Message-ID: - 1. Second Life Viewer - VWR - VWR-26093 Mass avatar texture rebake and load failures resulting in blury and grey textures which do not resolve on their own Already exists. I added a comment and my logs to it. Shoud this be a VWR Jira? Or could it be related to some other system. ponzu On Mon, Jun 20, 2011 at 8:03 PM, Thickbrick Sleaford < thickbrick.sleaford at gmail.com> wrote: > On Saturday 18 June 2011 20:00:04 Lee ponzu wrote: > > However, and unrelated to shadows, I began to notice last night that > while > > my scenes had all downloaded, the avatars around me were still all gray. > > Their objects were OK, it was just their skin and cloth final bake that > is > > missing. They do show up after several minutes, but long after > everything > > else. > > > > I've noticed avatar bakes taking very long to un-gray too, when trying the > SL > v2 viewer recently after not using it for a long-ish while. This is > especially > noticeable in crowded areas. > > Looking at the texture console, it looks like any fetch that is using udp > (i.e. bakes, since they can not be fetched via http) is always at the > bottom > of the list, and usually gets bumped out quickly. I haven't tested this, > but I > get the feeling that the udp fetches are starved out of processing by the > regular http fetches. If I stay a while in a gray people gathering, and > then > relog, the once-gray people have at least one discard level of their bakes > quickly decoded, probably from cache. This makes me think that this is a > prioritization issue, possibly caused by the quick turn-around of http > textures. > > -- > Thickbrick > _______________________________________________ > 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/20110623/99f53748/attachment.htm From lee.ponzu at gmail.com Wed Jun 22 22:08:27 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Thu, 23 Jun 2011 01:08:27 -0400 Subject: [opensource-dev] Stop Animating Me gone missing... Message-ID: Using latest dev 2.7.5.xxxx. I needed to stop my animation but couldn't find it in the menu. Didn't it used to be there? Should it be there? Was it removed on purpose? Am I merely blind or drunk? Someone had to remind me that we used to use a wearable object to do that, and that worked fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110623/8b22ef25/attachment.htm From lee.ponzu at gmail.com Wed Jun 22 22:18:03 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Thu, 23 Jun 2011 01:18:03 -0400 Subject: [opensource-dev] Stop Animating Me gone missing... In-Reply-To: References: Message-ID: Never mind....found it. 8-( On Thu, Jun 23, 2011 at 1:08 AM, Lee ponzu wrote: > Using latest dev 2.7.5.xxxx. I needed to stop my animation but couldn't > find it in the menu. Didn't it used to be there? Should it be there? Was > it removed on purpose? Am I merely blind or drunk? > > Someone had to remind me that we used to use a wearable object to do that, > and that worked fine. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110623/fcaff023/attachment.htm From holydoughnuts at gmail.com Wed Jun 22 22:40:19 2011 From: holydoughnuts at gmail.com (holydoughnuts) Date: Thu, 23 Jun 2011 01:40:19 -0400 Subject: [opensource-dev] Highlight Transparent Broken? In-Reply-To: References: Message-ID: <4E02D1C3.1040906@gmail.com> On 6/23/2011 12:10 AM, Trilo Byte wrote: > Is it just me, or is Advanced -> Highlighting and Visibility -> Highlight Transparent broken? > > I convinced my girlfriend to try the development viewer on her machine, and she pointed it out (it's not a feature I use much). Normally, when enabled, it should highlight any.all prims with transparency in red, and in build 233586 (mac client) it doesn't appear to be doing anything. Is this happening to anyone else? Hmm, yes it repros here, Win7/ATI. Ctrl-Alt-T only works if I disable basic shaders. (I think it's expected that it won't fully work if automatic alpha is on, but it's definitely switched off here.) From jhwelch at gmail.com Thu Jun 23 02:31:44 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Thu, 23 Jun 2011 05:31:44 -0400 Subject: [opensource-dev] Highlight Transparent Broken? In-Reply-To: <4E02D1C3.1040906@gmail.com> References: <4E02D1C3.1040906@gmail.com> Message-ID: Could you also check glow (cts-644/cts-656) and windlight clouds (storm-1314) to see if either of those are non-functional for you? I have a feeling that some of these are related to each other. From trilobyte550m at gmail.com Thu Jun 23 07:55:16 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Thu, 23 Jun 2011 07:55:16 -0700 Subject: [opensource-dev] Highlight Transparent Broken? In-Reply-To: References: <4E02D1C3.1040906@gmail.com> Message-ID: CTS-644/CTS-656 - glow works onViewer-Dev build 233586, Mac client. STORM-1314 - windlight clouds are also fine on Viewer-Dev build 233586, Mac client. On Jun 23, 2011, at 2:31 AM, Jonathan Welch wrote: > Could you also check glow (cts-644/cts-656) and windlight clouds > (storm-1314) to see if either of those are non-functional for you? I > have a feeling that some of these are related to each other. > _______________________________________________ > 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 monty at lindenlab.com Thu Jun 23 08:40:37 2011 From: monty at lindenlab.com (Monty Brandenberg) Date: Thu, 23 Jun 2011 11:40:37 -0400 Subject: [opensource-dev] Is it just me? Avatar textures downloading last. In-Reply-To: References: <201106210303.58294.thickbrick.sleaford@gmail.com> Message-ID: <4E035E75.2010408@lindenlab.com> On 6/23/2011 1:06 AM, Lee ponzu wrote: > * 1. Second Life Viewer - VWR > * VWR-26093 > > > Mass avatar texture rebake and load failures resulting in blury and > grey textures which do not resolve on their own > > > > Already exists. I added a comment and my logs to it. Shoud this be a > VWR Jira? Or could it be related to some other system. That's fine. We'll move it around as needed. And thanks for DEBUG level info. (Sim has the enable_simulator storm I hate. Not the problem, just sticks out....) From dave at meadowlakearts.com Thu Jun 23 18:47:52 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Thu, 23 Jun 2011 20:47:52 -0500 Subject: [opensource-dev] Wierd experience last four builds.. just me? Message-ID: <4E03ECC8.1020403@meadowlakearts.com> I've been experiencing a crash on initial login with the last four builds. The FIRST time I connect with a new build download it bluescreens my PC, subsequent logins work just fine.. Anyone else experiencing anything similar? Config details below: Second Life 2.7.5 (233708) Jun 23 2011 10:46:18 (Second Life Development) Release Notes You are at 250,670.0, 245,092.0, 4,011.0 in Mextli located at sim9935.agni.lindenlab.com (216.82.46.77:13004) Second Life Server 11.06.14.232746 Release Notes CPU: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz (1729.02 MHz) Memory: 6125 MB OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GT 425M/PCI/SSE2 Windows Graphics Driver Version: 8.17.0012.7533 OpenGL Version: 4.1.0 libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1 J2C Decoder Version: KDU v6.4.1 Audio Driver Version: FMOD version 3.750000 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Not Connected Built with MSVC version 1600 Packets Lost: 1/6,812 (0.0%) From holydoughnuts at gmail.com Thu Jun 23 21:17:21 2011 From: holydoughnuts at gmail.com (holydoughnuts) Date: Fri, 24 Jun 2011 00:17:21 -0400 Subject: [opensource-dev] Highlight Transparent Broken? In-Reply-To: References: <4E02D1C3.1040906@gmail.com> Message-ID: <4E040FD1.1040608@gmail.com> On 6/23/2011 5:31 AM, Jonathan Welch wrote: > Could you also check glow (cts-644/cts-656) and windlight clouds > (storm-1314) to see if either of those are non-functional for you? I > have a feeling that some of these are related to each other. Those are OK here. I have to disable them to make Ctrl-Alt-T work but otherwise they're fine. From armin.weatherwax at googlemail.com Fri Jun 24 03:52:34 2011 From: armin.weatherwax at googlemail.com (ArminWeatherHax Resident) Date: Fri, 24 Jun 2011 10:52:34 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110609165620.6514.70030@domU-12-31-38-00-90-68.compute-1.internal> References: <20110609165620.6514.70030@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110624105234.24978.58167@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/333/#review813 ----------------------------------------------------------- I pushed a new version of the patch to https://bitbucket.org/ArminW/vwr-25923 Its 2 commits: * first Vadims patch * then my patch addressing the reviews here - ArminWeatherHax On June 9, 2011, 9:56 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 9, 2011, 9:56 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt a36a329e77cc > indra/newview/llvoicevivox.h a36a329e77cc > indra/newview/llvoicevivox.cpp a36a329e77cc > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110624/7aa6fe06/attachment.htm From jhwelch at gmail.com Fri Jun 24 04:45:37 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 24 Jun 2011 11:45:37 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110609165620.6514.70030@domU-12-31-38-00-90-68.compute-1.internal> References: <20110609165620.6514.70030@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110624114537.19652.67354@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/333/ ----------------------------------------------------------- (Updated June 24, 2011, 4:45 a.m.) Review request for Viewer. Summary ------- This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. ---- Ways to reproduce: log into a simulator. Reproduces: always Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). What happens: In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing Expected: On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). ---- going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. This addresses bug VWR-25923. http://jira.secondlife.com/browse/VWR-25923 Diffs (updated) ----- doc/contributions.txt 04e2a3ddca51 indra/newview/llviewerregion.h 04e2a3ddca51 indra/newview/llviewerregion.cpp 04e2a3ddca51 indra/newview/llvoicevivox.h 04e2a3ddca51 indra/newview/llvoicevivox.cpp 04e2a3ddca51 Diff: http://codereview.secondlife.com/r/333/diff Testing ------- Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110624/6f631ce1/attachment.htm From sllists at boroon.dasgupta.ch Fri Jun 24 06:05:02 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 24 Jun 2011 13:05:02 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110624114537.19652.67354@domU-12-31-38-00-90-68.compute-1.internal> References: <20110624114537.19652.67354@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110624130502.20868.32413@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/333/#review814 ----------------------------------------------------------- indra/newview/llvoicevivox.h Very good idea to explain the semantics of this field in detail, as the name alone doesn't give it away fully. :-) indra/newview/llvoicevivox.cpp These are two sentences. Use a period instead of a comma. indra/newview/llvoicevivox.cpp requestParcelInfo() might be a more natural name than using 'do'. indra/newview/llvoicevivox.h Not a native speaker myself, but I don't think 'keep s.th. staying in ' is proper English. Maybe either write // Setting mRegionHasVoiceCaps to false makes the voice client stay in stateDisabled. or simply // Setting mRegionHasVoiceCaps to false keeps the voice client in stateDisabled. indra/newview/llvoicevivox.h This sentence confused me for some reason. I guess 'allows to leave' would be clearer than 'allows escaping'. indra/newview/llvoicevivox.cpp I think this should be "changed region before the region cap response for the previous region arrived" to be clear. indra/newview/llvoicevivox.cpp https://wiki.secondlife.com/wiki/Coding_standard#Naming_Convention says local variables should be lower_case, not camelCase so make this parcel_local_ID. indra/newview/llvoicevivox.cpp What does the first 'it' refer to? "ID with" what? indra/newview/llvoicevivox.cpp Why not directly mCurrentRegion = gAgent.getRegion(); and then use mCurrentRegion in the rest of this method? indra/newview/llvoicevivox.cpp Here, too, either just 'keeps' without 'staying' or 'makes [...] stay', I think. - Boroondas On June 24, 2011, 4:45 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 24, 2011, 4:45 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt 04e2a3ddca51 > indra/newview/llviewerregion.h 04e2a3ddca51 > indra/newview/llviewerregion.cpp 04e2a3ddca51 > indra/newview/llvoicevivox.h 04e2a3ddca51 > indra/newview/llvoicevivox.cpp 04e2a3ddca51 > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110624/51ab7d49/attachment-0001.htm From lee.ponzu at gmail.com Fri Jun 24 07:11:39 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Fri, 24 Jun 2011 10:11:39 -0400 Subject: [opensource-dev] Great article on SCALE in SL. Message-ID: There are a few things in here directly relevant to the viewer. See for example Camera Placement. Can someone send a copy to Rodvik Linden 8-) http://community.secondlife.com/t5/Building-and-Texturing-Forum/A-Matter-of-Scale-How-scale-affects-content-creation-and-land/td-p/943101 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110624/7e31176a/attachment.htm From lee.ponzu at gmail.com Fri Jun 24 08:08:58 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Fri, 24 Jun 2011 11:08:58 -0400 Subject: [opensource-dev] A question/comment about the behavior of auto-pilot camera. Message-ID: I use auto-pilot a lot, because for me arrow keys to move are problematic. I find it convenient to double-click on a spot, and then not have to worry until I get there. If the camera is in its default state, then the camera moves along following my head. This is fine. However, if I alt-click on some point off to the side, and then double click to auto-pilot, the camera focus moves along with my avatar. I think it would be better (for me) if the alt-click point was more sticky, so the camera stayed focused on it while my avatar does it's auto-pilot. Does that make sense to people? Maybe it would make auto-pilot more popular. Anyway, just babbling. Thanks for listening. Ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110624/40f721ae/attachment.htm From vsavchuk at productengine.com Fri Jun 24 09:15:24 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Fri, 24 Jun 2011 16:15:24 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110624114537.19652.67354@domU-12-31-38-00-90-68.compute-1.internal> References: <20110624114537.19652.67354@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110624161524.24978.42984@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/333/#review815 ----------------------------------------------------------- Ship it! No major objections now, thanks. - Vadim On June 24, 2011, 4:45 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 24, 2011, 4:45 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt 04e2a3ddca51 > indra/newview/llviewerregion.h 04e2a3ddca51 > indra/newview/llviewerregion.cpp 04e2a3ddca51 > indra/newview/llvoicevivox.h 04e2a3ddca51 > indra/newview/llvoicevivox.cpp 04e2a3ddca51 > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110624/2e1d8fec/attachment.htm From latifer at streamgrid.net Fri Jun 24 10:07:47 2011 From: latifer at streamgrid.net (Latif Khalifa) Date: Fri, 24 Jun 2011 19:07:47 +0200 Subject: [opensource-dev] Highlight Transparent Broken? In-Reply-To: <4E040FD1.1040608@gmail.com> References: <4E02D1C3.1040906@gmail.com> <4E040FD1.1040608@gmail.com> Message-ID: Transparency was broken for me when Fast Alpha was enabled somewhere in the debug menus. I don't know where the current location of that setting is. On Fri, Jun 24, 2011 at 6:17 AM, holydoughnuts wrote: > On 6/23/2011 5:31 AM, Jonathan Welch wrote: >> Could you also check glow (cts-644/cts-656) and windlight clouds >> (storm-1314) to see if either of those are non-functional for you? ?I >> have a feeling that some of these are related to each other. > Those are OK here. I have to disable them to make Ctrl-Alt-T work but > otherwise they're fine. > _______________________________________________ > 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 jhwelch at gmail.com Fri Jun 24 15:35:49 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 24 Jun 2011 18:35:49 -0400 Subject: [opensource-dev] Highlight Transparent Broken? In-Reply-To: References: <4E02D1C3.1040906@gmail.com> <4E040FD1.1040608@gmail.com> Message-ID: If no one files a jira on highlight transparent malfunctioning it won't be fixed. Would someone take care of this? From lee.ponzu at gmail.com Fri Jun 24 15:56:56 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Fri, 24 Jun 2011 18:56:56 -0400 Subject: [opensource-dev] Highlight Transparent Broken? In-Reply-To: References: <4E02D1C3.1040906@gmail.com> <4E040FD1.1040608@gmail.com> Message-ID: Will do. On Fri, Jun 24, 2011 at 6:35 PM, Jonathan Welch wrote: > If no one files a jira on highlight transparent malfunctioning it > won't be fixed. Would someone take care of this? > _______________________________________________ > 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/20110624/1fef05cb/attachment.htm From lee.ponzu at gmail.com Fri Jun 24 16:03:29 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Fri, 24 Jun 2011 19:03:29 -0400 Subject: [opensource-dev] Highlight Transparent Broken? In-Reply-To: References: <4E02D1C3.1040906@gmail.com> <4E040FD1.1040608@gmail.com> Message-ID: Or maybe not. I just tested them so that I could write a good Jira, and both worked )on my 3 year old iMac. Second Life 2.7.4 (232938) Jun 15 2011 12:44:34 (Second Life Development) Release Notes You are at 306321.0, 233077.0, 44.0 in Hitaki located at sim9595.agni.lindenlab.com (216.82.44.52:12035) Second Life Server 11.06.14.232746 Release Notes CPU: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (2400 MHz) Memory: 3072 MB OS Version: Mac OS X 10.6.7 Darwin 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 Graphics Card Vendor: ATI Technologies Inc. Graphics Card: ATI Radeon HD 2600 PRO OpenGL Engine OpenGL Version: 2.1 ATI-1.6.26 libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1 J2C Decoder Version: KDU v6.4.1 Audio Driver Version: FMOD version 3.750000 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Vivox 3.2.0002.9361 Built with GCC version 40001 Packets Lost: 12/15577 (0.1%) On Fri, Jun 24, 2011 at 6:56 PM, Lee ponzu wrote: > Will do. > > > On Fri, Jun 24, 2011 at 6:35 PM, Jonathan Welch wrote: > >> If no one files a jira on highlight transparent malfunctioning it >> won't be fixed. Would someone take care of this? >> _______________________________________________ >> 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/20110624/c02fb91d/attachment.htm From lee.ponzu at gmail.com Fri Jun 24 16:11:08 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Fri, 24 Jun 2011 19:11:08 -0400 Subject: [opensource-dev] Highlight Transparent Broken? In-Reply-To: References: <4E02D1C3.1040906@gmail.com> <4E040FD1.1040608@gmail.com> Message-ID: OK. I created a really unsatisfactory Jira... - Second Life Viewer - VWR - VWR-26115 On Fri, Jun 24, 2011 at 6:35 PM, Jonathan Welch wrote: > If no one files a jira on highlight transparent malfunctioning it > won't be fixed. Would someone take care of this? > _______________________________________________ > 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/20110624/1626bec8/attachment.htm From nexiim at gmail.com Fri Jun 24 22:37:12 2011 From: nexiim at gmail.com (Nexii Malthus) Date: Sat, 25 Jun 2011 06:37:12 +0100 Subject: [opensource-dev] A question/comment about the behavior of auto-pilot camera. In-Reply-To: References: Message-ID: I agree with this. Stealing the users' camera leaves the user with a sense that they feel they lost control -- which is very bad for interaction. This goes for pretty much everywhere that involves stealing the users' camera where the user didn't intend to do so. (ugh, here comes bad memories of edit appearance) - Nexii On Fri, Jun 24, 2011 at 4:08 PM, Lee ponzu wrote: > I use auto-pilot a lot, because for me arrow keys to move are > problematic. I find it convenient to double-click on a spot, and then not > have to worry until I get there. > > If the camera is in its default state, then the camera moves along > following my head. This is fine. However, if I alt-click on some point off > to the side, and then double click to auto-pilot, the camera focus moves > along with my avatar. I think it would be better (for me) if the alt-click > point was more sticky, so the camera stayed focused on it while my avatar > does it's auto-pilot. > > Does that make sense to people? Maybe it would make auto-pilot more > popular. > > Anyway, just babbling. Thanks for listening. > > Ponzu > > _______________________________________________ > 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/20110625/ece5f9f0/attachment.htm From jaeger_Reg at hotmail.com Sat Jun 25 08:30:11 2011 From: jaeger_Reg at hotmail.com (jaeger_Reg at hotmail.com) Date: Sat, 25 Jun 2011 15:30:11 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110624114537.19652.67354@domU-12-31-38-00-90-68.compute-1.internal> References: <20110624114537.19652.67354@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110625153011.24975.86071@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/333/#review819 ----------------------------------------------------------- When I applied this latest patch to firestorm, which is based off of LL 2.5.2, I kept getting timed out when TPing from a mainland area and a DD of 256 to other regions. I tried multiple times TPing from the area around help island public to magnum sandbox 4 or to help people island. In every case I timed and was logged off after the TP was completed, as the viewer was cleaning up and closing connections to the old regions. I don't have this problem with the first iteration of this patch. I feel this scenario needs to be tested with this latest patch on v-dev tip to make sure this doesn't happen there as well. The account I used only has 4 friends, and around 24 items in the inventory in addition to the library. It also only has 2 attachments (a hud and the firestorm bridge) and is one of the noob outfits. I also am running on an i7 2600k, 16GB ram, ATI 6970, and 20/5mbit FIOS connection. - tankmaster.finesmith On June 24, 2011, 4:45 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 24, 2011, 4:45 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt 04e2a3ddca51 > indra/newview/llviewerregion.h 04e2a3ddca51 > indra/newview/llviewerregion.cpp 04e2a3ddca51 > indra/newview/llvoicevivox.h 04e2a3ddca51 > indra/newview/llvoicevivox.cpp 04e2a3ddca51 > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110625/eb13c1e8/attachment-0001.htm From lee.ponzu at gmail.com Sat Jun 25 08:58:20 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Sat, 25 Jun 2011 11:58:20 -0400 Subject: [opensource-dev] A question/comment about the behavior of auto-pilot camera. In-Reply-To: References: Message-ID: I looked through some JIRAs. Apparently there are also interactions of double-click with HUDs, and some other issues. Just thinking out loud... Maybe we need to think through a more general solution. It occurs to me that llRayCast() is going to make it easier to create scripted route/path finders using simple AI. Some possible useful behaviors... - Go here. - Go here and sit. - Go wherever this avatar goes. - Exactly trace the footsteps of this avatar. - Try to stay just to the left of this avatar. - Try to stay just to the right of this avatar. - Try to get in front of and face this avatar. Five years ago, I expected a lot more of this type of puppeteering to be added to SL, but it never happened. Maybe the perfect chased away the good. It should be obvious and built-in to shake hands, hold hands, hug, slap, pat-on-head, peck-on-cheek, put-arm-around, etc etc etc. Of course, this is a massive project involving server and VWR and lots of other invisible parts I don't even know about, and it cannot all be done at once. Like I said...just thinking out loud. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110625/c77365d6/attachment.htm From sllists at boroon.dasgupta.ch Sat Jun 25 11:40:11 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 25 Jun 2011 20:40:11 +0200 Subject: [opensource-dev] A question/comment about the behavior of auto-pilot camera. In-Reply-To: References: Message-ID: <4E062B8B.2020306@boroon.dasgupta.ch> On 06/25/2011 05:58 PM, Lee ponzu wrote: > # Go wherever this avatar goes. A long time back, the viewer had a 'Follow' option in the context menu on other avatars. If I remember correctly, it was removed due to abuse considerations. (Which I could never quite follow (sic), as this merely facilitated something for everyone that a skilled human keyboard or joystick-navigator could do manually anyway.) That feature was quite useful when showing SL to a friend who had just signed up and wasn't used to its navigation, yet. Having them follow you as you showed them around much more natural than teleporting everywhere, even for short distances. (Which might not have been possible back then, anyway. I don't remember whether this was before or after point-to-point teleports were introduced.) Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110625/7b25a28f/attachment.htm From jamey at beau.org Sat Jun 25 11:57:13 2011 From: jamey at beau.org (Jamey Fletcher) Date: Sat, 25 Jun 2011 13:57:13 -0500 Subject: [opensource-dev] A question/comment about the behavior of auto-pilot camera. In-Reply-To: <4E062B8B.2020306@boroon.dasgupta.ch> References: <4E062B8B.2020306@boroon.dasgupta.ch> Message-ID: <4E062F89.2000506@beau.org> Boroondas Gupte wrote: > On 06/25/2011 05:58 PM, Lee ponzu wrote: >> # Go wherever this avatar goes. > A long time back, the viewer had a 'Follow' option in the context menu > on other avatars. If I remember correctly, it was removed due to abuse > considerations. (Which I could never quite follow (sic), as this merely > facilitated something for everyone that a skilled human keyboard or > joystick-navigator could do manually anyway.) > That feature was quite useful when showing SL to a friend who had just > signed up and wasn't used to its navigation, yet. Having them follow you > as you showed them around much more natural than teleporting everywhere, > even for short distances. (Which might not have been possible back then, > anyway. I don't remember whether this was before or after point-to-point > teleports were introduced.) The follow feature would allow someone to set their AV following another, and then chat-spam the hell out of them. As it stands, it's nearly impossible to keep moving while chatting to someone. Of course, it would be nearly nothing to build a vehicle that would do it, or to modify a client to do it... From adeonwriter at live.com Sat Jun 25 17:08:09 2011 From: adeonwriter at live.com (Adeon Writer) Date: Sat, 25 Jun 2011 20:08:09 -0400 Subject: [opensource-dev] Adding Neck and Root Attachment Points Message-ID: In the interest of seeing how feasible adding "mNeck" and "mRoot" attachment points to the official LL viewer would be, it turns out that it's as simple as adding the joint names to the avatar_lad.xml file. It's been known for a while that modifying the file can give you more attachment points (for you and others with the same mod only), but the what I didn't know is adding entries for mNeck and mRoot will give the viewer fully functioning Neck and Root attachments, which are the two bones which previously had no attachment slots. Nyx Linden has expressed off the record that he will see a Neck attachment added to the viewer if a patch is submitted, which I'd assume would include the XML change, and updates to the menus. I was told I should bring this up on the list in hopes to give it some attention. I think it's possibly a rather easy thing to add, although it's beyond my own ability. https://jira.secondlife.com/browse/VWR-26120 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110625/a9957ac6/attachment.htm From trilobyte550m at gmail.com Sat Jun 25 18:10:18 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Sat, 25 Jun 2011 18:10:18 -0700 Subject: [opensource-dev] Adding Neck and Root Attachment Points In-Reply-To: References: Message-ID: Haven't we had the ability to put multiple attachments on any given attachment point for nearly a year now? I think there's a max per avatar (32), but once you've got an attachment on a particular point, select the next one you want to add and choose either Add or Add To from the context menu. On Jun 25, 2011, at 5:08 PM, Adeon Writer wrote: > In the interest of seeing how feasible adding "mNeck" and "mRoot" attachment points to the official LL viewer would be, it turns out that it's as simple as adding the joint names to the avatar_lad.xml file. > > It's been known for a while that modifying the file can give you more attachment points (for you and others with the same mod only), but the what I didn't know is adding entries for mNeck and mRoot will give the viewer fully functioning Neck and Root attachments, which are the two bones which previously had no attachment slots. > > Nyx Linden has expressed off the record that he will see a Neck attachment added to the viewer if a patch is submitted, which I'd assume would include the XML change, and updates to the menus. > > I was told I should bring this up on the list in hopes to give it some attention. I think it's possibly a rather easy thing to add, although it's beyond my own ability. > > https://jira.secondlife.com/browse/VWR-26120 > _______________________________________________ > 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/20110625/864bbb80/attachment.htm From adeonwriter at live.com Sat Jun 25 18:30:00 2011 From: adeonwriter at live.com (Adeon Writer) Date: Sat, 25 Jun 2011 21:30:00 -0400 Subject: [opensource-dev] Adding Neck and Root Attachment Points In-Reply-To: References: , Message-ID: Yes, although the catch here is that there simply isn't a Neck slot or a Root slot, so the fact that we can attach multiple objects to any given slot is irrelevant; those two slots have yet to be created. Neck and Root here are unique locations that aren't simply a duplicate slot of something we have now. > Haven't we had the ability to put multiple attachments on any given attachment point for nearly a year now? I think there's a max per avatar (32), but once you've got an attachment on a particular point, select the next one you want to add and choose either Add or Add To from the context menu. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110625/4ca93936/attachment.htm From trilobyte550m at gmail.com Sat Jun 25 18:36:01 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Sat, 25 Jun 2011 18:36:01 -0700 Subject: [opensource-dev] Adding Neck and Root Attachment Points In-Reply-To: References: , Message-ID: <761B52E2-DCB9-4E4F-A1A9-62FC3AE2048F@web-pass.com> True, though the neck is in a fixed location in relation to the chest and spine. Adding neck-worn items has worked pretty consistently well using those points. On Jun 25, 2011, at 6:30 PM, Adeon Writer wrote: > Yes, although the catch here is that there simply isn't a Neck slot or a Root slot, so the fact that we can attach multiple objects to any given slot is irrelevant; those two slots have yet to be created. Neck and Root here are unique locations that aren't simply a duplicate slot of something we have now. > > > Haven't we had the ability to put multiple attachments on any given attachment point for nearly a year now? I think there's a max per avatar (32), but once you've got an attachment on a particular point, select the next one you want to add and choose either Add or Add To from the context menu. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110625/5765097a/attachment.htm From adeonwriter at live.com Sat Jun 25 18:43:46 2011 From: adeonwriter at live.com (Adeon Writer) Date: Sat, 25 Jun 2011 21:43:46 -0400 Subject: [opensource-dev] Adding Neck and Root Attachment Points In-Reply-To: <761B52E2-DCB9-4E4F-A1A9-62FC3AE2048F@web-pass.com> References: , , , , <761B52E2-DCB9-4E4F-A1A9-62FC3AE2048F@web-pass.com> Message-ID: That's a very common belief, and possibly why the neck attachment has been missing for so long. But it's not the case: The neck is it's own bone as is the "root" bone; as anyone who has created an SL animation can tell you. :)Here's a youtube video to explain my case: It shows the new Neck and Root attachments being used, after I added this snipit of code: http://www.youtube.com/watch?v=Off7WNlfS3s This is not something that is possibly simply by using an attachment we already have, they are the missing bones. https://jira.secondlife.com/browse/VWR-26120 > True, though the neck is in a fixed location in relation to the chest and spine. Adding neck-worn items has worked pretty consistently well using those points. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110625/3a11b215/attachment.htm From ilana.debevec at gmail.com Sat Jun 25 19:13:35 2011 From: ilana.debevec at gmail.com (Ilana Debevec) Date: Sat, 25 Jun 2011 20:13:35 -0600 Subject: [opensource-dev] Adding Neck and Root Attachment Points In-Reply-To: References: <761B52E2-DCB9-4E4F-A1A9-62FC3AE2048F@web-pass.com> Message-ID: Absolutely, Positively. YES! As in yesterday. That video says it all. A long needed addition. On Sat, Jun 25, 2011 at 7:43 PM, Adeon Writer wrote: > That's a very common belief, and possibly why the neck attachment has > been missing for so long. But it's not the case: The neck is it's own bone > as is the "root" bone; as anyone who has created an SL animation can tell > you. :) > Here's a youtube video to explain my case: It shows the new Neck and Root > attachments being used, after I added this snipit of code: > > http://www.youtube.com/watch?v=Off7WNlfS3s > > id="39" > group="9" > pie_slice="1" > name="Neck" > joint="mNeck" > position="0 0 0" > rotation="0 0 0" > visible_in_first_person="true" /> > > id="40" > group="9" > pie_slice="2" > name="Bounding Box" > joint="mRoot" > position="0 0 0" > rotation="0 0 0" > visible_in_first_person="true" /> > > This is not something that is possibly simply by using an attachment we > already have, they are the missing bones. > > https://jira.secondlife.com/browse/VWR-26120 > > > True, though the neck is in a fixed location in relation to the chest and > spine. Adding neck-worn items has worked pretty consistently well using > those points. > > _______________________________________________ > 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/20110625/9b4f2f8f/attachment-0001.htm From secret.argent at gmail.com Sat Jun 25 19:30:45 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 25 Jun 2011 21:30:45 -0500 Subject: [opensource-dev] A question/comment about the behavior of auto-pilot camera. In-Reply-To: References: Message-ID: On 2011-06-25, at 10:58, Lee ponzu wrote: > Maybe we need to think through a more general solution. It occurs to me that llRayCast() is going to make it easier to create scripted route/path finders using simple AI. Some possible useful behaviors... > > ? Go here. > ? Go here and sit. > ? Go wherever this avatar goes. > ? Exactly trace the footsteps of this avatar. > ? Try to stay just to the left of this avatar. > ? Try to stay just to the right of this avatar. > ? Try to get in front of and face this avatar. And the one I most want... follow these waypoints (here, and here, and HERE, and here...) From secret.argent at gmail.com Sat Jun 25 19:32:22 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 25 Jun 2011 21:32:22 -0500 Subject: [opensource-dev] Adding Neck and Root Attachment Points In-Reply-To: References: <761B52E2-DCB9-4E4F-A1A9-62FC3AE2048F@web-pass.com> Message-ID: <5A2B7A77-C709-4ED5-A477-B42C2C442DF9@gmail.com> Me Too From adeonwriter at live.com Sun Jun 26 08:14:06 2011 From: adeonwriter at live.com (Adeon Writer) Date: Sun, 26 Jun 2011 11:14:06 -0400 Subject: [opensource-dev] Adding Neck and Root Attachment Points In-Reply-To: <5A2B7A77-C709-4ED5-A477-B42C2C442DF9@gmail.com> References: , , , <761B52E2-DCB9-4E4F-A1A9-62FC3AE2048F@web-pass.com>, , , <5A2B7A77-C709-4ED5-A477-B42C2C442DF9@gmail.com> Message-ID: You get this string when right clicking an object in your inventory, and choosing "Attach To" the new attachments added to the XML show up at the bottom of the list (They're actually sorted by ID number, I believe) as "MissingString(Name)" There are a few places the new attachments will need to appear in menus, and verified the strings are coming in:-In the the "Attach To" sub-menu when right clicking an inventory object-In the "Take Off" sub-menu when right clicking your own avatar mesh-In the "Attach" sub-menu when right clicking an in-world rezzed object-New checkboxes are needed when making a V2 outfit. > When you write in the jira that "these missing strings comes in> as...." -- where or how do you get that message? I could change the> code if only I knew where to look. >> Functionality wise, an XML addition is all that's needed, although the >> viewer would need some strings added or they come up as MissingString on >> some of the menus, and I think those are hardcoded. Maybe. (There's also >> the LSL back end needing some new constant names if scripts are to be able >> to use them properly, but I'd assume that would be on Nyx Linden's end.)>> Should I go and add it? (If so, how) >>> Add this to the agenda for the next Viewer Evolution meeting. If all>>> it takes is a change to the xml file and there are no repercussions>>> from doing so it should be taken in. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110626/aa9d7052/attachment.htm From adeonwriter at live.com Sun Jun 26 08:31:25 2011 From: adeonwriter at live.com (Adeon Writer) Date: Sun, 26 Jun 2011 11:31:25 -0400 Subject: [opensource-dev] Adding Neck and Root Attachment Points In-Reply-To: References: , , , <761B52E2-DCB9-4E4F-A1A9-62FC3AE2048F@web-pass.com>, , , <5A2B7A77-C709-4ED5-A477-B42C2C442DF9@gmail.com>, , Message-ID: The official name for the joint is "mRoot" so I suppose "Root" is the most logical thing to name it.And yes, it should auto-fill in the menus, if "id" and "pie_slice" have the correct values. I'm not sure how they work. The ones I provided certainly aren't correct.Additionally, the position and rotation offsets... I left at zero. The real attachments use a bit of offset for position, so small objects don't appear inside the avatar when first worn. > I have altered the xml file you wrote about and added 2 entries to > strings.xml and am compiling a viewer to test this. > > Can you think of a more descriptive name than "Bounding Box"? A > regular user would not know what that means. > > I'll be back later today to test these changes (hopefully the menus > auto-update from the xml file). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110626/2199f5c3/attachment.htm From twisted_laws at hotmail.com Sun Jun 26 08:32:48 2011 From: twisted_laws at hotmail.com (Twisted Laws) Date: Sun, 26 Jun 2011 15:32:48 -0000 Subject: [opensource-dev] Review Request: STORM-1103 Nearby sidebar minimap should be optional In-Reply-To: <20110514200727.22601.61704@domU-12-31-38-00-90-68.compute-1.internal> References: <20110514200727.22601.61704@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110626153248.22030.40516@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/265/ ----------------------------------------------------------- (Updated June 26, 2011, 8:32 a.m.) Review request for Viewer. Changes ------- Corrects an issue identified in JIRA STORM-1103 where it is possible to make it so the map can no longer be displayed. Quoted from JIRA 1. Open Nearby Panel 2. Decrease viewer window height until mini-map disappears automatically 3. Disable mini-map in the gear menu 4. Maximize viewer window height 5. Enable minim-map via gear menu Actual Results Minimap isn't displayed without this patch. With this patch, the Minimap is still displayable. Summary ------- Patch makes the map in the Nearby people tab optional with a menu option in the gear menu. Patch is XML only and resizing of the map is disabled (user_resize="false" in the layout_panels) as I could not find a way to easily save window sizes purely in XML. Patch is in the repository of https://bitbucket.org/Twisted_Laws/viewer-development-storm-1103 as https://bitbucket.org/Twisted_Laws/viewer-development-storm-1103/changeset/3455e79a14af and https://bitbucket.org/Twisted_Laws/viewer-development-storm-1103/changeset/48b66643a4d1 This addresses bug STORM-1103. http://jira.secondlife.com/browse/STORM-1103 Diffs (updated) ----- indra/newview/skins/default/xui/en/panel_people.xml 48b66643a4d1 Diff: http://codereview.secondlife.com/r/265/diff Testing ------- Tested by exercising the gear menu option of "View Map" with the People tab attached and detached insuring the map appears and disappears properly. Thanks, Twisted -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110626/af1552ec/attachment.htm From adeonwriter at live.com Sun Jun 26 08:38:38 2011 From: adeonwriter at live.com (Adeon Writer) Date: Sun, 26 Jun 2011 11:38:38 -0400 Subject: [opensource-dev] Adding Neck and Root Attachment Points In-Reply-To: References: , , , <761B52E2-DCB9-4E4F-A1A9-62FC3AE2048F@web-pass.com>, , , <5A2B7A77-C709-4ED5-A477-B42C2C442DF9@gmail.com>, , , , Message-ID: Perhaps; although the thing with the mRoot joint is that it never moves in relation to the avatar, so it won't actually be positioned on the center of their body. (People will use it for worn vehicles, props, dance poles) But if that's not to confusing, I say go with it. > For non-technical people would "Body Center" make sense? Root makes > it sound like a plant. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110626/f9b6f6fa/attachment.htm From adeonwriter at live.com Sun Jun 26 08:43:58 2011 From: adeonwriter at live.com (Adeon Writer) Date: Sun, 26 Jun 2011 11:43:58 -0400 Subject: [opensource-dev] Adding Neck and Root Attachment Points In-Reply-To: References: , , , , , , <761B52E2-DCB9-4E4F-A1A9-62FC3AE2048F@web-pass.com>, , , , , , <5A2B7A77-C709-4ED5-A477-B42C2C442DF9@gmail.com>, , , , , , , , , Message-ID: Well, there it is. Maybe it should be called Prop. But whatever works. Name is an afterthought to function. :) > Perhaps; although the thing with the mRoot joint is that it never moves in relation to the avatar, so it won't actually be positioned on the center of their body. (People will use it for worn vehicles, props, dance poles)> But if that's not to confusing, I say go with it.>>> For non-technical people would "Body Center" make sense? Root makes>> it sound like a plant. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110626/c7bb9dd3/attachment-0001.htm From lee.ponzu at gmail.com Sun Jun 26 10:03:27 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Sun, 26 Jun 2011 13:03:27 -0400 Subject: [opensource-dev] Adding Neck and Root Attachment Points In-Reply-To: References: <761B52E2-DCB9-4E4F-A1A9-62FC3AE2048F@web-pass.com> <5A2B7A77-C709-4ED5-A477-B42C2C442DF9@gmail.com> Message-ID: On Sun, Jun 26, 2011 at 11:43 AM, Adeon Writer wrote: > \Name is an afterthought to function. :) > > > Don't call it irving. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110626/b7a7dbd6/attachment.htm From oz at lindenlab.com Sun Jun 26 15:11:20 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sun, 26 Jun 2011 18:11:20 -0400 Subject: [opensource-dev] Snowstorm PO review build Message-ID: <4E07AE88.90402@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110626/d99d7e4f/attachment.htm From twisted_laws at hotmail.com Sun Jun 26 20:12:44 2011 From: twisted_laws at hotmail.com (Twisted Laws) Date: Sun, 26 Jun 2011 23:12:44 -0400 Subject: [opensource-dev] Snowstorm PO review build In-Reply-To: <4E07AE88.90402@lindenlab.com> References: <4E07AE88.90402@lindenlab.com> Message-ID: fails STORM-64, STORM-787 , STORM-1396 , VWR-25062 passes STORM-323, STORM-1103, STORM-1334, STORM-1392, STORM-1393, comments intermixed EXP-825 - untested [#STORM-1439] [crashhunters] crash in LLToolPie::handleMouseUp STORM-64 - couldn?t figure out how to invoke this As a Builder, I want the ability to use temporary images, animations, etc. and preview them inworld before uploading them STORM-323 - good redundant popups STORM-787 - setting not displayed in preferences media Mute Gestures Button STORM-1103 ? good, works as expected Nearby sidebar minimap should be optional STORM-1292 - untested [UNTRANSLATABLE XUI ATTRIBUTE] "Mi apariencia" tab in side menu bar > "MIS VESTUARIOS". You don't have any outfits yet. Try Search. (ALL LANGS) STORM-1302 ? untested (all langs) [TRANSLATED BUT IN ENG] (Spanish) Side Menu > Gente tab > MIS AMIGOS tab > buttons "Call", "Share" and "Teleport" and their tooltips STORM-1326 ? untested [ALL LANGS] (Spanish) [HARDCODED] Selling land, advice with "Anyone" in English. STORM-1334 ? good Console debug data scrolls away too quickly and is hard to read STORM-1352 ? untested [crashhunters] crash in LLNearbyChatScreenChannel::showToastsBottom() STORM-1372 ? untested [crashhunters] crash at [1] LLTemplateMessageBuilder::nextBlock(char const *) [secondlife-bin lltemplatemessagebuilder.cpp] STORM-1392 ? good Add Nearby Voice to the Communicate menu STORM-1393 ? good Missing Object/Prim count in Second Life 2.7.4 (233201) Jun 17 2011 21:33:05 (Second Life Development) STORM-1396 ? untested (no setting in preferences media) Storm-787 (mute gestures) also mutes sounds from objects VWR-24099 - untested [#STORM-1372] [crashhunters] crash at [1] LLTemplateMessageBuilder::nextBlock(char const *) [secondlife-bin lltemplatemessagebuilder.cpp] VWR-25062 ? the preferences media panel is empty below Allow Media to auto-play and Enable media filter checkboxes, losing Play media attached to other avatars, Play sounds from gestures, Voice Chat Settings and Input/output devices. [#STORM-1346] Add the ability to allow or deny domains that parcel owners want to play in the viewer's media and audio players VWR-25480 ? untested [#STORM-1350] Worldmap: Partial region name search UI bug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110626/f55d2e22/attachment.htm From angel_of_crimson at hotmail.com Mon Jun 27 09:29:35 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 27 Jun 2011 12:29:35 -0400 Subject: [opensource-dev] Snowstorm PO review build In-Reply-To: <4E07AE88.90402@lindenlab.com> References: <4E07AE88.90402@lindenlab.com> Message-ID: EXP-825 unable to test STORM-64 FAIL: preview window doesn't properly give preview options. Unable to find workaround. STORM-323 so far so good. STORM-787 untested (can someone point me to where the button is?) STORM-1103 well done STORM-1292 untested STORM-1302 untested STORM-1326 untested STORM-1334 untested STORM-1352 unable to test STORM-1372 unable to test STORM-1392 works! STORM-1393 seems fixed STORM-1396 untested VWR-24099 untested VWR-25062 Fail: the feature seems to work but allot of the sounds/media panel is missing including the white and black list buttons for the media filter. VWR-25480 seems fixed _______________________________________________ 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/20110627/e3c36d61/attachment.htm From armin.weatherwax at googlemail.com Mon Jun 27 15:01:49 2011 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Tue, 28 Jun 2011 00:01:49 +0200 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110625153011.24975.86071@domU-12-31-38-00-90-68.compute-1.internal> References: <20110624114537.19652.67354@domU-12-31-38-00-90-68.compute-1.internal> <20110625153011.24975.86071@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <201106280001.49739.Armin.Weatherwax@gmail.com> I agree very much about extensive testing of changes in key-functionality like voice. Lots of teleporting is the right thing to do for this patch (see the jira for more a more detailed list of things that I think need to be adressed). About Inventory failures and being disconnected from the sim, just to repeat here what we already where talking about in irc: neither iteration of the patch does anything inventory or disconnecting from the sim. To check the "you never know" factor I tried the build from a) my viewer-development branch with patch iteration 2 applied and b) Imprudence 1.3.2 with neither of both iterations applied. I got 1 time disconnected with a) , 2 times almost and 1 time disconnected with b). That all looks very much like a simulator - or network issue close to the sim to me. However good to address that, too, since for proper testing one needs to be able to make a distinction if a patch is causing a failure or the current state of the service. Armin jaeger_Reg at hotmail.com wrote: > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/#review819 > ----------------------------------------------------------- > > > When I applied this latest patch to firestorm, which is based off of > LL 2.5.2, I kept getting timed out when TPing from a mainland area > and a DD of 256 to other regions. I tried multiple times TPing from > the area around help island public to magnum sandbox 4 or to help > people island. In every case I timed and was logged off after the TP > was completed, as the viewer was cleaning up and closing connections > to the old regions. I don't have this problem with the first > iteration of this patch. I feel this scenario needs to be tested > with this latest patch on v-dev tip to make sure this doesn't happen > there as well. > > The account I used only has 4 friends, and around 24 items in the > inventory in addition to the library. It also only has 2 attachments > (a hud and the firestorm bridge) and is one of the noob outfits. I > also am running on an i7 2600k, 16GB ram, ATI 6970, and 20/5mbit FIOS > connection. > > - tankmaster.finesmith > > On June 24, 2011, 4:45 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://codereview.secondlife.com/r/333/ > > ----------------------------------------------------------- > > > > (Updated June 24, 2011, 4:45 a.m.) > > > > > > Review request for Viewer. > > > > > > Summary > > ------- > > > > This is a patch by ArminWeatherHax. I am creating the request to > > help speed this fix along in the system. > > > > ---- > > > > Ways to reproduce: log into a simulator. > > Reproduces: always > > Affects: any version supported, probably all 3rd party viewers but > > Kokua (and Imprudence, soon). > > > > What happens: > > In each idle cycle the voice client requests the > > "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > > See LLVivoxVoiceClient::stateMachine() after comment // Check for > > parcel boundary crossing > > > > Expected: > > On parcel/region change request the capability once. It's not the > > region that rezzes in, but the avatar, so do the request for the > > capability not earlier than the agents region signals > > capabilitiesReceived() true. After that you are sure if the region > > returns an empty url you can give up for that region. > > > > Not sure about the impact on lag - requesting and returning an url > > is not much data transmitted, though its a pretty big number of > > people doing it over and over per second (no matter if they have > > voice on or off). > > > > > > ---- > > > > going once again through llviewerregion I see its fortunately not > > each time a HTTP GET, just once when the agent connects to the > > region. Though the patch still saves all the lookup if the cap is > > there while it can't be possibly. > > > > > > This addresses bug VWR-25923. > > http://jira.secondlife.com/browse/VWR-25923 > > > > > > Diffs > > ----- > > > > doc/contributions.txt 04e2a3ddca51 > > indra/newview/llviewerregion.h 04e2a3ddca51 > > indra/newview/llviewerregion.cpp 04e2a3ddca51 > > indra/newview/llvoicevivox.h 04e2a3ddca51 > > indra/newview/llvoicevivox.cpp 04e2a3ddca51 > > > > Diff: http://codereview.secondlife.com/r/333/diff > > > > > > Testing > > ------- > > > > > > Thanks, > > > > Jonathan From kadah.coba at gmail.com Mon Jun 27 18:44:02 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Tue, 28 Jun 2011 01:44:02 -0000 Subject: [opensource-dev] Review Request: VWR-21522: Prevent unintended 10L sale Message-ID: <20110628014402.22033.2057@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/365/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This change makes it so setting an object for sale or modifying the price or sale type requires explicitly applying the changes. Default behavior before this patch is all sale info is committed to sim on change. After this patch the sale info will only get set or modified after hitting a "mark for sale" button. There is no change to removing an object from sale, unchecking "For sale" will be committed to sim without further user interation. https://bitbucket.org/Kadah_Coba/vwr-21522 Main Patch: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/45df3e1e9f6f German translation: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/01dc58391588 This addresses bug VWR-21522. http://jira.secondlife.com/browse/VWR-21522 Diffs ----- indra/newview/llpanelpermissions.h b245a988d038 indra/newview/llpanelpermissions.cpp b245a988d038 indra/newview/skins/default/xui/en/floater_tools.xml b245a988d038 Diff: http://codereview.secondlife.com/r/365/diff Testing ------- (I had stuff here but Review Board kept deleting it every time I tried to save.) Thanks, Kadah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110628/cd146ca9/attachment.htm From vsavchuk at productengine.com Tue Jun 28 06:26:59 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 28 Jun 2011 13:26:59 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110625153011.24975.86071@domU-12-31-38-00-90-68.compute-1.internal> References: <20110625153011.24975.86071@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110628132659.22032.32458@domU-12-31-38-00-90-68.compute-1.internal> > On June 25, 2011, 8:30 a.m., Tankmaster Finesmith wrote: > > When I applied this latest patch to firestorm, which is based off of LL 2.5.2, I kept getting timed out when TPing from a mainland area and a DD of 256 to other regions. I tried multiple times TPing from the area around help island public to magnum sandbox 4 or to help people island. In every case I timed and was logged off after the TP was completed, as the viewer was cleaning up and closing connections to the old regions. I don't have this problem with the first iteration of this patch. I feel this scenario needs to be tested with this latest patch on v-dev tip to make sure this doesn't happen there as well. > > > > The account I used only has 4 friends, and around 24 items in the inventory in addition to the library. It also only has 2 attachments (a hud and the firestorm bridge) and is one of the noob outfits. I also am running on an i7 2600k, 16GB ram, ATI 6970, and 20/5mbit FIOS connection. Could you please provide exact steps to reproduce the issue? Have you tried reverting the patch and repeating the teleport attempt? - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/333/#review819 ----------------------------------------------------------- On June 24, 2011, 4:45 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 24, 2011, 4:45 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt 04e2a3ddca51 > indra/newview/llviewerregion.h 04e2a3ddca51 > indra/newview/llviewerregion.cpp 04e2a3ddca51 > indra/newview/llvoicevivox.h 04e2a3ddca51 > indra/newview/llvoicevivox.cpp 04e2a3ddca51 > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110628/24902c45/attachment.htm From jaeger_Reg at hotmail.com Tue Jun 28 10:55:19 2011 From: jaeger_Reg at hotmail.com (Tankmaster Finesmith) Date: Tue, 28 Jun 2011 17:55:19 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110625153011.24975.86071@domU-12-31-38-00-90-68.compute-1.internal> References: <20110625153011.24975.86071@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110628175519.22026.68393@domU-12-31-38-00-90-68.compute-1.internal> > On June 25, 2011, 8:30 a.m., Tankmaster Finesmith wrote: > > When I applied this latest patch to firestorm, which is based off of LL 2.5.2, I kept getting timed out when TPing from a mainland area and a DD of 256 to other regions. I tried multiple times TPing from the area around help island public to magnum sandbox 4 or to help people island. In every case I timed and was logged off after the TP was completed, as the viewer was cleaning up and closing connections to the old regions. I don't have this problem with the first iteration of this patch. I feel this scenario needs to be tested with this latest patch on v-dev tip to make sure this doesn't happen there as well. > > > > The account I used only has 4 friends, and around 24 items in the inventory in addition to the library. It also only has 2 attachments (a hud and the firestorm bridge) and is one of the noob outfits. I also am running on an i7 2600k, 16GB ram, ATI 6970, and 20/5mbit FIOS connection. > > Vadim ProductEngine wrote: > Could you please provide exact steps to reproduce the issue? > Have you tried reverting the patch and repeating the teleport attempt? I TPed to Help Island Public, which is on maind land, while running from Visual Studio. Draw distance set to 256. Flew over orentation island and proceeded onto another neighboring sim. My viewer is now connected to several different regions do to normal viewer behavior. I then TP to magnum sandbox 4 by tyeping that into the nav bar up top and pressing enter. First tried with the first patch, which we have had for several weeks now in our repository: -TP was successful, then the viewer became rather unresponsive and the logs say things related to "(ip address) time out exceeded, disconnecting" but eventually recovers -repeated 3 times, last time I TPed to Help People Island instead and all times got the same result Second I tried with the updated patch: -TP was successful, then the viewer was completely unresponsive, and I eventually got the ding from getting logged off and in the loges I see a mass of "invalid packet from (IP address)" -repeated 3 times like and to the same regions (twice to magnum, once to HPI) every time I got logged off Third I reverted back to the first patch: Same experience as the first: -TP was successful, then the viewer became rather unresponsive and the logs say things related to "(ip address) time out exceeded, disconnecting" but eventually recovers -repeated 3 times, last time I TPed to HPI as I have in the other tests, and all times got the same result In talking with armin, he got similer results but thinks its the magnum sandbox region that may be having problems. I am not as sure on that as I get it when TPing to HPI as well which is release server channle and not a RC channle. - Tankmaster ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/333/#review819 ----------------------------------------------------------- On June 24, 2011, 4:45 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 24, 2011, 4:45 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt 04e2a3ddca51 > indra/newview/llviewerregion.h 04e2a3ddca51 > indra/newview/llviewerregion.cpp 04e2a3ddca51 > indra/newview/llvoicevivox.h 04e2a3ddca51 > indra/newview/llvoicevivox.cpp 04e2a3ddca51 > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110628/5d5c7310/attachment-0001.htm From kadah.coba at gmail.com Tue Jun 28 11:32:20 2011 From: kadah.coba at gmail.com (Kadah) Date: Tue, 28 Jun 2011 11:32:20 -0700 Subject: [opensource-dev] Snowstorm PO review build In-Reply-To: References: <4E07AE88.90402@lindenlab.com> Message-ID: <4E0A1E34.2090105@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 STORM-787 There is an unclosed (likely also truncated) check_box entry at panel_preferences_sound.xml at 346. This is preventing the rest of the panel from being displayed. Looks like a bad merge. On 6/26/2011 8:12 PM, Twisted Laws wrote: > STORM-787 - setting not > displayed in preferences media > Mute Gestures Button -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOCh40AAoJEIdLfPRu7qE2WJEIALN9FOKjlAsnjN2MZsndOJiZ WQdGynreisLaLTh9ztmwlQQNSOdlX8KNQFbHjmx4EU2L1E43n05QSD4pZR3fKK4Q MQJ0BaA7vvAOIG5oLMrEbZ1jiVBJnl+509WS1RldGVV6qP8gl0Uib8GN3oVTLbsQ q41Jk1tGLOgqHa1fvf7sO682uMsdzk7IwOlfzYYX5prjnZomCdrhcerLHXhR7gjV VqZ2wrjadwRutovvuW2bwZhHBEeS2O3uYVp0MA5Z5CAOWJkyy2dqX+sYPQ507R9C RWMu8N2FYFjm0ClJBClJkpvzAxFjv3mjpG/T1O/Ak1Vi+YStrkMh4v4SakXW2kU= =JTsF -----END PGP SIGNATURE----- From sythos at gmail.com Tue Jun 28 11:45:55 2011 From: sythos at gmail.com (Altair Sythos Memo) Date: Tue, 28 Jun 2011 20:45:55 +0200 Subject: [opensource-dev] Shader typo Message-ID: <20110628204555.7e755d92.sythos@gmail.com> SecondLife-i686-2.7.6.233972/app_settings/shaders/class2/deferred/sunlightSSAOMSF.glsl should be sunLightSSAOMSF.glsl renaming turn ON again shadows From oz at lindenlab.com Tue Jun 28 18:18:26 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 28 Jun 2011 21:18:26 -0400 Subject: [opensource-dev] Revised review build Message-ID: <4E0A7D62.3010805@lindenlab.com> This adds an issue or two, fixes a merge problem in the sound preferences panel that messed up a couple of the issues in the previous build, and omits some issues that have been approved and merged to viewer-development. http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_viewer-poreview/rev/234235/index.html EXP-825 [#STORM-1439] [crashhunters] crash in LLToolPie::handleMouseUp STORM-457 There is no space char after [AGENT_NAME] in 'conference-title-incoming' for Japanese language STORM-787 Mute Gestures Button STORM-1325 The viewer doesn't retry to upload baked textures if the initial upload failed STORM-1327 MULTIPLE LANGS (Spanish/German) [FORMATTING] Overlapped text in About Land Window when the land is for sell: "Los objetos se incluyen en la venta" STORM-1372 [crashhunters] crash at [1] LLTemplateMessageBuilder::nextBlock(char const *) [secondlife-bin lltemplatemessagebuilder.cpp] STORM-1392 Add Nearby Voice to the Communicate menu STORM-1396 Storm-787 (mute gestures) also mutes sounds from objects STORM-1406 [ENG LAYOUT] Viewer - Overlapping text in Input/Output devices preference STORM-1452 Debug settings -- TRUE/FALSE name (not label) translated in foreign languages VWR-21522 [#STORM-1453] Prevent unintended 10L sale VWR-24099 [#STORM-1372] [crashhunters] crash at [1] LLTemplateMessageBuilder::nextBlock(char const *) [secondlife-bin lltemplatemessagebuilder.cpp] VWR-25062 [#STORM-1346] Add the ability to allow or deny domains that parcel owners want to play in the viewer's media and audio players -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110628/0c501c0f/attachment.htm From vsavchuk at productengine.com Wed Jun 29 05:20:10 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Wed, 29 Jun 2011 12:20:10 -0000 Subject: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam In-Reply-To: <20110625153011.24975.86071@domU-12-31-38-00-90-68.compute-1.internal> References: <20110625153011.24975.86071@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110629122010.22928.8920@domU-12-31-38-00-90-68.compute-1.internal> > On June 25, 2011, 8:30 a.m., Tankmaster Finesmith wrote: > > When I applied this latest patch to firestorm, which is based off of LL 2.5.2, I kept getting timed out when TPing from a mainland area and a DD of 256 to other regions. I tried multiple times TPing from the area around help island public to magnum sandbox 4 or to help people island. In every case I timed and was logged off after the TP was completed, as the viewer was cleaning up and closing connections to the old regions. I don't have this problem with the first iteration of this patch. I feel this scenario needs to be tested with this latest patch on v-dev tip to make sure this doesn't happen there as well. > > > > The account I used only has 4 friends, and around 24 items in the inventory in addition to the library. It also only has 2 attachments (a hud and the firestorm bridge) and is one of the noob outfits. I also am running on an i7 2600k, 16GB ram, ATI 6970, and 20/5mbit FIOS connection. > > Vadim ProductEngine wrote: > Could you please provide exact steps to reproduce the issue? > Have you tried reverting the patch and repeating the teleport attempt? > > Tankmaster Finesmith wrote: > I TPed to Help Island Public, which is on maind land, while running from Visual Studio. Draw distance set to 256. Flew over orentation island and proceeded onto another neighboring sim. My viewer is now connected to several different regions do to normal viewer behavior. I then TP to magnum sandbox 4 by tyeping that into the nav bar up top and pressing enter. > > First tried with the first patch, which we have had for several weeks now in our repository: > -TP was successful, then the viewer became rather unresponsive and the logs say things related to "(ip address) time out exceeded, disconnecting" but eventually recovers > -repeated 3 times, last time I TPed to Help People Island instead and all times got the same result > > Second I tried with the updated patch: > -TP was successful, then the viewer was completely unresponsive, and I eventually got the ding from getting logged off and in the loges I see a mass of "invalid packet from (IP address)" > -repeated 3 times like and to the same regions (twice to magnum, once to HPI) every time I got logged off > > Third I reverted back to the first patch: > Same experience as the first: > -TP was successful, then the viewer became rather unresponsive and the logs say things related to "(ip address) time out exceeded, disconnecting" but eventually recovers > -repeated 3 times, last time I TPed to HPI as I have in the other tests, and all times got the same result > > > In talking with armin, he got similer results but thinks its the magnum sandbox region that may be having problems. I am not as sure on that as I get it when TPing to HPI as well which is release server channle and not a RC channle. Thanks, Tankmaster. I tend to think that these errors are not related to the patch. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/333/#review819 ----------------------------------------------------------- On June 24, 2011, 4:45 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/ > ----------------------------------------------------------- > > (Updated June 24, 2011, 4:45 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a patch by ArminWeatherHax. I am creating the request to help speed this fix along in the system. > > ---- > > Ways to reproduce: log into a simulator. > Reproduces: always > Affects: any version supported, probably all 3rd party viewers but Kokua (and Imprudence, soon). > > What happens: > In each idle cycle the voice client requests the "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > See LLVivoxVoiceClient::stateMachine() after comment // Check for parcel boundary crossing > > Expected: > On parcel/region change request the capability once. It's not the region that rezzes in, but the avatar, so do the request for the capability not earlier than the agents region signals capabilitiesReceived() true. After that you are sure if the region returns an empty url you can give up for that region. > > Not sure about the impact on lag - requesting and returning an url is not much data transmitted, though its a pretty big number of people doing it over and over per second (no matter if they have voice on or off). > > > ---- > > going once again through llviewerregion I see its fortunately not each time a HTTP GET, just once when the agent connects to the region. Though the patch still saves all the lookup if the cap is there while it can't be possibly. > > > This addresses bug VWR-25923. > http://jira.secondlife.com/browse/VWR-25923 > > > Diffs > ----- > > doc/contributions.txt 04e2a3ddca51 > indra/newview/llviewerregion.h 04e2a3ddca51 > indra/newview/llviewerregion.cpp 04e2a3ddca51 > indra/newview/llvoicevivox.h 04e2a3ddca51 > indra/newview/llvoicevivox.cpp 04e2a3ddca51 > > Diff: http://codereview.secondlife.com/r/333/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/09b0ae62/attachment.htm From vsavchuk at productengine.com Wed Jun 29 06:37:08 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Wed, 29 Jun 2011 13:37:08 -0000 Subject: [opensource-dev] Review Request: VWR-21522: Prevent unintended 10L sale In-Reply-To: <20110628014402.22033.2057@domU-12-31-38-00-90-68.compute-1.internal> References: <20110628014402.22033.2057@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110629133708.25892.40071@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/365/#review825 ----------------------------------------------------------- Looking good overall. Please fix the minor issues. indra/newview/llpanelpermissions.cpp What is the "KC" label for? indra/newview/llpanelpermissions.cpp Coding standard: rewrite as btn_mark_for_sale. indra/newview/llpanelpermissions.cpp ditto indra/newview/llpanelpermissions.cpp What does the comment mean? indra/newview/llpanelpermissions.cpp Please consider moving the duplicated code to a separate method like enableMarkForSale(bool enabled); indra/newview/llpanelpermissions.cpp Follow the CS when naming local variables. - Vadim On June 27, 2011, 6:44 p.m., Kadah Coba wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/365/ > ----------------------------------------------------------- > > (Updated June 27, 2011, 6:44 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This change makes it so setting an object for sale or modifying the price or sale type requires explicitly applying the changes. Default behavior before this patch is all sale info is committed to sim on change. After this patch the sale info will only get set or modified after hitting a "mark for sale" button. There is no change to removing an object from sale, unchecking "For sale" will be committed to sim without further user interation. > > https://bitbucket.org/Kadah_Coba/vwr-21522 > Main Patch: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/45df3e1e9f6f > German translation: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/01dc58391588 > > > This addresses bug VWR-21522. > http://jira.secondlife.com/browse/VWR-21522 > > > Diffs > ----- > > indra/newview/llpanelpermissions.h b245a988d038 > indra/newview/llpanelpermissions.cpp b245a988d038 > indra/newview/skins/default/xui/en/floater_tools.xml b245a988d038 > > Diff: http://codereview.secondlife.com/r/365/diff > > > Testing > ------- > > (I had stuff here but Review Board kept deleting it every time I tried to save.) > > > Thanks, > > Kadah > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/c8bbb08f/attachment-0001.htm From lee.ponzu at gmail.com Wed Jun 29 06:38:56 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Wed, 29 Jun 2011 09:38:56 -0400 Subject: [opensource-dev] Avatar Scale and Camera Placement Message-ID: There is a thought provoking discussion of avatar scale here... http://www.sluniverse.com/php/vb/content-creation/61046-matter-scale-how-scale-affects.html You've probably seen it, but if not, it is a worthwhile read. One of the issues is default camera placement. In brief, the default is too far back and too high. Of course, this is a matter of individual needs and taste, but it suggested to me a useful "feature" for the viewer. How about a few pre-packaged optional camera placement configurations in preferences? (Yes, experts can keep using the legacy sliders.) Traditional: Camera behavior as at present Closer: Camera is lower, closer, and more level, as suggested in the thread. Close: Maybe something half way between Traditional and Closest. Crowd: Farther than traditional Then, make it easy to switch from one to another. Funner/Faster/Easier!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/074e29a1/attachment.htm From oz at lindenlab.com Wed Jun 29 06:41:05 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 29 Jun 2011 13:41:05 -0000 Subject: [opensource-dev] Review Request: VWR-21522: Prevent unintended 10L sale In-Reply-To: <20110628014402.22033.2057@domU-12-31-38-00-90-68.compute-1.internal> References: <20110628014402.22033.2057@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110629134105.22026.11505@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/365/#review824 ----------------------------------------------------------- Just a couple of minor items to address and this looks good. remove the 'KC:' from your comments ... mercurial will tell us who to blame if we need to know :-) I don't really think that the issue ids are needed either, but don't object to them. indra/newview/llpanelpermissions.h it would be clearer to spell that 'mLastSelectedObject' (transpose 'j' and 'e') indra/newview/llpanelpermissions.cpp There's nothing else inside this 'else if' - why not add the check of update_sale_info to this statement rather than adding the nested if ? - Oz On June 27, 2011, 6:44 p.m., Kadah Coba wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/365/ > ----------------------------------------------------------- > > (Updated June 27, 2011, 6:44 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This change makes it so setting an object for sale or modifying the price or sale type requires explicitly applying the changes. Default behavior before this patch is all sale info is committed to sim on change. After this patch the sale info will only get set or modified after hitting a "mark for sale" button. There is no change to removing an object from sale, unchecking "For sale" will be committed to sim without further user interation. > > https://bitbucket.org/Kadah_Coba/vwr-21522 > Main Patch: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/45df3e1e9f6f > German translation: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/01dc58391588 > > > This addresses bug VWR-21522. > http://jira.secondlife.com/browse/VWR-21522 > > > Diffs > ----- > > indra/newview/llpanelpermissions.h b245a988d038 > indra/newview/llpanelpermissions.cpp b245a988d038 > indra/newview/skins/default/xui/en/floater_tools.xml b245a988d038 > > Diff: http://codereview.secondlife.com/r/365/diff > > > Testing > ------- > > (I had stuff here but Review Board kept deleting it every time I tried to save.) > > > Thanks, > > Kadah > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/77afa5a6/attachment.htm From lee.ponzu at gmail.com Wed Jun 29 06:44:58 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Wed, 29 Jun 2011 09:44:58 -0400 Subject: [opensource-dev] Basic Shaders and FPS Message-ID: This is something I just discovered that I suppose most of you have always known. I was messing with my oldish iMac (ATI 2600 Pro) and I discovered that the main thing that makes all the difference to FPS is the shaders. Basic Shaders off: FPS == 30 to 50. Basic Shaders on: FPS == 13 to 15 Similar effect for just Atmospheric or Shadows. So, this made me crave a custom button for turning shaders on and off (yeah, CMD-P/Graphics/Basic Shader is easy. Just thinking of all the people who don't even know that preferences exists 8-) Need FPS? <>. Want things to look better? <> Easy peasy. BTW, I also briefly tested on my slightly newer Macbook Pro (nvidia 9400M). Same ting, but the FPS difference is much less dramatic. ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/365ebeeb/attachment.htm From jhwelch at gmail.com Wed Jun 29 07:32:47 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 29 Jun 2011 14:32:47 -0000 Subject: [opensource-dev] Review Request: STORM-1459 "Wearing Tab" - Add ability to copy displayed inventory names to clipboard Message-ID: <20110629143247.22928.81730@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/370/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Add a feature on the "Wearing TAB" where users could copy to the clipboard everything you see in the "Wearing TAB". This would make the blogging communities life soooooo much easier instead of having to type out all that information. The label on this button needs input from someone on the XD team. I would like to know if my code for adding a CR to the end of every line but the last one could be done in a more elegant way. This addresses bug STORM-1459. http://jira.secondlife.com/browse/STORM-1459 Diffs ----- doc/contributions.txt f9864a43ddf0 indra/newview/llpanelwearing.h f9864a43ddf0 indra/newview/llpanelwearing.cpp f9864a43ddf0 indra/newview/skins/default/xui/en/panel_outfits_wearing.xml f9864a43ddf0 Diff: http://codereview.secondlife.com/r/370/diff Testing ------- Clicked on Send to Clipboard button and was able to paste results into an editor. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/cbc12d4b/attachment.htm From vsavchuk at productengine.com Wed Jun 29 07:52:41 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Wed, 29 Jun 2011 14:52:41 -0000 Subject: [opensource-dev] Review Request: STORM-1459 "Wearing Tab" - Add ability to copy displayed inventory names to clipboard In-Reply-To: <20110629143247.22928.81730@domU-12-31-38-00-90-68.compute-1.internal> References: <20110629143247.22928.81730@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110629145241.22030.77642@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/370/#review826 ----------------------------------------------------------- Looks good apart from missing NULL check. indra/newview/llpanelwearing.cpp I'd use const_iterator instead. indra/newview/llpanelwearing.cpp A bit of code duplication. I'd rewrite it like this: ///////////////////////////////// if (!need_cr) { need_cr = true; } else { text += "\n"; } text += item->getName(); ///////////////////////////////// Please also make sure the item is not NULL to prevent a crash. - Vadim On June 29, 2011, 7:32 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/370/ > ----------------------------------------------------------- > > (Updated June 29, 2011, 7:32 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Add a feature on the "Wearing TAB" where users could copy to the clipboard everything you see in the "Wearing TAB". This would make the blogging communities life soooooo much easier instead of having to type out all that information. > > The label on this button needs input from someone on the XD team. > > I would like to know if my code for adding a CR to the end of every line but the last one could be done in a more elegant way. > > > This addresses bug STORM-1459. > http://jira.secondlife.com/browse/STORM-1459 > > > Diffs > ----- > > doc/contributions.txt f9864a43ddf0 > indra/newview/llpanelwearing.h f9864a43ddf0 > indra/newview/llpanelwearing.cpp f9864a43ddf0 > indra/newview/skins/default/xui/en/panel_outfits_wearing.xml f9864a43ddf0 > > Diff: http://codereview.secondlife.com/r/370/diff > > > Testing > ------- > > Clicked on Send to Clipboard button and was able to paste results into an editor. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/cb70cb27/attachment-0001.htm From kadah.coba at gmail.com Wed Jun 29 11:31:31 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Wed, 29 Jun 2011 18:31:31 -0000 Subject: [opensource-dev] Review Request: VWR-21522: Prevent unintended 10L sale In-Reply-To: <20110629134105.22026.11505@domU-12-31-38-00-90-68.compute-1.internal> References: <20110629134105.22026.11505@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110629183131.22029.89821@domU-12-31-38-00-90-68.compute-1.internal> > On June 29, 2011, 6:41 a.m., Oz Linden wrote: > > indra/newview/llpanelpermissions.cpp, lines 477-480 > > > > > > There's nothing else inside this 'else if' - why not add the check of update_sale_info to this statement rather than adding the nested if ? The parent if ends with an 'else' that disables the inputs controls; a lot of the logic would need reworking. I'll poke it to see if can work the logic to handle this. - Kadah ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/365/#review824 ----------------------------------------------------------- On June 27, 2011, 6:44 p.m., Kadah Coba wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/365/ > ----------------------------------------------------------- > > (Updated June 27, 2011, 6:44 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This change makes it so setting an object for sale or modifying the price or sale type requires explicitly applying the changes. Default behavior before this patch is all sale info is committed to sim on change. After this patch the sale info will only get set or modified after hitting a "mark for sale" button. There is no change to removing an object from sale, unchecking "For sale" will be committed to sim without further user interation. > > https://bitbucket.org/Kadah_Coba/vwr-21522 > Main Patch: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/45df3e1e9f6f > German translation: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/01dc58391588 > > > This addresses bug VWR-21522. > http://jira.secondlife.com/browse/VWR-21522 > > > Diffs > ----- > > indra/newview/llpanelpermissions.h b245a988d038 > indra/newview/llpanelpermissions.cpp b245a988d038 > indra/newview/skins/default/xui/en/floater_tools.xml b245a988d038 > > Diff: http://codereview.secondlife.com/r/365/diff > > > Testing > ------- > > (I had stuff here but Review Board kept deleting it every time I tried to save.) > > > Thanks, > > Kadah > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/a5aa39ba/attachment.htm From kadah.coba at gmail.com Wed Jun 29 11:36:15 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Wed, 29 Jun 2011 18:36:15 -0000 Subject: [opensource-dev] Review Request: VWR-21522: Prevent unintended 10L sale In-Reply-To: <20110629133708.25892.40071@domU-12-31-38-00-90-68.compute-1.internal> References: <20110629133708.25892.40071@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110629183615.23142.28653@domU-12-31-38-00-90-68.compute-1.internal> > On June 29, 2011, 6:37 a.m., Vadim ProductEngine wrote: > > indra/newview/llpanelpermissions.cpp, line 245 > > > > > > Coding standard: rewrite as btn_mark_for_sale. Will do. As far as the XUI names, is there a standard for those? I've noted several different styles used and floater_tools uses one of the oldest I've seen. - Kadah ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/365/#review825 ----------------------------------------------------------- On June 27, 2011, 6:44 p.m., Kadah Coba wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/365/ > ----------------------------------------------------------- > > (Updated June 27, 2011, 6:44 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This change makes it so setting an object for sale or modifying the price or sale type requires explicitly applying the changes. Default behavior before this patch is all sale info is committed to sim on change. After this patch the sale info will only get set or modified after hitting a "mark for sale" button. There is no change to removing an object from sale, unchecking "For sale" will be committed to sim without further user interation. > > https://bitbucket.org/Kadah_Coba/vwr-21522 > Main Patch: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/45df3e1e9f6f > German translation: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/01dc58391588 > > > This addresses bug VWR-21522. > http://jira.secondlife.com/browse/VWR-21522 > > > Diffs > ----- > > indra/newview/llpanelpermissions.h b245a988d038 > indra/newview/llpanelpermissions.cpp b245a988d038 > indra/newview/skins/default/xui/en/floater_tools.xml b245a988d038 > > Diff: http://codereview.secondlife.com/r/365/diff > > > Testing > ------- > > (I had stuff here but Review Board kept deleting it every time I tried to save.) > > > Thanks, > > Kadah > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/5606a654/attachment.htm From hitomi.tiponi at yahoo.co.uk Wed Jun 29 12:11:09 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Wed, 29 Jun 2011 20:11:09 +0100 (BST) Subject: [opensource-dev] Basic Shaders and FPS Message-ID: <1309374669.97334.YahooMailRC@web23903.mail.ird.yahoo.com> That is why there are the Low-Medium-High-Ultra settings - so that people don't need to know about shaders, just that sliding the slider right makes things look better but slower. The individual settings for each standard setting (e.g. Low) could be debated, but the approach seems to work pretty well. And it is not just shaders that make a big difference - LOD and Draw Distance also have a big effect. >I was messing with my oldish iMac (ATI 2600 Pro) and I discovered that the > main thing that makes all the difference to FPS is the shaders. ... >So, this made me crave a custom button for turning shaders on and off (yeah, >CMD-P/Graphics/Basic Shader is easy. Just thinking of all the people who >don't even know that preferences exists 8-) Need FPS? <>. >Want things to look better? <> Easy peasy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/6fce4cc5/attachment.htm From jhwelch at gmail.com Wed Jun 29 12:14:14 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 29 Jun 2011 19:14:14 -0000 Subject: [opensource-dev] Review Request: STORM-1459 "Wearing Tab" - Add ability to copy displayed inventory names to clipboard In-Reply-To: <20110629143247.22928.81730@domU-12-31-38-00-90-68.compute-1.internal> References: <20110629143247.22928.81730@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110629191414.22033.36444@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/370/ ----------------------------------------------------------- (Updated June 29, 2011, 12:14 p.m.) Review request for Viewer. Changes ------- Made changes requested by Oz and Vadim and with help from Alexandrea Fride. Summary ------- Add a feature on the "Wearing TAB" where users could copy to the clipboard everything you see in the "Wearing TAB". This would make the blogging communities life soooooo much easier instead of having to type out all that information. The label on this button needs input from someone on the XD team. I would like to know if my code for adding a CR to the end of every line but the last one could be done in a more elegant way. This addresses bug STORM-1459. http://jira.secondlife.com/browse/STORM-1459 Diffs (updated) ----- doc/contributions.txt f9864a43ddf0 indra/newview/llpanelwearing.h f9864a43ddf0 indra/newview/llpanelwearing.cpp f9864a43ddf0 indra/newview/skins/default/xui/en/menu_wearing_gear.xml f9864a43ddf0 Diff: http://codereview.secondlife.com/r/370/diff Testing ------- Clicked on Send to Clipboard button and was able to paste results into an editor. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/76cfc347/attachment.htm From kadah.coba at gmail.com Wed Jun 29 16:54:17 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Wed, 29 Jun 2011 23:54:17 -0000 Subject: [opensource-dev] Review Request: VWR-21522: Prevent unintended 10L sale In-Reply-To: <20110628014402.22033.2057@domU-12-31-38-00-90-68.compute-1.internal> References: <20110628014402.22033.2057@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110629235417.22033.86163@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/365/ ----------------------------------------------------------- (Updated June 29, 2011, 4:54 p.m.) Review request for Viewer. Changes ------- Added requested changes (I think I got them all) Fixed issue where objects that are being actively changed by scripts would get prevented from being marked for sale Summary ------- This change makes it so setting an object for sale or modifying the price or sale type requires explicitly applying the changes. Default behavior before this patch is all sale info is committed to sim on change. After this patch the sale info will only get set or modified after hitting a "mark for sale" button. There is no change to removing an object from sale, unchecking "For sale" will be committed to sim without further user interation. https://bitbucket.org/Kadah_Coba/vwr-21522 Main Patch: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/45df3e1e9f6f German translation: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/01dc58391588 This addresses bug VWR-21522. http://jira.secondlife.com/browse/VWR-21522 Diffs (updated) ----- indra/newview/skins/default/xui/de/floater_tools.xml b245a988d038 indra/newview/skins/default/xui/en/floater_tools.xml b245a988d038 indra/newview/llpanelpermissions.h b245a988d038 indra/newview/llpanelpermissions.cpp b245a988d038 Diff: http://codereview.secondlife.com/r/365/diff Testing ------- (I had stuff here but Review Board kept deleting it every time I tried to save.) Thanks, Kadah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110629/5e0edb00/attachment.htm From nickyperian at yahoo.com Wed Jun 29 18:34:00 2011 From: nickyperian at yahoo.com (Nicky Perian) Date: Thu, 30 Jun 2011 01:34:00 -0000 Subject: [opensource-dev] Review Request: STORM-1459 "Wearing Tab" - Add ability to copy displayed inventory names to clipboard In-Reply-To: <20110629191414.22033.36444@domU-12-31-38-00-90-68.compute-1.internal> References: <20110629191414.22033.36444@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110630013400.25891.71839@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/370/#review829 ----------------------------------------------------------- \n is a new line character(line-feed) \r is a carriage return. maybe change the comment to new line. - Nicky On June 29, 2011, 12:14 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/370/ > ----------------------------------------------------------- > > (Updated June 29, 2011, 12:14 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Add a feature on the "Wearing TAB" where users could copy to the clipboard everything you see in the "Wearing TAB". This would make the blogging communities life soooooo much easier instead of having to type out all that information. > > The label on this button needs input from someone on the XD team. > > I would like to know if my code for adding a CR to the end of every line but the last one could be done in a more elegant way. > > > This addresses bug STORM-1459. > http://jira.secondlife.com/browse/STORM-1459 > > > Diffs > ----- > > doc/contributions.txt f9864a43ddf0 > indra/newview/llpanelwearing.h f9864a43ddf0 > indra/newview/llpanelwearing.cpp f9864a43ddf0 > indra/newview/skins/default/xui/en/menu_wearing_gear.xml f9864a43ddf0 > > Diff: http://codereview.secondlife.com/r/370/diff > > > Testing > ------- > > Clicked on Send to Clipboard button and was able to paste results into an editor. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/10c384bf/attachment.htm From kadah.coba at gmail.com Wed Jun 29 23:57:53 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Thu, 30 Jun 2011 06:57:53 -0000 Subject: [opensource-dev] Review Request: STORM-1315: Ability to do simple math in numeric edit fields Message-ID: <20110630065753.22033.14086@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/377/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This is a direct adaptation of Aimee Trescothick's contributed patch from STORM-1315 for v-d. Adjustments were made where needed to make it work with the newer boost and llui code. Some changes were made to the variable names it uses on build; ie "PX" for x position instead of just "X". Patch allows for imputing simple math equations in to the spinner controls. On the build floater a series of variable names are available for using the objects current values in equations, like "sx+3" will take the current X scale and add 3. Repo: https://bitbucket.org/Kadah_Coba/storm-1315 Changeset: https://bitbucket.org/Kadah_Coba/storm-1315/changeset/d33ca6edf370 This addresses bug STORM-1315. http://jira.secondlife.com/browse/STORM-1315 Diffs ----- doc/contributions.txt UNKNOWN indra/llmath/CMakeLists.txt UNKNOWN indra/llmath/llcalc.h UNKNOWN indra/llmath/llcalc.cpp UNKNOWN indra/llmath/llcalcparser.h UNKNOWN indra/llmath/llcalcparser.cpp UNKNOWN indra/llui/lllineeditor.h UNKNOWN indra/llui/lllineeditor.cpp UNKNOWN indra/llui/llspinctrl.cpp UNKNOWN indra/newview/llappviewer.cpp UNKNOWN indra/newview/llpanelface.cpp UNKNOWN indra/newview/llpanelobject.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/377/diff Testing ------- Built and ran. Some testing done with simple equations on the build tools floater to edit an object, no issues were observed. Thanks, Kadah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/376f11c2/attachment-0001.htm From jhwelch at gmail.com Thu Jun 30 01:27:00 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 30 Jun 2011 08:27:00 -0000 Subject: [opensource-dev] Review Request: STORM-1459 "Wearing Tab" - Add ability to copy displayed inventory names to clipboard In-Reply-To: <20110629191414.22033.36444@domU-12-31-38-00-90-68.compute-1.internal> References: <20110629191414.22033.36444@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110630082700.23142.6570@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/370/ ----------------------------------------------------------- (Updated June 30, 2011, 1:27 a.m.) Review request for Viewer. Changes ------- Updated comment per Nicky's suggestion Summary ------- Add a feature on the "Wearing TAB" where users could copy to the clipboard everything you see in the "Wearing TAB". This would make the blogging communities life soooooo much easier instead of having to type out all that information. The label on this button needs input from someone on the XD team. I would like to know if my code for adding a CR to the end of every line but the last one could be done in a more elegant way. This addresses bug STORM-1459. http://jira.secondlife.com/browse/STORM-1459 Diffs (updated) ----- doc/contributions.txt f9864a43ddf0 indra/newview/llpanelwearing.h f9864a43ddf0 indra/newview/llpanelwearing.cpp f9864a43ddf0 indra/newview/skins/default/xui/en/menu_wearing_gear.xml f9864a43ddf0 Diff: http://codereview.secondlife.com/r/370/diff Testing ------- Clicked on Send to Clipboard button and was able to paste results into an editor. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/f2d4d74c/attachment.htm From opensourceobscure at gmail.com Thu Jun 30 03:56:27 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Thu, 30 Jun 2011 12:56:27 +0200 Subject: [opensource-dev] focus to Inventory Search Message-ID: Please enable back focus to Inventory Search. See https://jira.secondlife.com/browse/VWR-19700 https://jira.secondlife.com/browse/VWR-18496 https://jira.secondlife.com/browse/VWR-19967 Opensource Obscure -- http://twitter.com/oobscure - http://opensourceobscure.com/lol discuss Second Life Viewer 2: http://j.mp/slv2group From vsavchuk at productengine.com Thu Jun 30 09:29:27 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Thu, 30 Jun 2011 16:29:27 -0000 Subject: [opensource-dev] Review Request: VWR-21522: Prevent unintended 10L sale In-Reply-To: <20110629235417.22033.86163@domU-12-31-38-00-90-68.compute-1.internal> References: <20110629235417.22033.86163@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110630162927.25890.42890@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/365/#review831 ----------------------------------------------------------- Ship it! Fine with me. Although, if you correct the cosmetic issues below, that will be great. indra/newview/llpanelpermissions.cpp Please separate comments from "//" with a space, i.e. write "// Check if..." indra/newview/llpanelpermissions.cpp CS: check_purchase or better check_purchase_cb indra/newview/llpanelpermissions.cpp dead code indra/newview/llpanelpermissions.cpp ditto - Vadim On June 29, 2011, 4:54 p.m., Kadah Coba wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/365/ > ----------------------------------------------------------- > > (Updated June 29, 2011, 4:54 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This change makes it so setting an object for sale or modifying the price or sale type requires explicitly applying the changes. Default behavior before this patch is all sale info is committed to sim on change. After this patch the sale info will only get set or modified after hitting a "mark for sale" button. There is no change to removing an object from sale, unchecking "For sale" will be committed to sim without further user interation. > > https://bitbucket.org/Kadah_Coba/vwr-21522 > Main Patch: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/45df3e1e9f6f > German translation: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/01dc58391588 > > > This addresses bug VWR-21522. > http://jira.secondlife.com/browse/VWR-21522 > > > Diffs > ----- > > indra/newview/skins/default/xui/de/floater_tools.xml b245a988d038 > indra/newview/skins/default/xui/en/floater_tools.xml b245a988d038 > indra/newview/llpanelpermissions.h b245a988d038 > indra/newview/llpanelpermissions.cpp b245a988d038 > > Diff: http://codereview.secondlife.com/r/365/diff > > > Testing > ------- > > (I had stuff here but Review Board kept deleting it every time I tried to save.) > > > Thanks, > > Kadah > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/32ad2cc5/attachment.htm From vsavchuk at productengine.com Thu Jun 30 10:00:06 2011 From: vsavchuk at productengine.com (Vadim Savchuk) Date: Thu, 30 Jun 2011 20:00:06 +0300 Subject: [opensource-dev] Review Request: STORM-1315: Ability to do simple math in numeric edit fields In-Reply-To: <20110630065753.22033.14086@domU-12-31-38-00-90-68.compute-1.internal> References: <20110630065753.22033.14086@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <4E0CAB96.8020505@productengine.com> On 06/30/2011 09:57 AM, Kadah Coba wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/377/ > > > Review request for Viewer. > By Kadah Coba. > > > Description > > This is a direct adaptation of Aimee Trescothick's contributed patch from STORM-1315 for v-d. Adjustments were made where needed to make it work with the newer boost and llui code. Some changes were made to the variable names it uses on build; ie "PX" for x position instead of just "X". > > Patch allows for imputing simple math equations in to the spinner controls. On the build floater a series of variable names are available for using the objects current values in equations, like "sx+3" will take the current X scale and add 3. > I get an error when try to view the diff on Review Board. Please refresh it or create a new review request (not sure how to fix). -- Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/0183def4/attachment-0001.htm From kadah.coba at gmail.com Thu Jun 30 10:22:55 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Thu, 30 Jun 2011 17:22:55 -0000 Subject: [opensource-dev] Review Request: VWR-21522: Prevent unintended 10L sale In-Reply-To: <20110630162927.25890.42890@domU-12-31-38-00-90-68.compute-1.internal> References: <20110630162927.25890.42890@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110630172255.22029.44311@domU-12-31-38-00-90-68.compute-1.internal> > On June 30, 2011, 9:29 a.m., Vadim ProductEngine wrote: > > indra/newview/llpanelpermissions.cpp, line 1027 > > > > > > CS: check_purchase or better check_purchase_cb Same name is used else where in the legacy code, should I change both while I'm at it? > On June 30, 2011, 9:29 a.m., Vadim ProductEngine wrote: > > indra/newview/llpanelpermissions.cpp, line 1118 > > > > > > dead code Mistake while merging, will clean > On June 30, 2011, 9:29 a.m., Vadim ProductEngine wrote: > > indra/newview/llpanelpermissions.cpp, line 443 > > > > > > Please separate comments from "//" with a space, i.e. write "// Check if..." I don't think that was in the CS wiki doc. Will fix comments - Kadah ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/365/#review831 ----------------------------------------------------------- On June 29, 2011, 4:54 p.m., Kadah Coba wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/365/ > ----------------------------------------------------------- > > (Updated June 29, 2011, 4:54 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This change makes it so setting an object for sale or modifying the price or sale type requires explicitly applying the changes. Default behavior before this patch is all sale info is committed to sim on change. After this patch the sale info will only get set or modified after hitting a "mark for sale" button. There is no change to removing an object from sale, unchecking "For sale" will be committed to sim without further user interation. > > https://bitbucket.org/Kadah_Coba/vwr-21522 > Main Patch: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/45df3e1e9f6f > German translation: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/01dc58391588 > > > This addresses bug VWR-21522. > http://jira.secondlife.com/browse/VWR-21522 > > > Diffs > ----- > > indra/newview/skins/default/xui/de/floater_tools.xml b245a988d038 > indra/newview/skins/default/xui/en/floater_tools.xml b245a988d038 > indra/newview/llpanelpermissions.h b245a988d038 > indra/newview/llpanelpermissions.cpp b245a988d038 > > Diff: http://codereview.secondlife.com/r/365/diff > > > Testing > ------- > > (I had stuff here but Review Board kept deleting it every time I tried to save.) > > > Thanks, > > Kadah > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/d546a3fd/attachment.htm From Lance.Corrimal at eregion.de Thu Jun 30 10:33:32 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 30 Jun 2011 19:33:32 +0200 Subject: [opensource-dev] focus to Inventory Search In-Reply-To: References: Message-ID: <201106301933.33170.Lance.Corrimal@eregion.de> Am Donnerstag, 30. Juni 2011 schrieb Opensource Obscure: > Please enable back focus to Inventory Search. > > See https://jira.secondlife.com/browse/VWR-19700 > https://jira.secondlife.com/browse/VWR-18496 > https://jira.secondlife.com/browse/VWR-19967 https://jira.secondlife.com/browse/VWR-26169 as well. LC From kadah.coba at gmail.com Thu Jun 30 10:33:42 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Thu, 30 Jun 2011 17:33:42 -0000 Subject: [opensource-dev] Review Request: VWR-21522: Prevent unintended 10L sale In-Reply-To: <20110629235417.22033.86163@domU-12-31-38-00-90-68.compute-1.internal> References: <20110629235417.22033.86163@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110630173342.23142.27597@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/365/ ----------------------------------------------------------- (Updated June 30, 2011, 10:33 a.m.) Review request for Viewer. Changes ------- Requested CS changes. Would you like a clean fork with this as one changeset? The current fork got too messy for my standards. Summary ------- This change makes it so setting an object for sale or modifying the price or sale type requires explicitly applying the changes. Default behavior before this patch is all sale info is committed to sim on change. After this patch the sale info will only get set or modified after hitting a "mark for sale" button. There is no change to removing an object from sale, unchecking "For sale" will be committed to sim without further user interation. https://bitbucket.org/Kadah_Coba/vwr-21522 Main Patch: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/45df3e1e9f6f German translation: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/01dc58391588 This addresses bug VWR-21522. http://jira.secondlife.com/browse/VWR-21522 Diffs (updated) ----- doc/contributions.txt UNKNOWN indra/newview/llpanelpermissions.h UNKNOWN indra/newview/llpanelpermissions.cpp UNKNOWN indra/newview/skins/default/xui/de/floater_tools.xml UNKNOWN indra/newview/skins/default/xui/en/floater_tools.xml UNKNOWN Diff: http://codereview.secondlife.com/r/365/diff Testing ------- (I had stuff here but Review Board kept deleting it every time I tried to save.) Thanks, Kadah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/9b0a5591/attachment.htm From vsavchuk at productengine.com Thu Jun 30 11:02:14 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Thu, 30 Jun 2011 18:02:14 -0000 Subject: [opensource-dev] Review Request: STORM-1459 "Wearing Tab" - Add ability to copy displayed inventory names to clipboard In-Reply-To: <20110630082700.23142.6570@domU-12-31-38-00-90-68.compute-1.internal> References: <20110630082700.23142.6570@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110630180214.23142.23745@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/370/#review834 ----------------------------------------------------------- Ship it! No major objections. indra/newview/llpanelwearing.cpp Looks a bit confusing. - Vadim On June 30, 2011, 1:27 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/370/ > ----------------------------------------------------------- > > (Updated June 30, 2011, 1:27 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Add a feature on the "Wearing TAB" where users could copy to the clipboard everything you see in the "Wearing TAB". This would make the blogging communities life soooooo much easier instead of having to type out all that information. > > The label on this button needs input from someone on the XD team. > > I would like to know if my code for adding a CR to the end of every line but the last one could be done in a more elegant way. > > > This addresses bug STORM-1459. > http://jira.secondlife.com/browse/STORM-1459 > > > Diffs > ----- > > doc/contributions.txt f9864a43ddf0 > indra/newview/llpanelwearing.h f9864a43ddf0 > indra/newview/llpanelwearing.cpp f9864a43ddf0 > indra/newview/skins/default/xui/en/menu_wearing_gear.xml f9864a43ddf0 > > Diff: http://codereview.secondlife.com/r/370/diff > > > Testing > ------- > > Clicked on Send to Clipboard button and was able to paste results into an editor. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/c5679dc5/attachment-0001.htm From vsavchuk at productengine.com Thu Jun 30 11:15:51 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Thu, 30 Jun 2011 18:15:51 -0000 Subject: [opensource-dev] Review Request: VWR-21522: Prevent unintended 10L sale In-Reply-To: <20110630162927.25890.42890@domU-12-31-38-00-90-68.compute-1.internal> References: <20110630162927.25890.42890@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110630181551.22028.55766@domU-12-31-38-00-90-68.compute-1.internal> > On June 30, 2011, 9:29 a.m., Vadim ProductEngine wrote: > > indra/newview/llpanelpermissions.cpp, line 1027 > > > > > > CS: check_purchase or better check_purchase_cb > > Kadah Coba wrote: > Same name is used else where in the legacy code, should I change both while I'm at it? Well, you generally don't have to fix CS in code that you didn't modify. But in this case the change seems to be small and related to your work, so please do. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/365/#review831 ----------------------------------------------------------- On June 30, 2011, 10:33 a.m., Kadah Coba wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/365/ > ----------------------------------------------------------- > > (Updated June 30, 2011, 10:33 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This change makes it so setting an object for sale or modifying the price or sale type requires explicitly applying the changes. Default behavior before this patch is all sale info is committed to sim on change. After this patch the sale info will only get set or modified after hitting a "mark for sale" button. There is no change to removing an object from sale, unchecking "For sale" will be committed to sim without further user interation. > > https://bitbucket.org/Kadah_Coba/vwr-21522 > Main Patch: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/45df3e1e9f6f > German translation: https://bitbucket.org/Kadah_Coba/vwr-21522/changeset/01dc58391588 > > > This addresses bug VWR-21522. > http://jira.secondlife.com/browse/VWR-21522 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/newview/llpanelpermissions.h UNKNOWN > indra/newview/llpanelpermissions.cpp UNKNOWN > indra/newview/skins/default/xui/de/floater_tools.xml UNKNOWN > indra/newview/skins/default/xui/en/floater_tools.xml UNKNOWN > > Diff: http://codereview.secondlife.com/r/365/diff > > > Testing > ------- > > (I had stuff here but Review Board kept deleting it every time I tried to save.) > > > Thanks, > > Kadah > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/948c0778/attachment.htm From kadah.coba at gmail.com Thu Jun 30 11:56:29 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Thu, 30 Jun 2011 18:56:29 -0000 Subject: [opensource-dev] Review Request: STORM-1315: Ability to do simple math in numeric edit fields In-Reply-To: <20110630065753.22033.14086@domU-12-31-38-00-90-68.compute-1.internal> References: <20110630065753.22033.14086@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110630185629.22026.8801@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/377/ ----------------------------------------------------------- (Updated June 30, 2011, 11:56 a.m.) Review request for Viewer. Changes ------- Lets see if this diff wants to work. Summary ------- This is a direct adaptation of Aimee Trescothick's contributed patch from STORM-1315 for v-d. Adjustments were made where needed to make it work with the newer boost and llui code. Some changes were made to the variable names it uses on build; ie "PX" for x position instead of just "X". Patch allows for imputing simple math equations in to the spinner controls. On the build floater a series of variable names are available for using the objects current values in equations, like "sx+3" will take the current X scale and add 3. Repo: https://bitbucket.org/Kadah_Coba/storm-1315 Changeset: https://bitbucket.org/Kadah_Coba/storm-1315/changeset/d33ca6edf370 This addresses bug STORM-1315. http://jira.secondlife.com/browse/STORM-1315 Diffs (updated) ----- doc/contributions.txt UNKNOWN indra/llmath/CMakeLists.txt UNKNOWN indra/llmath/llcalc.h UNKNOWN indra/llmath/llcalc.cpp UNKNOWN indra/llmath/llcalcparser.h UNKNOWN indra/llmath/llcalcparser.cpp UNKNOWN indra/llui/lllineeditor.h UNKNOWN indra/llui/lllineeditor.cpp UNKNOWN indra/llui/llspinctrl.cpp UNKNOWN indra/newview/llappviewer.cpp UNKNOWN indra/newview/llpanelface.cpp UNKNOWN indra/newview/llpanelobject.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/377/diff Testing ------- Built and ran. Some testing done with simple equations on the build tools floater to edit an object, no issues were observed. Thanks, Kadah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/fb04fcaa/attachment.htm From kadah.coba at gmail.com Thu Jun 30 11:59:25 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Thu, 30 Jun 2011 18:59:25 -0000 Subject: [opensource-dev] Review Request: STORM-1315: Ability to do simple math in numeric edit fields In-Reply-To: <20110630185629.22026.8801@domU-12-31-38-00-90-68.compute-1.internal> References: <20110630185629.22026.8801@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110630185925.22028.27885@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/377/ ----------------------------------------------------------- (Updated June 30, 2011, 11:59 a.m.) Review request for Viewer. Summary ------- This is a direct adaptation of Aimee Trescothick's contributed patch from STORM-1315 for v-d. Adjustments were made where needed to make it work with the newer boost and llui code. Some changes were made to the variable names it uses on build; ie "PX" for x position instead of just "X". Patch allows for imputing simple math equations in to the spinner controls. On the build floater a series of variable names are available for using the objects current values in equations, like "sx+3" will take the current X scale and add 3. Repo: https://bitbucket.org/Kadah_Coba/storm-1315 Changeset: https://bitbucket.org/Kadah_Coba/storm-1315/changeset/d33ca6edf370 This addresses bug STORM-1315. http://jira.secondlife.com/browse/STORM-1315 Diffs (updated) ----- doc/contributions.txt 353807ed6a69 indra/llmath/CMakeLists.txt 353807ed6a69 indra/llmath/llcalc.h PRE-CREATION indra/llmath/llcalc.cpp PRE-CREATION indra/llmath/llcalcparser.h PRE-CREATION indra/llmath/llcalcparser.cpp PRE-CREATION indra/llui/lllineeditor.h 353807ed6a69 indra/llui/lllineeditor.cpp 353807ed6a69 indra/llui/llspinctrl.cpp 353807ed6a69 indra/newview/llappviewer.cpp 353807ed6a69 indra/newview/llpanelface.cpp 353807ed6a69 indra/newview/llpanelobject.cpp 353807ed6a69 Diff: http://codereview.secondlife.com/r/377/diff Testing ------- Built and ran. Some testing done with simple equations on the build tools floater to edit an object, no issues were observed. Thanks, Kadah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/42aa3f2e/attachment.htm From kadah.coba at gmail.com Thu Jun 30 12:00:31 2011 From: kadah.coba at gmail.com (Kadah) Date: Thu, 30 Jun 2011 12:00:31 -0700 Subject: [opensource-dev] Review Request: STORM-1315: Ability to do simple math in numeric edit fields In-Reply-To: <4E0CAB96.8020505@productengine.com> References: <20110630065753.22033.14086@domU-12-31-38-00-90-68.compute-1.internal> <4E0CAB96.8020505@productengine.com> Message-ID: <4E0CC7CF.4030903@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fixed. Not sure why that didn't want to work the first two times. On 6/30/2011 10:00 AM, Vadim Savchuk wrote: > On 06/30/2011 09:57 AM, Kadah Coba wrote: >> This is an automatically generated e-mail. To reply, visit: >> http://codereview.secondlife.com/r/377/ >> >> >> Review request for Viewer. >> By Kadah Coba. >> >> >> Description >> >> This is a direct adaptation of Aimee Trescothick's contributed patch from STORM-1315 for v-d. Adjustments were made where needed to make it work with the newer boost and llui code. Some changes were made to the variable names it uses on build; ie "PX" for x position instead of just "X". >> >> Patch allows for imputing simple math equations in to the spinner controls. On the build floater a series of variable names are available for using the objects current values in equations, like "sx+3" will take the current X scale and add 3. >> > I get an error when try to view the diff on Review Board. Please refresh > it or create a new review request (not sure how to fix). > > -- > Vadim > > > > _______________________________________________ > 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/ iQEcBAEBAgAGBQJODMfOAAoJEIdLfPRu7qE2QQMH/2FDPqJ2EdLIytCHUckc8xtt 9ihAlZTK53U7E+IGoi0tET8C5NexWZ7CXiTIRDkaCltAaS4WhNN8eFvKfAoUqD5M 8MVwc0gyYJ7xpTKSMmAnWICuiO38bQsT2Tj1fssk4H1xmt4crKv2LiSF80aBVAMD jETiqD8zbsqmHJkMSp3G7LO2K4AD29Vq1983YV+JruYb9dmaBPg0oQgkcGYrjXbw eT0j1RtmAK/MqcuSMC+5M2vfosyqMkUOZpOlIjUVIv23JdqvT7ViTX3btBBOXdmN UGlff1SBRTd1+Bo4+Z4c5PL7D/nyhlyESgxafKDDNAL1of2FvdEPqHY9h3I4NAs= =c9eC -----END PGP SIGNATURE----- From kadah.coba at gmail.com Thu Jun 30 13:49:16 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Thu, 30 Jun 2011 20:49:16 -0000 Subject: [opensource-dev] Review Request: STORM-1315: Ability to do simple math in numeric edit fields In-Reply-To: <20110630185925.22028.27885@domU-12-31-38-00-90-68.compute-1.internal> References: <20110630185925.22028.27885@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110630204916.22027.40149@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/377/ ----------------------------------------------------------- (Updated June 30, 2011, 1:49 p.m.) Review request for Viewer. Changes ------- Support for floor, ceil, modulo. Fixed ABS. Added more constants, SQRT_TWO_PI and SQRT3. Summary ------- This is a direct adaptation of Aimee Trescothick's contributed patch from STORM-1315 for v-d. Adjustments were made where needed to make it work with the newer boost and llui code. Some changes were made to the variable names it uses on build; ie "PX" for x position instead of just "X". Patch allows for imputing simple math equations in to the spinner controls. On the build floater a series of variable names are available for using the objects current values in equations, like "sx+3" will take the current X scale and add 3. Repo: https://bitbucket.org/Kadah_Coba/storm-1315 Changeset: https://bitbucket.org/Kadah_Coba/storm-1315/changeset/d33ca6edf370 This addresses bug STORM-1315. http://jira.secondlife.com/browse/STORM-1315 Diffs (updated) ----- doc/contributions.txt UNKNOWN indra/llmath/CMakeLists.txt UNKNOWN indra/llmath/llcalc.h UNKNOWN indra/llmath/llcalc.cpp UNKNOWN indra/llmath/llcalcparser.h UNKNOWN indra/llmath/llcalcparser.cpp UNKNOWN indra/llui/lllineeditor.h UNKNOWN indra/llui/lllineeditor.cpp UNKNOWN indra/llui/llspinctrl.cpp UNKNOWN indra/newview/llappviewer.cpp UNKNOWN indra/newview/llpanelface.cpp UNKNOWN indra/newview/llpanelobject.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/377/diff Testing ------- Built and ran. Some testing done with simple equations on the build tools floater to edit an object, no issues were observed. Thanks, Kadah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/30b7056b/attachment.htm From kadah.coba at gmail.com Thu Jun 30 13:50:22 2011 From: kadah.coba at gmail.com (Kadah Coba) Date: Thu, 30 Jun 2011 20:50:22 -0000 Subject: [opensource-dev] Review Request: STORM-1315: Ability to do simple math in numeric edit fields In-Reply-To: <20110630204916.22027.40149@domU-12-31-38-00-90-68.compute-1.internal> References: <20110630204916.22027.40149@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110630205022.23142.72943@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/377/ ----------------------------------------------------------- (Updated June 30, 2011, 1:50 p.m.) Review request for Viewer. Changes ------- I have no idea why review board keeps breaking my diffs. Trying again. Summary ------- This is a direct adaptation of Aimee Trescothick's contributed patch from STORM-1315 for v-d. Adjustments were made where needed to make it work with the newer boost and llui code. Some changes were made to the variable names it uses on build; ie "PX" for x position instead of just "X". Patch allows for imputing simple math equations in to the spinner controls. On the build floater a series of variable names are available for using the objects current values in equations, like "sx+3" will take the current X scale and add 3. Repo: https://bitbucket.org/Kadah_Coba/storm-1315 Changeset: https://bitbucket.org/Kadah_Coba/storm-1315/changeset/d33ca6edf370 This addresses bug STORM-1315. http://jira.secondlife.com/browse/STORM-1315 Diffs (updated) ----- doc/contributions.txt 353807ed6a69 indra/llmath/CMakeLists.txt 353807ed6a69 indra/llmath/llcalc.h PRE-CREATION indra/llmath/llcalc.cpp PRE-CREATION indra/llmath/llcalcparser.h PRE-CREATION indra/llmath/llcalcparser.cpp PRE-CREATION indra/llui/lllineeditor.h 353807ed6a69 indra/llui/lllineeditor.cpp 353807ed6a69 indra/llui/llspinctrl.cpp 353807ed6a69 indra/newview/llappviewer.cpp 353807ed6a69 indra/newview/llpanelface.cpp 353807ed6a69 indra/newview/llpanelobject.cpp 353807ed6a69 Diff: http://codereview.secondlife.com/r/377/diff Testing ------- Built and ran. Some testing done with simple equations on the build tools floater to edit an object, no issues were observed. Thanks, Kadah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110630/c413a922/attachment.htm