Re: [opensource-dev] Is 'STANDALONE' confusing?

[Jonathan Welch]

> In case where you cannot (or don't want to) use the LL prebuilt binary (e.g.
> fmod) and/or do not have them in some system folder (Find.cmake
> won't find them), you can (or should) specify a path using:
> -D_INCLUDE_DIR= -D_LIBRARY=

I tried many variations of this for Fmod, with "/" and "\" in the path, etc.
in the autobuild configure step but could not get it to work.

>From my configure .bat file:
-DFMOD_INCLUDE_DIR:PATH=e:\olibs\linden\libraries\include

 Directory of e:\olibs\linden\libraries\include

11/24/2010  09:30 AM  .
11/24/2010  09:30 AM  ..
10/28/2005  10:58 AM74,634 fmod.h
11/09/2005  11:59 AM39,872 fmoddyn.h
10/28/2005  10:59 AM 1,721 fmod_errors.h

I still get the error fmod.h not found

Am I missing something obvious or is this supposed to work but doesn't?
___
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] Is 'STANDALONE' confusing?

[Oz Linden (Scott Lawrence)]

On 2011-03-03 1:45, Philippe (Merov) Bossut wrote:
>
> Dropping privately built 3rd party libs though was always a bit of a 
> black art. Now that most 3rd party libs have a public repo available 
> at lindenlab/3p- though, you have another possibility which 
> is to build the package yourself and point autobuild.xml to it using a 
> "file:///" url (don't forget to also change the md5 hash...). 
> That will extract libs and includes and drop them in 
> build-/packages. I experimented with that in OPEN-6 and it works 
> fine.

I'd really like to some experiences from open devs trying to use this 
method.  Essentially, it means maintaining your own version of the 
autobuild configuration file (either in autobuild.xml, being careful not 
to include those changes in any changeset meant to be merged to 
viewer-development, or by using a copy and pointing to the copy either 
with a --config-file option to autobuild or with the 
AUTOBUILD_CONFIG_FILE environment variable).

Even if you build your own prebuilds, you probably won't need to do it 
very often - check them all out once, build each one, construct the 
packages portion of the autobuild.xml file and then copy it into any 
working copy you've got for doing viewer work.  The only time you should 
need to rebuild any of them is when a package is modified either by you 
or from upstream.


___
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] Daily Scrum Summary - Tuesday, March 1

[Anya Kanevsky]

 Sprint 12, ends 03.21.11 Tuesday, March 1 General Notes
--

   - MMOTD: Merov

Team Status
--
 Merov Linden
--

*PAST*

   - MM : pushed last set of fixes, tagged 2.5.1, build.
   - Viewer Coding and Design: interesting ideas shared on possible root of
   the pant flare bug (ECC-49), i.e.: issue could be the H channel of the baked
   texture to be deleted/not uploaded/not decompressed. Alas, the bug started
   to show mid November in dev builds and the kdu upgrade (STORM-151) was
   pulled in Dec 21. So it's not the cause of the problem :(
   - Attended triage meeting

*FUTURE*

   - MM
   - STORM-1023 : fmod : test, test and, hopefully, fix
   - STORM-987 : llimage_libtest: Add image stats output

*IMPEDIMENTS*

   - none

Oz Linden
--

*PAST*

   - Assorted internal meetings
   - Found and fixed a texture cache startup bug (no jira yet)

*FUTURE*

   - Autobuild integration and testing
   - taking most of this afternoon off

*IMPEDIMENTS*

   - none

Q Linden
--

*PAST*

   - process work
   - 2.5.1 release
   - work on storm-26 and its children (keyboard shortcut system)

*FUTURE*

   - Wrapping up for my departure. Last day is Friday.

*IMPEDIMENTS*

   - increasingly dwindling time left at LL

Bao Linden
--

*PAST*

   - OOO for the morning
   - reviewed and tested STORM-864

*FUTURE*

   - re-investigate CTS-478 because wolfpup gave me some of his log files.
   - work on STORM-1026

*IMPEDIMENTS*

   - none

Wolf Linden
--

*PAST*

   - Viewed and commented on all items with "Needs Design" tag

*FUTURE*

   - Follow-up on items that required more info

