Re: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates
On Feb. 18, 2013, 7:25 a.m., Aleric Inglewood wrote: I don't understand this fix at ALL. It doesn't seem to make any sense :/... What you need is to set the final scale once the distance between destination and current become LESS than the minimum interpolation distance, because then interpolation will never update it anymore. This fix just makes condition true all the time for your test case at your frame rate, but will still fail to reach the final scale when you increase the frame rate (or when the destination scale is simply so close to the start scale that this condition is never true). Hello Aleric, I’m sorry you don’t understand this fix at all. In short: other cases like the one you mentioned still fail to reach the final scale will be treated in other parts of the code and are parts of other if/else conditions. I am aware that the LL version of drawable.cpp differs in several places from the one that Henri (or other TPVs) uses for example, and the change of this fix will not make sense in other viewers. - MartinRJ --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/#review1301 --- On Feb. 17, 2013, 7:02 p.m., MartinRJ Fayray wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/ --- (Updated Feb. 17, 2013, 7:02 p.m.) Review request for Viewer. Description --- At high framerates tiny prims get stuck upon interpolation when they are resized via script. I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), in lldrawable.cpp updateXform to decide whether a scale change requires an immediate rebuild or not. This addresses bug BUG-1709. https://jira.secondlife.com/browse/BUG-1709 Diffs - indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/617/diff/ Testing --- See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 Repository: https://bitbucket.org/MartinRJ/bug-1709 Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/ --- Review request for Viewer. Description --- At high framerates tiny prims get stuck upon interpolation when they are resized via script. I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), in lldrawable.cpp updateXform to decide whether a scale change requires an immediate rebuild or not. This addresses bug BUG-1709. https://jira.secondlife.com/browse/BUG-1709 Diffs - indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/617/diff/ Testing --- See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/ --- (Updated Feb. 17, 2013, 7:02 p.m.) Review request for Viewer. Description --- At high framerates tiny prims get stuck upon interpolation when they are resized via script. I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), in lldrawable.cpp updateXform to decide whether a scale change requires an immediate rebuild or not. This addresses bug BUG-1709. https://jira.secondlife.com/browse/BUG-1709 Diffs - indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/617/diff/ Testing (updated) --- See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 Repository: https://bitbucket.org/MartinRJ/bug-1709 Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/616/ --- (Updated Feb. 16, 2013, 10:53 a.m.) Review request for Viewer. Description --- Fixes missing childprim- position/rotation-updates when the avatar was 20+m away and didn't have the object in view when it was changed. Repository: https://bitbucket.org/MartinRJ/bug-840 This addresses bug BUG-840. https://jira.secondlife.com/browse/BUG-840 Diffs - indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/616/diff/ Testing (updated) --- Create an object with two prims, add a script with a listener on PUBLIC_CHANNEL and make it change the relative position of the child prim in the listen-event. Move the avatar 20+ m away from the test object, and look in the opposite direction, so that the object is not in view. Shout something in public chat so that the child prim changes its relative position. Turn around so that the test object is in view again. Expected result: the prims visibly changed. Without this fix, the child prim would not update its position (or rotation). This fix has to be tested against the following related bugs: BUG-840 [positionbug], BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL MAINT-2275 [vehiclebug], Child prims are left behind by animated, moving physical objects MAINT-1742 [selection], Child object does not update position while selected. MAINT-2247 [selection] Child object does not update rotation while selected. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/616/ --- (Updated Feb. 16, 2013, 11:44 a.m.) Review request for Viewer. Changes --- Successfully tested against: BUG-840 [positionbug], BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL MAINT-2275 [vehiclebug], Child prims are left behind by animated, moving physical objects MAINT-1742 [selection], Child object does not update position while selected. MAINT-2247 [selection] Child object does not update rotation while selected. Description --- Fixes missing childprim- position/rotation-updates when the avatar was 20+m away and didn't have the object in view when it was changed. Repository: https://bitbucket.org/MartinRJ/bug-840 This addresses bug BUG-840. https://jira.secondlife.com/browse/BUG-840 Diffs (updated) - indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/616/diff/ Testing --- Create an object with two prims, add a script with a listener on PUBLIC_CHANNEL and make it change the relative position of the child prim in the listen-event. Move the avatar 20+ m away from the test object, and look in the opposite direction, so that the object is not in view. Shout something in public chat so that the child prim changes its relative position. Turn around so that the test object is in view again. Expected result: the prims visibly changed. Without this fix, the child prim would not update its position (or rotation). This fix has to be tested against the following related bugs: BUG-840 [positionbug], BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL MAINT-2275 [vehiclebug], Child prims are left behind by animated, moving physical objects MAINT-1742 [selection], Child object does not update position while selected. MAINT-2247 [selection] Child object does not update rotation while selected. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/616/ --- (Updated Feb. 16, 2013, 11:25 p.m.) Review request for Viewer. Changes --- Did some cleanup. Description --- Fixes missing childprim- position/rotation-updates when the avatar was 20+m away and didn't have the object in view when it was changed. Repository: https://bitbucket.org/MartinRJ/bug-840 This addresses bug BUG-840. https://jira.secondlife.com/browse/BUG-840 Diffs (updated) - indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/616/diff/ Testing --- Create an object with two prims, add a script with a listener on PUBLIC_CHANNEL and make it change the relative position of the child prim in the listen-event. Move the avatar 20+ m away from the test object, and look in the opposite direction, so that the object is not in view. Shout something in public chat so that the child prim changes its relative position. Turn around so that the test object is in view again. Expected result: the prims visibly changed. Without this fix, the child prim would not update its position (or rotation). This fix has to be tested against the following related bugs: BUG-840 [positionbug], BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL MAINT-2275 [vehiclebug], Child prims are left behind by animated, moving physical objects MAINT-1742 [selection], Child object does not update position while selected. MAINT-2247 [selection] Child object does not update rotation while selected. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/616/ --- Review request for Viewer. Description --- Fixes missing childprim- position/rotation-updates when the avatar was 20+m away and didn't have the object in view when it was changed. Repository: https://bitbucket.org/MartinRJ/bug-840 This addresses bug BUG-840. https://jira.secondlife.com/browse/BUG-840 Diffs - indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/616/diff/ Testing --- Create an object with two prims, add a script with a listener on PUBLIC_CHANNEL and make it change the relative position of the child prim in the listen-event. Move the avatar 20+ m away from the test object, and look in the opposite direction, so that the object is not in view. Shout something in public chat so that the child prim changes its relative position. Turn around so that the test object is in view again. Expected result: the prims visibly changed. Without this fix, the child prim would not update its position (or rotation). Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/616/#review1299 --- I just noticed that my fix re-introduces MAINT-2275 Child prims are left behind by animated, moving (physical) linksets. I'm looking for a solution. - MartinRJ Fayray On Feb. 15, 2013, 1:54 a.m., MartinRJ Fayray wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/616/ --- (Updated Feb. 15, 2013, 1:54 a.m.) Review request for Viewer. Description --- Fixes missing childprim- position/rotation-updates when the avatar was 20+m away and didn't have the object in view when it was changed. Repository: https://bitbucket.org/MartinRJ/bug-840 This addresses bug BUG-840. https://jira.secondlife.com/browse/BUG-840 Diffs - indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/616/diff/ Testing --- Create an object with two prims, add a script with a listener on PUBLIC_CHANNEL and make it change the relative position of the child prim in the listen-event. Move the avatar 20+ m away from the test object, and look in the opposite direction, so that the object is not in view. Shout something in public chat so that the child prim changes its relative position. Turn around so that the test object is in view again. Expected result: the prims visibly changed. Without this fix, the child prim would not update its position (or rotation). Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: BUG-540: Math updates by Moon Metty. Reviewed by Chieron Tenk.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/606/ --- Review request for Viewer. Description --- Improved functions: getEulerAngles ( now: setQuat(F32 roll, F32 pitch, F32 yaw) ) packToVector3 getAngleAxis setAngleAxis shortestArc projected_vec angle_between For details please see: http://jira.phoenixviewer.com/browse/FIRE-7989 and http://jira.phoenixviewer.com/browse/FIRE-7997 This addresses bug BUG-540. https://jira.secondlife.com/browse/BUG-540 Diffs - indra/llmath/llmath.h f32c39fdfcfe indra/llmath/llquaternion.h f32c39fdfcfe indra/llmath/llquaternion.cpp f32c39fdfcfe indra/llmath/v3math.h f32c39fdfcfe Diff: http://codereview.secondlife.com/r/606/diff/ Testing --- Please go to https://jira.secondlife.com/browse/BUG-540 Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-540: Math updates by Moon Metty. Reviewed by Chieron Tenk.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/606/ --- (Updated Oct. 24, 2012, 10:44 p.m.) Review request for Viewer. Changes --- Fixed the attachment bug. Test/performance results will be posted later. I also updated the repository at https://bitbucket.org/MartinRJ/bug-540 Description --- Improved functions: getEulerAngles ( now: setQuat(F32 roll, F32 pitch, F32 yaw) ) packToVector3 getAngleAxis setAngleAxis shortestArc projected_vec angle_between For details please see: http://jira.phoenixviewer.com/browse/FIRE-7989 and http://jira.phoenixviewer.com/browse/FIRE-7997 This addresses bug BUG-540. https://jira.secondlife.com/browse/BUG-540 Diffs (updated) - indra/llmath/llmath.h f32c39fdfcfe indra/llmath/llquaternion.h f32c39fdfcfe indra/llmath/llquaternion.cpp f32c39fdfcfe indra/llmath/v3math.h f32c39fdfcfe Diff: http://codereview.secondlife.com/r/606/diff/ Testing --- Please go to https://jira.secondlife.com/browse/BUG-540 Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1911: Go-to line function for the internal LSL script editor
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/596/ --- (Updated Sept. 19, 2012, 7:26 a.m.) Review request for Viewer. Changes --- Updated Jira-URLs to point to STORM-1911 instead. Summary (updated) - STORM-1911: Go-to line function for the internal LSL script editor Description --- Repository is here: https://bitbucket.org/MartinRJ/storm-1911 I more or less cloned the search-function and modified the floater via xml (new file: floater_goto_line.xml) to fit for a 'go to line' floater. Also I added a callback to prevalidate the input in the 'go to line' line-editor, so that only numbers can be entered into it. This addresses bug STORM-1911. https://jira.secondlife.com/browse/STORM-1911 Diffs - doc/contributions.txt 7a056d7afeb2 indra/newview/CMakeLists.txt 7a056d7afeb2 indra/newview/llfloatergotoline.h PRE-CREATION indra/newview/llfloatergotoline.cpp PRE-CREATION indra/newview/llpreviewscript.h 7a056d7afeb2 indra/newview/llpreviewscript.cpp 7a056d7afeb2 indra/newview/skins/default/xui/en/floater_goto_line.xml PRE-CREATION indra/newview/skins/default/xui/en/panel_script_ed.xml 7a056d7afeb2 Diff: http://codereview.secondlife.com/r/596/diff/ Testing --- Tested on my local PC with a modded 3.3.4-release3 version. Open a script with at least 300 lines inside inventory, go to menu 'Edit- go to line', enter a number less than 300 into the 'Go to' - field. Expected result: the cursor jumps to the entered line number (column 0). Repeat the test with a script inside an object's content. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-59: Go-to line function for the internal LSL script editor
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/596/ --- (Updated Sept. 18, 2012, 4:11 p.m.) Review request for Viewer. Changes --- I moved LLFloaterGotoLine into a new class file (llfloatergotoline.cpp with the header file llfloatergotoline.h), according to Kelly's review (and updated CMakeLists.txt), added some null-checks in LLFloaterGotoLine and LLFloaterScriptSearch, and I set setCommitOnFocusLost to FALSE (for the lineeditor in LLFloaterGotoLine::postBuild / LLFloaterScriptSearch::postBuild), to prevent unexpected commits/search. Description --- Repository is here: https://bitbucket.org/MartinRJ/bug-59 I more or less cloned the search-function and modified the floater via xml (new file: floater_goto_line.xml) to fit for a 'go to line' floater. Also I added a callback to prevalidate the input in the 'go to line' line-editor, so that only numbers can be entered into it. This addresses bug BUG-59. https://jira.secondlife.com/browse/BUG-59 Diffs (updated) - doc/contributions.txt 7a056d7afeb2 indra/newview/CMakeLists.txt 7a056d7afeb2 indra/newview/llfloatergotoline.h PRE-CREATION indra/newview/llfloatergotoline.cpp PRE-CREATION indra/newview/llpreviewscript.h 7a056d7afeb2 indra/newview/llpreviewscript.cpp 7a056d7afeb2 indra/newview/skins/default/xui/en/floater_goto_line.xml PRE-CREATION indra/newview/skins/default/xui/en/panel_script_ed.xml 7a056d7afeb2 Diff: http://codereview.secondlife.com/r/596/diff/ Testing --- Tested on my local PC with a modded 3.3.4-release3 version. Open a script with at least 300 lines inside inventory, go to menu 'Edit- go to line', enter a number less than 300 into the 'Go to' - field. Expected result: the cursor jumps to the entered line number (column 0). Repeat the test with a script inside an object's content. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-59: Go-to line function for the internal LSL script editor
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/596/ --- (Updated Sept. 18, 2012, 4:12 p.m.) Review request for Viewer. Changes --- New repository: https://bitbucket.org/MartinRJ/storm-1911 Description (updated) --- Repository is here: https://bitbucket.org/MartinRJ/storm-1911 I more or less cloned the search-function and modified the floater via xml (new file: floater_goto_line.xml) to fit for a 'go to line' floater. Also I added a callback to prevalidate the input in the 'go to line' line-editor, so that only numbers can be entered into it. This addresses bug BUG-59. https://jira.secondlife.com/browse/BUG-59 Diffs - doc/contributions.txt 7a056d7afeb2 indra/newview/CMakeLists.txt 7a056d7afeb2 indra/newview/llfloatergotoline.h PRE-CREATION indra/newview/llfloatergotoline.cpp PRE-CREATION indra/newview/llpreviewscript.h 7a056d7afeb2 indra/newview/llpreviewscript.cpp 7a056d7afeb2 indra/newview/skins/default/xui/en/floater_goto_line.xml PRE-CREATION indra/newview/skins/default/xui/en/panel_script_ed.xml 7a056d7afeb2 Diff: http://codereview.secondlife.com/r/596/diff/ Testing --- Tested on my local PC with a modded 3.3.4-release3 version. Open a script with at least 300 lines inside inventory, go to menu 'Edit- go to line', enter a number less than 300 into the 'Go to' - field. Expected result: the cursor jumps to the entered line number (column 0). Repeat the test with a script inside an object's content. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: Added a UI field to display group count in the groups floater, plus code to update it. This adresses BUG-81.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/598/#review1255 --- Ship it! Ship It! - MartinRJ Fayray On Sept. 12, 2012, 1:29 p.m., Lance Corrimal wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/598/ --- (Updated Sept. 12, 2012, 1:29 p.m.) Review request for Viewer. Description --- This patch adds the number of groups you're in to the bottom of the group list. This addresses bug BUG-81. http://jira.secondlife.com/browse/BUG-81 Diffs - indra/newview/llpanelpeople.cpp 40296d1901e6 indra/newview/skins/default/xui/en/panel_people.xml 40296d1901e6 Diff: http://codereview.secondlife.com/r/598/diff/diff Testing --- Testing done in the latest dolphin viewer beta, and in a recent viewer-development fork. The actual implementation has been in Marine Kelleys RLV for a while, and has been adapted with her permission. Thanks, Lance Corrimal ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: Added a UI field to display group count in the groups floater, plus code to update it. This adresses BUG-81.
On Sept. 12, 2012, 11:24 p.m., MartinRJ Fayray wrote: Ship It! Just tested with a modded 3.4.0 viewer-release (from revision 7a056d7afeb2 - https://bitbucket.org/lindenlab/viewer-release/changeset/7a056d7afeb246435e31d06cee2a9a85eac82476). Works as expected. Ship it! - MartinRJ --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/598/#review1255 --- On Sept. 12, 2012, 1:29 p.m., Lance Corrimal wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/598/ --- (Updated Sept. 12, 2012, 1:29 p.m.) Review request for Viewer. Description --- This patch adds the number of groups you're in to the bottom of the group list. This addresses bug BUG-81. http://jira.secondlife.com/browse/BUG-81 Diffs - indra/newview/llpanelpeople.cpp 40296d1901e6 indra/newview/skins/default/xui/en/panel_people.xml 40296d1901e6 Diff: http://codereview.secondlife.com/r/598/diff/diff Testing --- Testing done in the latest dolphin viewer beta, and in a recent viewer-development fork. The actual implementation has been in Marine Kelleys RLV for a while, and has been adapted with her permission. Thanks, Lance Corrimal ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-59: Go-to line function for the internal LSL script editor
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/596/ --- (Updated Sept. 13, 2012, 5:52 a.m.) Review request for Viewer. Changes --- Added the proposed changes(kelly and lance): jumping to the next match on commit (search-and-replace-floater); jump to the line and close on commit (goto-floater). Description --- Repository is here: https://bitbucket.org/MartinRJ/bug-59 I more or less cloned the search-function and modified the floater via xml (new file: floater_goto_line.xml) to fit for a 'go to line' floater. Also I added a callback to prevalidate the input in the 'go to line' line-editor, so that only numbers can be entered into it. This addresses bug BUG-59. https://jira.secondlife.com/browse/BUG-59 Diffs (updated) - doc/contributions.txt 7a056d7afeb2 indra/newview/llpreviewscript.h 7a056d7afeb2 indra/newview/llpreviewscript.cpp 7a056d7afeb2 indra/newview/skins/default/xui/en/floater_goto_line.xml PRE-CREATION indra/newview/skins/default/xui/en/panel_script_ed.xml 7a056d7afeb2 Diff: http://codereview.secondlife.com/r/596/diff/diff Testing --- Tested on my local PC with a modded 3.3.4-release3 version. Open a script with at least 300 lines inside inventory, go to menu 'Edit- go to line', enter a number less than 300 into the 'Go to' - field. Expected result: the cursor jumps to the entered line number (column 0). Repeat the test with a script inside an object's content. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-59: Go-to line function for the internal LSL script editor
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/596/ --- (Updated Sept. 13, 2012, 6:20 a.m.) Review request for Viewer. Description --- Repository is here: https://bitbucket.org/MartinRJ/bug-59 I more or less cloned the search-function and modified the floater via xml (new file: floater_goto_line.xml) to fit for a 'go to line' floater. Also I added a callback to prevalidate the input in the 'go to line' line-editor, so that only numbers can be entered into it. This addresses bug BUG-59. https://jira.secondlife.com/browse/BUG-59 Diffs - doc/contributions.txt 7a056d7afeb2 indra/newview/llpreviewscript.h 7a056d7afeb2 indra/newview/llpreviewscript.cpp 7a056d7afeb2 indra/newview/skins/default/xui/en/floater_goto_line.xml PRE-CREATION indra/newview/skins/default/xui/en/panel_script_ed.xml 7a056d7afeb2 Diff: http://codereview.secondlife.com/r/596/diff/diff Testing --- Tested on my local PC with a modded 3.3.4-release3 version. Open a script with at least 300 lines inside inventory, go to menu 'Edit- go to line', enter a number less than 300 into the 'Go to' - field. Expected result: the cursor jumps to the entered line number (column 0). Repeat the test with a script inside an object's content. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-59: Go-to line function for the internal LSL script editor
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/596/ --- (Updated Sept. 13, 2012, 8:38 a.m.) Review request for Viewer. Changes --- Fix: The current selection needs to be deselected before I can move the cursor to it's new position. Description --- Repository is here: https://bitbucket.org/MartinRJ/bug-59 I more or less cloned the search-function and modified the floater via xml (new file: floater_goto_line.xml) to fit for a 'go to line' floater. Also I added a callback to prevalidate the input in the 'go to line' line-editor, so that only numbers can be entered into it. This addresses bug BUG-59. https://jira.secondlife.com/browse/BUG-59 Diffs (updated) - doc/contributions.txt 7a056d7afeb2 indra/newview/llpreviewscript.h 7a056d7afeb2 indra/newview/llpreviewscript.cpp 7a056d7afeb2 indra/newview/skins/default/xui/en/floater_goto_line.xml PRE-CREATION indra/newview/skins/default/xui/en/panel_script_ed.xml 7a056d7afeb2 Diff: http://codereview.secondlife.com/r/596/diff/ Testing --- Tested on my local PC with a modded 3.3.4-release3 version. Open a script with at least 300 lines inside inventory, go to menu 'Edit- go to line', enter a number less than 300 into the 'Go to' - field. Expected result: the cursor jumps to the entered line number (column 0). Repeat the test with a script inside an object's content. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: BUG-59: Go-to line function for the internal LSL script editor
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/596/ --- Review request for Viewer. Description --- Repository is here: https://bitbucket.org/MartinRJ/bug-59 I more or less cloned the search-function and modified the floater via xml (new file: floater_goto_line.xml) to fit for a 'go to line' floater. Also I added a callback to prevalidate the input in the 'go to line' line-editor, so that only numbers can be entered into it. This addresses bug BUG-59. https://jira.secondlife.com/browse/BUG-59 Diffs - doc/contributions.txt 7ae099f5a764 indra/newview/llpreviewscript.h 7ae099f5a764 indra/newview/llpreviewscript.cpp 7ae099f5a764 indra/newview/skins/default/xui/en/floater_goto_line.xml PRE-CREATION indra/newview/skins/default/xui/en/panel_script_ed.xml 7ae099f5a764 Diff: http://codereview.secondlife.com/r/596/diff/diff Testing --- Tested on my local PC with a modded 3.3.4-release3 version. Open a script with at least 300 lines inside inventory, go to menu 'Edit- go to line', enter a number less than 300 into the 'Go to' - field. Expected result: the cursor jumps to the entered line number (column 0). Repeat the test with a script inside an object's content. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-59: Go-to line function for the internal LSL script editor
On Sept. 11, 2012, 3:24 a.m., Lance Corrimal wrote: Tested it in a viewer-development based build. Works fine for scripts in my inv as well as for scripts in objects. One thing though, hitting enter when entering the line number shgould be enough, clicking the ok button is a bit of a pain. I wanted to keep the design close to the 'search' function. I know you are right about the Enter key, and I am missing that feature in the Search box, as well. It would be cool if we could add that to both, the 'search' and the 'goto' window. Let's talk at the next UG meeting with Oz about that. Thank you much for testing this / and your feedback. - MartinRJ --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/596/#review1251 --- On Sept. 11, 2012, 2:39 a.m., MartinRJ Fayray wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/596/ --- (Updated Sept. 11, 2012, 2:39 a.m.) Review request for Viewer. Description --- Repository is here: https://bitbucket.org/MartinRJ/bug-59 I more or less cloned the search-function and modified the floater via xml (new file: floater_goto_line.xml) to fit for a 'go to line' floater. Also I added a callback to prevalidate the input in the 'go to line' line-editor, so that only numbers can be entered into it. This addresses bug BUG-59. https://jira.secondlife.com/browse/BUG-59 Diffs - doc/contributions.txt 7ae099f5a764 indra/newview/llpreviewscript.h 7ae099f5a764 indra/newview/llpreviewscript.cpp 7ae099f5a764 indra/newview/skins/default/xui/en/floater_goto_line.xml PRE-CREATION indra/newview/skins/default/xui/en/panel_script_ed.xml 7ae099f5a764 Diff: http://codereview.secondlife.com/r/596/diff/diff Testing --- Tested on my local PC with a modded 3.3.4-release3 version. Open a script with at least 300 lines inside inventory, go to menu 'Edit- go to line', enter a number less than 300 into the 'Go to' - field. Expected result: the cursor jumps to the entered line number (column 0). Repeat the test with a script inside an object's content. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1893: 'share' function (in friends-list) doesn't bring up the residents' IM window when it's minimized
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/589/ --- (Updated Sept. 7, 2012, 7:31 p.m.) Review request for Viewer. Changes --- Added a check for a null return. Description --- Repository is here: https://bitbucket.org/MartinRJ/storm-1893 I just added two calls to show() and setVisible() in LLAvatarActions::share to bring the IM window to front even when it's minimized. This addresses bug STORM-1893. https://jira.secondlife.com/browse/STORM-1893 Diffs (updated) - doc/contributions.txt 7ae099f5a764 indra/newview/llavataractions.cpp 7ae099f5a764 Diff: http://codereview.secondlife.com/r/589/diff/diff Testing --- Please see the test plan in the Jira. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: STORM-1893: 'share' function (in friends-list) doesn't bring up the residents' IM window when it's minimized
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/589/ --- Review request for Viewer. Description --- Repository is here: https://bitbucket.org/MartinRJ/storm-1893 I just added two calls to show() and setVisible() in LLAvatarActions::share to bring the IM window to front even when it's minimized. This addresses bug STORM-1893. https://jira.secondlife.com/browse/STORM-1893 Diffs - indra/newview/llavataractions.cpp 4d9106153407 Diff: http://codereview.secondlife.com/r/589/diff/diff Testing --- Please see the test plan in the Jira. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1879: Inventory gear menu remains on screen after floater is closed
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/588/ --- (Updated June 25, 2012, 5:45 a.m.) Review request for Viewer. Changes --- Updated only some comments. Description --- Hide menus when the closed floater has focus. Added a check whether a VisibilityChange-action was triggered via shortcut. Repository: https://bitbucket.org/MartinRJ/storm-1879 This addresses bug STORM-1879. https://jira.secondlife.com/browse/STORM-1879 Diffs (updated) - indra/llui/llfloater.cpp 4d9106153407 indra/llui/lltoggleablemenu.cpp 4d9106153407 Diff: http://codereview.secondlife.com/r/588/diff/diff Testing --- See test plan in JIRA: https://jira.secondlife.com/browse/STORM-1879 Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: STORM-1879: Inventory gear menu remains on screen after floater is closed
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/588/ --- Review request for Viewer. Description --- Hide menus when the closed floater has focus. Added a check whether a VisibilityChange-action was triggered via shortcut. Repository: https://bitbucket.org/MartinRJ/storm-1879 This addresses bug STORM-1879. https://jira.secondlife.com/browse/STORM-1879 Diffs - indra/llui/llfloater.cpp 4d9106153407 indra/llui/lltoggleablemenu.cpp 4d9106153407 Diff: http://codereview.secondlife.com/r/588/diff/diff Testing --- See test plan in JIRA: https://jira.secondlife.com/browse/STORM-1879 Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1892 - Add Apply button to the edit content permission floater
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/587/#review1236 --- Ship it! Ship It! - MartinRJ Fayray On June 23, 2012, 4:34 p.m., Jonathan Yap wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/587/ --- (Updated June 23, 2012, 4:34 p.m.) Review request for Viewer. Description --- Add Apply button to the edit content permission floater, now called Adjust Content Permissions. Minor rewording of title and floater text for clarity and to avoid confusion with STORM-68 (As a Builder, I want that ability to set default permissions on creation of objects, clothing, scripts, notecards, etc.), which is in the pipeline. This addresses bug STORM-1892. https://jira.secondlife.com/browse/STORM-1892 Diffs - doc/contributions.txt 4d9106153407 indra/newview/llfloaterbulkpermission.h 4d9106153407 indra/newview/llfloaterbulkpermission.cpp 4d9106153407 indra/newview/skins/default/xui/en/floater_bulk_perms.xml 4d9106153407 Diff: http://codereview.secondlife.com/r/587/diff/diff Testing --- See test plan in jira Thanks, Jonathan Yap ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: STORM-1844: Block and Ignore buttons on llDialog() menus overlap when there is only one button
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/585/ --- Review request for Viewer. Description --- Removed unnecessary code, replaced unapplicable use of h_pad with a default padding of 4 * HPAD (because I don't see why the padding should depend on the number of ALL buttons including scripted, block and ignore button, and why the block and ignore button should move at all, it acts strange - which can be seen best in case of only one button where h_pad behaves quite weird, and I don't see why one would try approximating max_width with h_pad, it doesn't need to test for an overlap - I should not even get into that if-block ever. It looks to me that during design of the ignore/block buttons someone was planning to put the ignore button into the same - last - row as the dialog button when there was enough space). I believe in the actual version of viewer-release block and ignore would probably always overlap if you change the default button size to something greater than 100. line 356 says in a comment: //assume that h_pad far less than BUTTON_WIDTH which does NOT work when there is only one button. ln 341 or the copy-pasted code in ln 358 can in many cases cause that the ignore button ALWAYS leaves the notification-window, because h_pad is only useful to calculate the padding between the scripted dialog buttons, it doesn't really apply to the block/ignore buttons, I believe. So we can remove ln 342-345 and the copypasted lines 359-362 when we just prevent that the case ever occurs. When we enter the if-block in ln 342, the if-block in ln 359 should automatically get executed also (when the ignore-button is moved because it otherwise would overlap with the window frame, then the block-button must be moved as well) and move by the size/width of the ignore button - but right now there is no case at all where the (wrong) if-block from ln 359-362 gets executed - in the current viewer. Ln. 359 SHOULD BE - (if we would leave the current behaviour) - like: if (mute_btn_left + mute_btn_rect.getWidth() max_width - ignore_btn_width - padding-between-ignore-and-block) - and ln. 361 SHOULD BE like: mute_btn_left = max_width - mute_btn_rect.getWidth() - 2 * HPAD - ignore_btn_width - padding-between-ignore-and-block; An example for the current misbehaviour (that the button gets out of the visible area of the notification window frame) would be if we would extend the window size to 360 (max_width = 360), then buttons-per-row would become '4', and ignore_btn_left would become increased by 90 - (assuming that h_pad doesn't change to much), then the ignore-button would in all cases (1 dialog-button, two dialog buttons, n- dialog buttons) leave the area of the notifications window to the right, and the block-button in some cases too. Another example would be if we changed the default size of the button to 107 (current default is 90). Then the block- and ignore-button would probably always overlap (the block and ignore-buttons would be on the same spot, I believe). It seems that it was presumed that 2*h_pad + 3 buttons = maximum width. The old code can lead to many little bugs if the maximum width changes at some future point. buttons_per_row * BUTTON_WIDTH + (buttons_per_row - 1) * h_pad - was an approximation to max_width, which I have replaced with max_width This addresses bug STORM-1844. Diffs - indra/newview/lltoastnotifypanel.cpp 29143d1fc6fa Diff: http://codereview.secondlife.com/r/585/diff/diff Testing --- Testing repository: https://bitbucket.org/MartinRJ/storm-1844 Looking for feedback! Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1878: Blocking an avatar does not derender worn lights
On June 18, 2012, 12:02 p.m., David Parks wrote: No issues with the code so far, but from inspection I don't think this code will block lights for an avatar that is already muted -- it only blocks lights at the moment you mute another avatar. You'll need to add a check to LLPipeline::setLight that verifies the object is not on the mute list before inserting the object onto gPipeline.mLights. Lights from an avatar that is already muted were blocked before, already. The adressed issue was that you had to teleport away and back to get rid of the lights. I can't 100% tell that I'd really understand the magic behind, but that already worked before. With this fix, the lights disappear instantly (without the need to teleport away/then back). - MartinRJ --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/583/#review1230 --- On June 18, 2012, 11:04 a.m., MartinRJ Fayray wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/583/ --- (Updated June 18, 2012, 11:04 a.m.) Review request for Viewer and David Parks. Description --- An avatar currently gets derendered/invisible when the user blocks it. The local lights attached to that avatar have to become erased too. Repository: https://bitbucket.org/MartinRJ/storm-1878 This addresses bug STORM-1878. https://jira.secondlife.com/browse/STORM-1878 Diffs - indra/newview/llmutelist.cpp 29143d1fc6fa indra/newview/pipeline.h 29143d1fc6fa indra/newview/pipeline.cpp 29143d1fc6fa Diff: http://codereview.secondlife.com/r/583/diff/diff Testing --- Tested with 1-6 local attached lights on the target avatar. Blocking/muting the avatar also disabled the attached lights in all tests successfully. Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: STORM-1845: Move Show HUD Attachments (Alt+Shift+H) from Advanced- Highlighting and Visibility to Me - menu
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/582/ --- Review request for Viewer and Oz Linden. Description --- Moved the option to enable/disable the visibility of HUD attachments to the Me- menu. This addresses bug STORM-1845. Diffs - indra/newview/skins/default/xui/en/menu_viewer.xml 29143d1fc6fa Diff: http://codereview.secondlife.com/r/582/diff/diff Testing --- Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo.
On March 25, 2012, 3:13 a.m., Tofu Buzzard wrote: Thanks for looking at this issue, MartinRJ. The only thing that give me pause for thought is - if the crash is coming from an uncaught exception, the 'right' thing to do seems to be to catch the exception and show the notification you've created then, aborting the login. Any clear reason why this isn't the approach? Does pre-validation give a better user experience? Cheers. @Tofu: you want to remove the un-supported input string from the combo-box and have a valid grid selected instead. Otherwise, if you'd do what you've mentioned what would be the 'right' thing, and only catch the exception, if the user presses Login after that notification he'd get the next error. - MartinRJ --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/#review1184 --- On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/ --- (Updated March 24, 2012, 5:33 a.m.) Review request for Viewer. Description --- FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter. Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ About: When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error (throw LLInvalidGridName(grid);). This fix adds code to: notifications.xml (a warning message text/notification: IllegalGridName), llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). Todo: Maybe edit the notification message, and update the language files. This addresses bug STORM-1818. http://jira.secondlife.com/browse/STORM-1818 Diffs - indra/newview/llpanellogin.cpp acfb0781d850 indra/newview/llviewernetwork.h acfb0781d850 indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 Diff: http://codereview.secondlife.com/r/563/diff/diff Testing --- Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo.
On March 25, 2012, 5:29 a.m., Tofu Buzzard wrote: If the downside of that is that the user doesn't know their grid is invalid until they try to login then I reckon that's fine, but I'll defer to others. @Tofu the malformed grid-address is added PERMANENTLY to the grid-list IMMEDIATELY if you don't prevent this. - MartinRJ --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/#review1186 --- On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/ --- (Updated March 24, 2012, 5:33 a.m.) Review request for Viewer. Description --- FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter. Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ About: When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error (throw LLInvalidGridName(grid);). This fix adds code to: notifications.xml (a warning message text/notification: IllegalGridName), llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). Todo: Maybe edit the notification message, and update the language files. This addresses bug STORM-1818. http://jira.secondlife.com/browse/STORM-1818 Diffs - indra/newview/llpanellogin.cpp acfb0781d850 indra/newview/llviewernetwork.h acfb0781d850 indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 Diff: http://codereview.secondlife.com/r/563/diff/diff Testing --- Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/ --- (Updated March 24, 2012, 5:33 a.m.) Review request for Viewer. Changes --- Rebuilt as STORM-1818 with repository pulled from viewer-release (updated diff-file). Summary (updated) - STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo. Description (updated) --- FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter. Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ About: When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error (throw LLInvalidGridName(grid);). This fix adds code to: notifications.xml (a warning message text/notification: IllegalGridName), llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). Todo: Maybe edit the notification message, and update the language files. This addresses bug STORM-1818. http://jira.secondlife.com/browse/STORM-1818 Diffs (updated) - indra/newview/llpanellogin.cpp acfb0781d850 indra/newview/llviewernetwork.h acfb0781d850 indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 Diff: http://codereview.secondlife.com/r/563/diff/diff Testing --- Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1818: Fix for viewer crash when entering chars other than [a-z0-9-_. ] into the grid-selection combo.
On March 24, 2012, 8:08 a.m., Lance Corrimal wrote: I would like to point out that having all those linden-internal grids in there is utterly useless unless you are inside the linden lab network. How about adding a proper grid manager that supports actually accessible grids instead? @Lance this is only a review of my crash fix, no public discussion. It is only about this severe bug (abnormal program termination). This is not a public user group meeting where we discuss features, please bear in mind that you just demanded me - a volunteer contributor - to add a proper grid manager: How about adding a proper grid manager? The answer is: no! Of course not! - MartinRJ --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/#review1179 --- On March 24, 2012, 5:33 a.m., MartinRJ Fayray wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/563/ --- (Updated March 24, 2012, 5:33 a.m.) Review request for Viewer. Description --- FIX FOR STORM-1818 (https://jira.secondlife.com/browse/storm-1818) Abnormal program termination when I enter an URL to the grid selection combobox (login-screen) and press enter. Repository with fix: https://bitbucket.org/MartinRJ/storm-1818/ About: When entering a malformed grid dns address, the viewer needs to catch the malformed address. Currently it throws an error in a subroutine of the grid-address-handling (llviewernetwork.cpp, function 'addGrid') and crashes without warning due to a thrown error (throw LLInvalidGridName(grid);). This fix adds code to: notifications.xml (a warning message text/notification: IllegalGridName), llviewernetwork.h (a function which checks whether a given grid exists, by name (string): bool getGridExists), llpanellogin.cpp (an include for llviewernetwork.h, and a check against an invalid grid dns address in function onSelectServer). Todo: Maybe edit the notification message, and update the language files. This addresses bug STORM-1818. http://jira.secondlife.com/browse/STORM-1818 Diffs - indra/newview/llpanellogin.cpp acfb0781d850 indra/newview/llviewernetwork.h acfb0781d850 indra/newview/skins/default/xui/en/notifications.xml acfb0781d850 Diff: http://codereview.secondlife.com/r/563/diff/diff Testing --- Test plan: Insert a malformed grid dns address (e.g. http://grid.francogrid.org:8002 which works with some TPVs) into the grid selection combo on the login screen. Expected behaviour: a popup shows up, informing about the malformed address, and the grid selection combo swaps back to the default grid (Agni). Thanks, MartinRJ Fayray ___ 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