*IMPEDIMENTS*

   - Need more info/context on VWR-9103 and SVC-6752

Grumpity ProductEngine
--

*PAST*

   - triage
   - release discussions
   - jira wrangling
   - UI study results discussions

*FUTURE*

   - UI results triage to current sprint
   - nyx responded. now need to figure out desired behavior on STORM-326
   - clear review queue in sprint 11
   - meet with Geo

*IMPEDIMENTS*

   - none

Paul ProductEngine
--

*PAST*

   - STORM-357 (Gestures button is in the pressed state after drag-n-drop
   but gestures list isn't visible)
  - WIP. Working on appropriate solution assuming that there is no top
  control any more. Estimate ~ 5-6 hours.

*FUTURE*

   - STORM-357 (Gestures button is in the pressed state after drag-n-drop
   but gestures list isn't visible)

*IMPEDIMENTS*

   - none

Seth ProductEngine
--

*PAST*

   - BUG (STORM-721) Information about resident is displayed incorrectly in
   mini-inspector if there are any resident or group SLURLs
  - Fixed. Posted the patch at the review board.
   - BUG (STORM-989) Texture Picker freezes - does not indicate texture on
   prim
  - Could not reproduce.

*FUTURE*

   - BUG (STORM-989) Texture Picker freezes - does not indicate texture on
   prim
  - Try to reproduce with other scenario.
   - BUG (STORM-268) Texture Edit - Pick Texture Window drops the vertical
   scroll bar

*IMPEDIMENTS*

   - none

Vadim ProductEngine
--

*PAST*

   - STORM-236 (Allow the "Speak" button to be removed, like other buttons):
  - Fixed a couple of bugs. Feeling bad so not much progress.

*FUTURE*

   - Finish with STORM-236.

*IMPEDIMENTS*

   - Need a PO decision for STORM-326 (Persistent water/sky presets).

Andrey ProductEngine
--

*PAST*

   - decided to run I18N test cycle against v-d branch. Started with UI Pass
   against German, French, Portuguese, Spanish
   - reported 21 issues

*FUTURE*

   - finish I18N UI pass against German, French, Portuguese, Spanish
   - 2.5.1 release testing (???)

*IMPEDIMENTS*

   - none

Jonathan Yap
--

*PAST*

   - VWR-24876 (Enable Hints menu entry/preference is confusing)
  - Wrote comment answering Wolf's questions.
   - STORM-1019 (Add ability to display beacons for Media on a Prim objects)
  - Wrote comment in reply to Wolf's question.
   - Mini-hackathon for autobuild+vs2010
  - Short of recompiling Cmake there is no solution for setting a value
  needed to operate the IDE automatically.
  - System still runs out of resources when compiling via IDE.

*FUTURE*

*IMPEDIMENTS*

   - STORM - 956
  - File message_template.msg needs to be pushed into viewer code tree
  from server code tree. Long term solution expected late March.
   - STORM - 1019 Needs "go ahead as-is" or "change it to this" input from
   Wolf.

Wolfpup Lowenhar
--

*PAST*

   - OPEN-37 : was able to get full build run with working viewer but
   noticed that some files in secondlife-bin project need 1+GB of heap space to
   compile when building in RelWithDebInfo, will

[opensource-dev] Review Request: STORM-236 Allow the "Speak" button to be removed, like other buttons

[Vadim ProductEngine]

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

Review request for Viewer.


Summary
---

Cumulative diff of changes made by Wolfpup, Richard and me.

Description:
* Ability to hide the Speak button with the bottom tray context menu.
* Made the chat input resize handle visible, so that the feature is easily 
discoverable.
* Applied Richard's fix to layout panel resizing logic.

My changes:
* Made the Speak button inhibit auto-hiding (that is its original behavior).
  This also fixes numerous glitches with buttons resizing/positioning.
* Fixed resize cursor drawn on a non-Speak button to the right of the chat 
input.
* Reverted wrong changes to LLSpeakButton class:
  - The correct way to hide a button is either removing it from the parent's 
child list
or calling button->setVisible(FALSE).
  - There was no need to narrow the speaking indicator.
* Moved the drag handle icon file to icons/bottomtray/ folder.
* Cleanups.


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


Diffs
-

  doc/contributions.txt 767feb16f05f 
  indra/llui/lllayoutstack.cpp 767feb16f05f 
  indra/newview/llbottomtray.h 767feb16f05f 
  indra/newview/llbottomtray.cpp 767feb16f05f 
  indra/newview/skins/default/textures/bottomtray/ChatBarHandle.png 
767feb16f05f 
  indra/newview/skins/default/textures/textures.xml 767feb16f05f 
  indra/newview/skins/default/xui/en/menu_bottomtray.xml 767feb16f05f 
  indra/newview/skins/default/xui/en/panel_bottomtray.xml 767feb16f05f 

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


Testing
---


Thanks,

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

Re: [opensource-dev] Review Request: (STORM-721) Information about resident is displayed incorrectly in mini-inspector if there are any resident or group SLURLs

[Richard Nelson]

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



indra/llui/lltextbase.cpp


this will still display views that are partially outside of the visible rect

what you want to do iscall mDocumentView->draw() inside the block that has 
the clip operation and then hide the mDocumentView when calling LLUICtrl::draw.




- Richard


On March 1, 2011, 1:53 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/169/
> ---
> 
> (Updated March 1, 2011, 1:53 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fixed text editor to display the embedded widgets only if they are in the 
> currently visible area of a text document.
> 
> 
> This addresses bug STORM-721.
> http://jira.secondlife.com/browse/STORM-721
> 
> 
> Diffs
> -
> 
>   indra/llui/lltextbase.cpp 767feb16f05f 
> 
> Diff: http://codereview.secondlife.com/r/169/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Seth
> 
>

___
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-1037: remove the 'hide url' checkboxes from parcel management

[Oz Linden]

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

Review request for Viewer.


Summary
---

This patch removes the two "Hide URL" checkboxes in the parcel management 
screens.
The corresponding flags are not removed from the messages exchanged with server 
in order to preserve backward compatibility; instead, they are always sent as 
'false' (show the url), and are ignored when received.


This addresses bug storm-1037.
http://jira.secondlife.com/browse/storm-1037


Diffs
-

  indra/llinventory/llparcel.h 8596ccc522d9 
  indra/llinventory/llparcel.cpp 8596ccc522d9 
  indra/newview/llfloaterauction.cpp 8596ccc522d9 
  indra/newview/llpanellandaudio.cpp 8596ccc522d9 
  indra/newview/llpanellandmedia.cpp 8596ccc522d9 
  indra/newview/llpanelnearbymedia.cpp 8596ccc522d9 
  indra/newview/skins/default/xui/da/floater_about_land.xml 8596ccc522d9 
  indra/newview/skins/default/xui/de/floater_about_land.xml 8596ccc522d9 
  indra/newview/skins/default/xui/en/floater_about_land.xml 8596ccc522d9 
  indra/newview/skins/default/xui/es/floater_about_land.xml 8596ccc522d9 
  indra/newview/skins/default/xui/fr/floater_about_land.xml 8596ccc522d9 
  indra/newview/skins/default/xui/it/floater_about_land.xml 8596ccc522d9 
  indra/newview/skins/default/xui/ja/floater_about_land.xml 8596ccc522d9 
  indra/newview/skins/default/xui/nl/floater_about_land.xml 8596ccc522d9 
  indra/newview/skins/default/xui/pl/floater_about_land.xml 8596ccc522d9 
  indra/newview/skins/default/xui/pt/floater_about_land.xml 8596ccc522d9 

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


Testing
---

Verified that the checkboxes are no longer present, and that media can be set 
using either dialog.


Thanks,

Oz

___
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-1038: crash in texture cache pruning

[Oz Linden]

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

Review request for Viewer.


Summary
---

If the viewer is started when the maximum number of items allowed in the 
texture cache is greater than the number actually in the cache, the viewer 
crashes.


This addresses bug storm-1038.
http://jira.secondlife.com/browse/storm-1038


Diffs
-

  indra/newview/lltexturecache.cpp 8596ccc522d9 

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


Testing
---

Since I found this by somehow getting into the over-full condition when working 
on an unrelated issue, I found myself unable to launch my viewer.  One this fix 
was applied, launching worked just fine.


Thanks,

Oz

___
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-1038: crash in texture cache pruning

[Thickbrick Sleaford]

On Thursday 03 March 2011 22:12:54 Oz Linden wrote:
> http://jira.secondlife.com/browse/storm-1038
...
> Diff: http://codereview.secondlife.com/r/172/diff

Isn't this the same bug as the one patched by Aleric in VWR-24337? (I haven't 
followed the logic through, but it seems to trigger the same assert.)

See:
https://jira.secondlife.com/browse/VWR-24337
https://codereview.secondlife.com/r/93/

-- 
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

Re: [opensource-dev] Review Request: (STORM-721) Information about resident is displayed incorrectly in mini-inspector if there are any resident or group SLURLs

[Seth ProductEngine]

> On March 3, 2011, 11:45 a.m., Richard Nelson wrote:
> > indra/llui/lltextbase.cpp, line 604
> > 
> >
> > this will still display views that are partially outside of the visible 
> > rect
> > 
> > what you want to do iscall mDocumentView->draw() inside the block that 
> > has the clip operation and then hide the mDocumentView when calling 
> > LLUICtrl::draw.
> > 
> >

The clip rect in the block with drawText() call is not enabled for the editors 
without a scroller and even enabling it and calling mDocumentView->draw() 
inside that block cuts off the bottom of the last visible line of text (see 
screenshot at 
https://jira.secondlife.com/secure/attachment/48565/clipped_text.png).

With allow_scroll="false" & clip_partial="true" settings for the editor we lose 
one text line and if there are icons on the first line they will be clipped 
anyway because the top of such icons exceeds the top limit of the visible rect.


- Seth


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


On March 1, 2011, 1:53 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/169/
> ---
> 
> (Updated March 1, 2011, 1:53 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fixed text editor to display the embedded widgets only if they are in the 
> currently visible area of a text document.
> 
> 
> This addresses bug STORM-721.
> http://jira.secondlife.com/browse/STORM-721
> 
> 
> Diffs
> -
> 
>   indra/llui/lltextbase.cpp 767feb16f05f 
> 
> Diff: http://codereview.secondlife.com/r/169/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Seth
> 
>

___
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-1038: crash in texture cache pruning

[Cron Stardust]

> On None, Oz Linden wrote:
> > indra/newview/lltexturecache.cpp, line 1439
> > 
> >
> > This was the crash - note that it is exactly the same condition that 
> > would normally get you out of the loop above.
> >

Any idea why this assert was there in the first place?  It looks to me like the 
code was escaping the loop on an error clause (which would explain why it was 
done in "if() break;" style,) and then asserting on that error.  If I'm right 
then why there wasn't any comments on those lines explaining the reasoning 
escapes me...  Such logic is far from obvious! :P

Note also that if there were no entries to purge (entries_to_purge < 0 because 
the above code found enough empty entries to successfully reduce the cache size 
enough,) and purge_list is empty (as it should be at this point in the code,) 
then the assert would fire.  Of course, I'm just trying to determine the 
reasoning behind the assert in the first place, and exercise my code reverse 
engineering skills. (The last few classes haven't had an ounce of real code, so 
I'm bored... :P )

PS: While you're in this territory, you might want to put some spaces around 
the subtraction operator inside the parenthesis on line 1426.  It looked too 
much like a dash to me on first glance!


- Cron


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


On March 3, 2011, 12:12 p.m., Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/172/
> ---
> 
> (Updated March 3, 2011, 12:12 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> If the viewer is started when the maximum number of items allowed in the 
> texture cache is greater than the number actually in the cache, the viewer 
> crashes.
> 
> 
> This addresses bug storm-1038.
> http://jira.secondlife.com/browse/storm-1038
> 
> 
> Diffs
> -
> 
>   indra/newview/lltexturecache.cpp 8596ccc522d9 
> 
> Diff: http://codereview.secondlife.com/r/172/diff
> 
> 
> Testing
> ---
> 
> Since I found this by somehow getting into the over-full condition when 
> working on an unrelated issue, I found myself unable to launch my viewer.  
> One this fix was applied, launching worked just fine.
> 
> 
> Thanks,
> 
> Oz
> 
>

___
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-1038: crash in texture cache pruning

[Cron Stardust]

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


As Thickbrick just noted on OSDev, this looks to be practically identical to 
https://codereview.secondlife.com/r/93

- Cron


On March 3, 2011, 12:12 p.m., Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/172/
> ---
> 
> (Updated March 3, 2011, 12:12 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> If the viewer is started when the maximum number of items allowed in the 
> texture cache is greater than the number actually in the cache, the viewer 
> crashes.
> 
> 
> This addresses bug storm-1038.
> http://jira.secondlife.com/browse/storm-1038
> 
> 
> Diffs
> -
> 
>   indra/newview/lltexturecache.cpp 8596ccc522d9 
> 
> Diff: http://codereview.secondlife.com/r/172/diff
> 
> 
> Testing
> ---
> 
> Since I found this by somehow getting into the over-full condition when 
> working on an unrelated issue, I found myself unable to launch my viewer.  
> One this fix was applied, launching worked just fine.
> 
> 
> Thanks,
> 
> Oz
> 
>

___
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-1044 Improved message template checking.

[Kelly Washington]

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

Review request for Viewer.


Summary
---

Improved message template checking.
* If no changes have been made to the message template the check is local only 
and trivial.
* If changes have been made to the message template then compatibility is 
verified on the first build after the change instead of when they package.
* Automated systems can use --force to force full message template verification


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


Diffs
-

  indra/cmake/TemplateCheck.cmake 3683d7c533f9 
  indra/newview/CMakeLists.txt 3683d7c533f9 
  scripts/messages/message_template.msg.sha1 PRE-CREATION 
  scripts/template_verifier.py 3683d7c533f9 

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


Testing
---

* Built the viewer and verified only the hash is checked.
* Changed the template and verified full verification happens and a new sha1 
saved.


Thanks,

Kelly

___
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-1037: remove the 'hide url' checkboxes from parcel management

[Brian McGroarty]

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

Ship it!


Looks to do what it says on the tin, and helps resis make better-informed 
choices about what media requests they trust

- Brian


On March 3, 2011, 11:52 a.m., Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/171/
> ---
> 
> (Updated March 3, 2011, 11:52 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This patch removes the two "Hide URL" checkboxes in the parcel management 
> screens.
> The corresponding flags are not removed from the messages exchanged with 
> server in order to preserve backward compatibility; instead, they are always 
> sent as 'false' (show the url), and are ignored when received.
> 
> 
> This addresses bug storm-1037.
> http://jira.secondlife.com/browse/storm-1037
> 
> 
> Diffs
> -
> 
>   indra/llinventory/llparcel.h 8596ccc522d9 
>   indra/llinventory/llparcel.cpp 8596ccc522d9 
>   indra/newview/llfloaterauction.cpp 8596ccc522d9 
>   indra/newview/llpanellandaudio.cpp 8596ccc522d9 
>   indra/newview/llpanellandmedia.cpp 8596ccc522d9 
>   indra/newview/llpanelnearbymedia.cpp 8596ccc522d9 
>   indra/newview/skins/default/xui/da/floater_about_land.xml 8596ccc522d9 
>   indra/newview/skins/default/xui/de/floater_about_land.xml 8596ccc522d9 
>   indra/newview/skins/default/xui/en/floater_about_land.xml 8596ccc522d9 
>   indra/newview/skins/default/xui/es/floater_about_land.xml 8596ccc522d9 
>   indra/newview/skins/default/xui/fr/floater_about_land.xml 8596ccc522d9 
>   indra/newview/skins/default/xui/it/floater_about_land.xml 8596ccc522d9 
>   indra/newview/skins/default/xui/ja/floater_about_land.xml 8596ccc522d9 
>   indra/newview/skins/default/xui/nl/floater_about_land.xml 8596ccc522d9 
>   indra/newview/skins/default/xui/pl/floater_about_land.xml 8596ccc522d9 
>   indra/newview/skins/default/xui/pt/floater_about_land.xml 8596ccc522d9 
> 
> Diff: http://codereview.secondlife.com/r/171/diff
> 
> 
> Testing
> ---
> 
> Verified that the checkboxes are no longer present, and that media can be set 
> using either dialog.
> 
> 
> Thanks,
> 
> Oz
> 
>

___
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-236 Allow the "Speak" button to be removed, like other buttons

[Wolfpup Lowenhar]

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

Ship it!


I built the repository provided in the JIRA locally and have tested this on my 
system works for Windows 7 32-bit. There is still an intermittent spacing issue 
that corrects itself if you cycle Voice when the Speak Button is not next to 
the chat panel.


indra/newview/llbottomtray.h


bool instead of BOOL? (code consistence)



indra/newview/llbottomtray.cpp


+1 you documented this one.



indra/newview/llbottomtray.cpp


Documentation?



indra/newview/llbottomtray.cpp


Document?



indra/newview/llbottomtray.cpp


Mentioning this in the preceding comment would be nice.



indra/newview/llbottomtray.cpp


Documentation ?



indra/newview/llbottomtray.cpp


Here we know why this is being done. +1 documented



indra/newview/llbottomtray.cpp


This looks good but would help if there was some documentation here 
explaining this function and exactly why it is needed.


- Wolfpup


On March 3, 2011, 10:33 a.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/170/
> ---
> 
> (Updated March 3, 2011, 10:33 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Cumulative diff of changes made by Wolfpup, Richard and me.
> 
> Description:
> * Ability to hide the Speak button with the bottom tray context menu.
> * Made the chat input resize handle visible, so that the feature is easily 
> discoverable.
> * Applied Richard's fix to layout panel resizing logic.
> 
> My changes:
> * Made the Speak button inhibit auto-hiding (that is its original behavior).
>   This also fixes numerous glitches with buttons resizing/positioning.
> * Fixed resize cursor drawn on a non-Speak button to the right of the chat 
> input.
> * Reverted wrong changes to LLSpeakButton class:
>   - The correct way to hide a button is either removing it from the parent's 
> child list
> or calling button->setVisible(FALSE).
>   - There was no need to narrow the speaking indicator.
> * Moved the drag handle icon file to icons/bottomtray/ folder.
> * Cleanups.
> 
> 
> This addresses bug STORM-236.
> http://jira.secondlife.com/browse/STORM-236
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 767feb16f05f 
>   indra/llui/lllayoutstack.cpp 767feb16f05f 
>   indra/newview/llbottomtray.h 767feb16f05f 
>   indra/newview/llbottomtray.cpp 767feb16f05f 
>   indra/newview/skins/default/textures/bottomtray/ChatBarHandle.png 
> 767feb16f05f 
>   indra/newview/skins/default/textures/textures.xml 767feb16f05f 
>   indra/newview/skins/default/xui/en/menu_bottomtray.xml 767feb16f05f 
>   indra/newview/skins/default/xui/en/panel_bottomtray.xml 767feb16f05f 
> 
> Diff: http://codereview.secondlife.com/r/170/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> 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

Re: [opensource-dev] Review Request: storm-1038: crash in texture cache pruning

[Aleric Inglewood]

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


You want to know what I think...

https://codereview.secondlife.com/r/93/
has been waiting to finally be merged for 6 weeks now.


- Aleric


On March 3, 2011, 12:12 p.m., Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/172/
> ---
> 
> (Updated March 3, 2011, 12:12 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> If the viewer is started when the maximum number of items allowed in the 
> texture cache is greater than the number actually in the cache, the viewer 
> crashes.
> 
> 
> This addresses bug storm-1038.
> http://jira.secondlife.com/browse/storm-1038
> 
> 
> Diffs
> -
> 
>   indra/newview/lltexturecache.cpp 8596ccc522d9 
> 
> Diff: http://codereview.secondlife.com/r/172/diff
> 
> 
> Testing
> ---
> 
> Since I found this by somehow getting into the over-full condition when 
> working on an unrelated issue, I found myself unable to launch my viewer.  
> One this fix was applied, launching worked just fine.
> 
> 
> Thanks,
> 
> Oz
> 
>

___
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: Nearby chat history is displaying both Display Names and user.names when the Display Name is not changed from default.

[ardylay]

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

(Updated March 3, 2011, 9:25 p.m.)


Review request for Viewer.


Summary
---

https://jira.secondlife.com/browse/VWR-24917
I have been finding the redundent display of functionally equivalent names in 
nearby chat history and IM history quite tiresome.
Simple proposal: If the resident's Display Name is at the default then do not 
display their user.name.
https://bitbucket.org/ArdyLay/viewer-development-vwr-24917

Change is to: LLAvatarName::getCompleteName

I find the following Callers:
LLAvatarActions::requestFriendshipDialog
LLAvatarActions::startIM
LLAvatarActions::startCall
LLIMModel::LLIMSession
LLIMModel::logToFile
LLPostponedNotification::onAvatarNameCache
LLUrlEntryAgent::onAvatarNameCache
LLUrlEntryAgent::getLabel
LLUrlEntryAgentCompleteName::getName

// Callback for name resolution of a god/estate message
llviewermessage.cpp(2149): args["NAME"] = av_name.getCompleteName();
llviewermessage.cpp(2154): chat.mText = av_name.getCompleteName() + ": " + 
message;

static void on_avatar_name_cache_toast ...
llimview.cpp(108): args["FROM"] = av_name.getCompleteName();

Some of these make me wonder if this change will cause some defects and should 
be implimented as a seperate function.


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


Diffs (updated)
-

  doc/contributions.txt c10d5e37db1e 
  indra/llcommon/llavatarname.cpp c10d5e37db1e 

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


Testing
---

I have been using this trivial change and have shared it with a friend, via 
bitbucket.  We have both built the viewer on Windows 7 and find the resulting 
reduction in redundent text in chat and IM history on screen to be very helpful.


Thanks,

ardy.lay

___
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] PO Test build (sprint 12)

[Philippe (Merov) Bossut]

Hi,

Keeping up good habits, I created the first test build of sprint 12:

http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/222709/index.html

This build contains fixes for the following:
* STORM-28 : As a User, I want the ability to send my calling card to
others.
* STORM-236 : Allow the "Speak" button to be removed, like other buttons
* STORM-494 : Message Well window is undocked while opening Side bar
* STORM-990 : The arrow in the bottom right of the Landmark panel points
down
* STORM-1015 : Unable to select right Login Landmark when its name is not
unique
* STORM-1020 : It is sometimes necessary to press ALT+CTRL+D twice to get
the Debug menu on the login screen
* STORM-1036 : Remove the unused "How to create a new Classified ad"
notification from XUI

Test welcome. Please report issues in the JIRAs themselves. If you have
credential to "PO Approve" those JIRAs, please do.

Cheers,
- Merov
___
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] Is 'STANDALONE' confusing?

[Philippe (Merov) Bossut]

Hi Jonathan,

On Thu, Mar 3, 2011 at 2:31 AM, Jonathan Welch  wrote:

> > In case where you cannot (or don't want to) use the LL prebuilt binary
> (e.g.
> > fmod) and/or do not have them in some system folder (Find.cmake
> > won't find them), you can (or should) specify a path using:
> > -D_INCLUDE_DIR= -D_LIBRARY=
>
> I tried many variations of this for Fmod, with "/" and "\" in the path,
> etc.
> in the autobuild configure step but could not get it to work.
>
> From my configure .bat file:
> -DFMOD_INCLUDE_DIR:PATH=e:\olibs\linden\libraries\include
>
>  Directory of e:\olibs\linden\libraries\include
>
> 11/24/2010  09:30 AM  .
> 11/24/2010  09:30 AM  ..
> 10/28/2005  10:58 AM74,634 fmod.h
> 11/09/2005  11:59 AM39,872 fmoddyn.h
> 10/28/2005  10:59 AM 1,721 fmod_errors.h
>
> I still get the error fmod.h not found
>
> Am I missing something obvious or is this supposed to work but doesn't?
>

On another thread, Twisted was reporting success with using the following:

autobuild --debug configure -c VC10msbuildRelWithDebInfo --
-DLL_TESTS:BOOL=OFF -DFMOD:BOOL=ON -DFMOD_INCLUDE_DIR=C:\Dev\fmod
-DFMOD_LIBRARY=C:\Dev\fmod

Of course, we are talking about using autobuild here. I suppose this is what
you've been trying to get going as well.

My advice would be:
- Try adding the -DFMOD_INCLUDE_DIR=E:\olibs\linden\libraries\include on the
command line directly.
- If you're not using a Cygwin command line, add it in the relevant
configuration in autobuild.xml

Cheers,
- Merov
___
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