Second Life Wiki - User contributions [en]

User:Balp Allen

2009-09-09T20:18:52Z

Balp Allen: Created page with 'Hacking in Emerald GreenLife. DJing at Carange and Blacklist. {{Plurker}}'

Hacking in Emerald GreenLife.

DJing at Carange and Blacklist.

{{Plurker}}

Talk:Viewer Visual Update

2008-04-18T13:29:57Z

Balp Allen: /* Feedback and Ideas */

== Thanx for the feedback thus far... ==
Hello and thanks for the comments! I'm involved with this project, codename "Dazzle", insofar as helping the Rx Team get the word out to our community. I haven't read all of these comments in close detail yet, but I appreciate not just the content, but the presentation too.

LordJason Kiesler — thanks for embedding that graphic to communicate what you think of about the button gradients. If anyone else wants to contribute screenshot mockups, please, you're more than welcome. Since this is a ''visual'' update, those type of aids help.

I also had [http://www.flickr.com/photos/torley/1801183618/ some nice comments on my Flickr photostream], and will be encouraging more... and responding in kind. Appreciatively yours! --[[User:Torley Linden|Torley Linden]] 16:28, 1 November 2007 (PDT)

Great, [http://torley.com/introducing-second-lifes-dazzle-user-interface-update even more Dazzle feedback on my personal blog!] --[[User:Torley Linden|Torley Linden]] 08:04, 5 November 2007 (PST)

i love the new version :O is fantastic 
the near me bug is fixed exellent 
now i'm bugfixing my purple version 
really a good job benjamin :D --[[User:Aliceinwire Bleac|Aliceinwire Bleac]] 04:56, 12 November 2007 (PST)

== Feedback and Ideas ==
*As far as I'm concerned, one of the gold standard issues for interface usability in this or any other application is the ability to pull pop up menus off the interface. If one can't do that, it doesn't matter how pretty they look; they block content and make working in the interface overly difficult. Gotta be able to pull stuff off the interface or it's more of the same with new candy colors. [Professor Beliveau/5:18SL 10/30/07]
* In the Mac instructions, if you start with 'Make a copy of the Second Life application with "Duplicate" and rename it "Second Life Visual Update"...' and move on from there then the "uninstall" step won't be needed, and people can more easily compare the two. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:14, 22 October 2007 (PDT)

* Great work on the graphics! Definitely shows off the potential for what can be done.

Well how novel: ripping off the Mac OS X metallic buttons and giving them an Aqua feel... Well, don't stop there. Read Apple's Human Interface Guidelines and implement them. Then we'll not only have the feel too, but then the whole thing may work as standard instead of being buggy, bloated, roll your own code. We would have international settings and keyboards that worked, standard window behaviour, one menu bar not two, and text editing handling that worked properly, and properly transposed keyboard shorcuts. Get that stuff sorted first then you can think of moving on to skinning.
: I would like to point out, that SecondLife client is Cross-Platform. If they stuck to the Mac guidelines, then it wouldn't fit windows or linux. To be honest, as SecondLife is effectively a game, the interface has to be a roll your own (Read Apples guidelines, it actually says that somewhere) --[[User:Nik Woodget|Nik Woodget]] 02:37, 22 October 2007 (PDT)

* Just to introduce the conservative voice *8) while I greatly appreciate thought going into the viewer and all, I wouldn't say that making the colors prettier and the buttons and icons slicker-looking would be where I'd focus efforts if it was me. Give me back a tearoffable friends list, let me tear off and move around llDialog() / GroupNotice style dropdowns, make the viewer notice and tell me something useful when packets-in-per-second drops to zero, and other actual functional enhancements would do me a world more good than shinier-looking buttons... [[User:Dale Innis|Dale Innis]] 11:06, 13 November 2007 (PST)

* Great look, how ever the big problems in the gui layout are net even addressed in this preview. Friends and group was so much more easier to use before the voice release. I really like to get that in the 18.4 viewer nice Linux bug fixes but no working friends list yet in that version. Voice i guess that will come some ware around 2010 at best. I'm not asking for much just two patches from nicholaz. (and probably a hard admittance from someone onside Linden that new look with friends inside the IM window was a bad idea.) --[[User:Balp Allen|Balp Allen]] 00:36, 14 November 2007 (PST)

* I Like to add to what I said in November, When I said great look, I assumed that the bad contrast issues was going to get solved before going close to RC status, that this skinnable should be skinnable long before RC status. I took the look as an example on what it could look like not the main and only way. To bad the look today haven't fixed any of the major issues. Even if we got a friend s list finally long be fore I hoped on it (and outside dazzle). I'm afraid Dazzle will come and force many users to stay at 1.19 until the day 1.2x something becomes mandatory, many others just screaming and being irritated. There is a patch in the Nicholaz version that could be simply tuned to make all the dazzle, oldstyle look files come into two directories skins\dazzle, skins\oldstyle. To make users more happy I would suggest that LL looks at this issue and slows down on the release plan. 1.18.6 was backed away when it didn't work, It's no shame in makeing something ready before releasing and maybe Dazzle is ready by it's project goals, however phase one with only the new look is for most resident's only halfway. But now home to test VWR-4575 fix. --[[User:Balp Allen|Balp Allen]] 06:29, 18 April 2008 (PDT)

== Feedback on the style itself ==

*The problem I'm having is with the fact that most of the text in search results is white on a bright blue/gray background, which makes it hard to read. Also, text in profiles and (non-editable) group descriptions is difficult to read for the same reason. I think that adding more contrast would definitely improve the usability (not to mention the accessibility) of this skin. -- ????

The theme seems to be mostly based on one of a variety of "glossy" 3d themes that have become popular in UNIX/X11 environments. I would much rather see the glossiness eliminated and something less overpowering being used as inspiration.

Specific points:
:* With a light background ALL the text needs to be dark.
:* The window close and minimize buttons look smaller in this style, even if they aren't, and I keep slowing down to hit them more precisely.
:* The translucent menu bar is an improvement. It needs to extend under the menus themselves, of course. The backdrop for the button bars on the bottom should be translucent as well, for symmetry... and with the new style I don't think the little "loops" over the buttons above the chat bar are really useful.
:* The glossiness of the buttons is a problem, and they also look more like tabs than buttons. A flatter more "matte" style would work better.
:* The slight border around the chat and nametags is VERY nice.
:* The 3d look of hover text is not so good, I think because it's light. The light colored pie menu is ''really'' a problem.
:* The inventory and appearance editor seem significantly less professional.
:At the moment I think the original style is preferrable. I would say that the dark color scheme works better, particularly for translucent windows... if the ghosted windows could turn dark (but with light text) that would work, but that's probably more than XUI can handle. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:25, 22 October 2007 (PDT)

*I'm not a fan of square buttons.
*Like Argent I struggle with some of the light backgrounds
*Would it be possible to have an instruction page? This file does... for all the images. I know its possible to open them all, and I will, but pointers for how to tweak what be nice. I'm going to try a nicer (for my eyes) skin with greens, similar to the theme I've got on my mac menus, and hack some buttons, but it will take a while to get right because I'm flying blind (particularly for .j2c's that don't automatically preview for me). --[[User:Eloise Pasteur|Eloise Pasteur]] 06:53, 22 October 2007 (PDT)
:* Good print, J2Cs aren't well supported in bitmap editors yet. -- [[User:Argent Stonecutter|Argent Stonecutter]] 09:14, 22 October 2007 (PDT)
:* In the textures folder is a textures.xml file. This is the mapping {purpose}.tga -> UUID.{any extension} --[[User:Thraxis Epsilon|Thraxis Epsilon]] 11:51, 22 October 2007 (PDT)

I too struggle with the chat history and permission/worn status in inventory, as it's light text on a light background, but I hope you'll correct this by darkening the text. I like dark text on a light background very much... but OTOH I can understand how in a dark environment, you might want the opposite, sort of like the dashboard on your car... can it be made skinnable, so people can have what they prefer? (Changing with time of day or ambient lighting is probably a bit much to ask for, but would be very cool.) --[[User:Melissa Yeuxdoux|Melissa Yeuxdoux]] 16:23, 2 November 2007 (PDT)

=== Similarity to Mac/Aqua ===
Well how novel: ripping off the Mac OS X metallic buttons and giving them an Aqua feel... Well, don't stop there. Read Apple's Human Interface Guidelines and implement them. Then we'll not only have the feel too, but then the whole thing may work as standard instead of being buggy, bloated, roll your own code. We would have international settings and keyboards that worked, standard window behaviour, one menu bar not two, and text editing handling that worked properly, and properly transposed keyboard shorcuts. Get that stuff sorted first then you can think of moving on to skinning.
: I would like to point out, that SecondLife client is Cross-Platform. If they stuck to the Mac guidelines, then it wouldn't fit windows or linux. To be honest, as SecondLife is effectively a game, the interface has to be a roll your own (Read Apples guidelines, it actually says that somewhere) --[[User:Nik Woodget|Nik Woodget]] 02:37, 22 October 2007 (PDT)
:: I don't think it looks Mac-like at all. In fact while Apple popularized the glossy look the "shiny metallic" look isn't really their schtick, and they have been moving away from the aggressive glossiness of the early OS X versions to a smoother and more professional look in Panther and Tiger. -- [[User:Argent Stonecutter|Argent Stonecutter]] 18:02, 22 October 2007 (PDT)
:::I personally wouldn’t complain if they implemented as much of Apple’s HIG as possible. I wouldn’t expect them to get rid of the in-window menubar, but it would be nice if things like keyboard layouts worked properly. —[[User:Frungi Stastny|Frungi Stastny]] 06:53, 23 October 2007 (PDT)

=== Icons ===

The icons representing prims in the object builder are too small. It is quite difficult to distinguish between similar prims as, for example, the cone and the semicone.--[[User:Eadoin Welles|Eadoin Welles]] 10:22, 22 October 2007 (PDT)

I'm not loving it... Although I do like some of the icons but color wise and color balance theme are killing my eyes. The whole "gloss jem" buttons from Window Vista and OS Mac got really really old so fast. For me, I'd like a dark theme. Something more like this theme. [[http://www.wincustomize.com/zoom.aspx?skinid=4617&libid=1]] --[[User:Vincent Nacon|Vincent Nacon]] 12:32, 22 October 2007 (PDT)

I don't think the icons on the map or in other windows should be changed from the standard client unless absolutely necessary... and again I don't think that encapsulating the icons is really a good idea. -- [[User:Argent Stonecutter|Argent Stonecutter]] 18:06, 22 October 2007 (PDT)

I really like the new icons in the inventory, they look much nicer than the old ones, however, the icons on the map, and the new ones in the title bar are really hard to read. Even from 5 inches away I still can't tell what that thing in the classifieds icon is supposed to be. It looks like two bars and a clock or a lip. The title bar land for sale icon is also really hard to read since you can't really see the $ unless you get really close to the screen. And I think the telehub icon might have too much detail in it for being so small. When you zoom all the way out on the map and see them all it gets really messy. --[[User:Kevin Susenko|Kevin Susenko]] 08:42, 8 December 2007 (PST)

I have to say I am underwhelmed by the icon set. Have you considered the [http://en.wikipedia.org/wiki/Tango_Desktop_Project Tango Desktop Project]? The Tango Project seeks to create a consistent graphical user interface experience across applications and platforms. IMHO, the quality of their icon sets is very high. Have a look at the icon sets and [http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines style guidelines on their website]. — [[User:Yuu Nakamichi|Yuu Nakamichi]] 15:21, 2 November 2007 (PDT)

== Additional suggestions ==
This section should be kept for suggestions that are really beyond the scope of a theme change.

=== Multiple Monitor Support ===

Would like more than anything to see the UI windows capable of being moved onto a second monitor off the main viewer window. Now that would be very cool and make life a whole lot easier.
:This would also mean making that the second life viewer would have to use system controls. Again its a pain for cross-platform software. Though not impossible. --[[User:Nik Woodget|Nik Woodget]] 02:38, 22 October 2007 (PDT)
::Why would this require using system controls ?
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 06:59, 22 October 2007 (PDT)
:::The UI in Second Life is part of the OpenGL rendering pipeline. In order for the controls to be seperated from the main window they would have to be contained in seperate OS controls. Maybe not system independent controls, perhaps custom controls rendered into borderless windows might work. --[[User:Nik Woodget|Nik Woodget]] 02:08, 28 November 2007 (PST)
:::: Aren't there free open-source cross platform systems already out there to do stuff like that?--[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 05:32, 13 November 2007 (PST)
::::: Possibly, do you have any you can suggest? --[[User:Nik Woodget|Nik Woodget]] 02:08, 28 November 2007 (PST)

:Let me add my support for multiple monitors with one dedicated to menus and controls to keep the main view screen wide open. This would be huge. [[User:Ralph Doctorow|Ralph Doctorow]] 07:33, 25 January 2008 (PST)

:In addition to people with large or multiple monitors, people with slower computers would be able to comfortably run the main 3D viewer window at 640x480, and keep text-only windows off to the side for greater visibility. Fancy "skin" effects aside, there's no need for most of the windows to be OpenGL-accelerated. [[User:Creem Pye|Creem Pye]] 11:26, 31 January 2008 (PST)

=== Mac Support ===

For the Mac port, at least, the way that command and control are reversed is really hard to deal with. It would be nice if there was an option to reverse the command and control keys ''for XUI only''. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:07, 22 October 2007 (PDT)

Whilst we're talking about this - can we add a request for a proper implementation of the Mac GUIs, without the irritating internal menus as well please. Swap the menu bar menus the way the GUI guidelines suggest. It's a different code base after all. I may have got used to this structure, but it's one bit of muscle memory I'd be very happy to get rid of! --[[User:Eloise Pasteur|Eloise Pasteur]] 15:56, 22 October 2007 (PDT)

=== Widgets ===

I like the new interface. It is surely better than the black one but, by the way, the real value would be to have a choice of skins which, in my understanding, is the main goal of this test. I think that another improvement might be to have the possibility to add gadgets. For example, I would like to have, close to the PDT time, also the local time, since most of events that I prepare are located in my country, and I prefer to use local time rather than useless PDT time. Rather than adding this feature, which may be of no interest to USA people and surely not at all to California people, you may give us the possibility to create gadgets, like in Google or Vista. So I could develop a small gadget to see time in various timezones, another one that automatically convert Linden dollars to various currencies, and so forth. By facilitating the development of user gadgets, you would dramatically improve the SL interface without having to develop them yourself. IMHO Greetings from Rome, Italy --[[User:Eadoin Welles|Eadoin Welles]] 10:19, 22 October 2007 (PDT)

==== Vector Graphics Widgets ====

Would like to see a flash layer, where flash widgets could communicate to the UI via an API and either replace or partially replace bits and pieces of it. This could be a big market for companies wishing to have customized clients but still take advantage of Linden Labs robust source.
:I would actively NOT want to see a layer that can only be programmed with a closed system like flash. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:07, 22 October 2007 (PDT)
::SVG + Javascript would work- uBrowser would be the place to start with that.
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 06:59, 22 October 2007 (PDT)
:::That's one approach. Javascript based controls are used in a number of programs: Firefox (XUL), Mac OS (Dashboard), Yahoo Widgets (for that matter Adobe's Actionscript has converged on Javascript). I'm not sure that SVG is the way to go, but that's not an objection... I just don't know wnough about SVG. Another possibility is to use Tk, since that has bindings for several scripting languages already. All this is somewhat out of the scope of a theme change. -- [[User:Argent Stonecutter|Argent Stonecutter]] 08:47, 22 October 2007 (PDT)
::::SVG would provide an "open" system for vector graphics where flash provides a "closed" system.
::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 12:41, 22 October 2007 (PDT)

=== Skin Support ===
I'd like to suggest Hue changer for quick custom theme color for users.... However, for graphic artist like myself, I would like to able customize the skin with ease. Just think more like WinAmp 5. --[[User:Vincent Nacon|Vincent Nacon]] 12:32, 22 October 2007 (PDT)

is also good to make a little program in php for the second life site or a executable for create new skin in more simple way

this is my purple skin :)
[[Image:Dazzle_purple_version.JPG|thumb|300px|Purple Skin]]

--[[User:Aliceinwire Bleac|Aliceinwire Bleac]] 04:56, 7 November 2007 (PST)

* Purple skin made me smile a lot! Thanx for sharing that with Ben and I, Aliceinwire! /me open-secretly hopes for a green-and-pink skin. :D --[[User:Torley Linden|Torley Linden]] 11:26, 7 November 2007 (PST)

===Too Little===
Just looking at the pic...except for the icons, which are probably needed, I'm underwhelmed. It's the same old interface except for being white and shinier (IMO, too shiny), and the consensus among people I know tends torward the opinion that the UI needs to be reinvented, not just polished, and I'd rather see development time being taken on that. Take as an example the work being done by e-Sheep with their new custom client. I'm not saying they've done things that I necescarily want to see but they've got their goals in the right place. I could list a number of UI suggestions and pet peeves but this isn't the place for it...some day I wil actualy get around to putting them on the JIRA. That said, I agree with the people who mentioned skins and even just being able to set UI color preferences from the preferences menu; that by itself would address a lot of issues. [[User:Elle Pollack|Elle Pollack]] 15:00, 22 October 2007 (PDT)

===Enhancement?===
I would love to beable to collect a Landmark while viewing another resident's profile picks. --[[User:Sabina Stenvaag] , 1 nov 2007 (PDT)

== Buttons. ==

The gradient effect on the buttons need to weigh one way or the other. Having the 'line' go right through the text with as much contrast as it has, is distracting, and hard on the eyes.
I would suggest more smoothing to it as well.
Here is a mock up of what I mean. The lower left button is the only one modified.
[[Image:NewViewer_button_mockup.jpg|mock up]]

== what is wrong with light text on dark background? ==

for me, light text on dark background is way more comfortable for my eyes, I find light backgrounds kinda too aggressive :/

why not continue with the dark backgrounds? imitating rl paper on software is kinda lame on my opinion :\ --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 01:08, 13 November 2007 (PST)

Talk:Viewer Visual Update

2007-11-14T08:36:00Z

Balp Allen: /* Feedback and Ideas */

== Thanx for the feedback thus far... ==
Hello and thanks for the comments! I'm involved with this project, codename "Dazzle", insofar as helping the Rx Team get the word out to our community. I haven't read all of these comments in close detail yet, but I appreciate not just the content, but the presentation too.

LordJason Kiesler — thanks for embedding that graphic to communicate what you think of about the button gradients. If anyone else wants to contribute screenshot mockups, please, you're more than welcome. Since this is a ''visual'' update, those type of aids help.

I also had [http://www.flickr.com/photos/torley/1801183618/ some nice comments on my Flickr photostream], and will be encouraging more... and responding in kind. Appreciatively yours! --[[User:Torley Linden|Torley Linden]] 16:28, 1 November 2007 (PDT)

Great, [http://torley.com/introducing-second-lifes-dazzle-user-interface-update even more Dazzle feedback on my personal blog!] --[[User:Torley Linden|Torley Linden]] 08:04, 5 November 2007 (PST)

i love the new version :O is fantastic 
the near me bug is fixed exellent 
now i'm bugfixing my purple version 
really a good job benjamin :D --[[User:Aliceinwire Bleac|Aliceinwire Bleac]] 04:56, 12 November 2007 (PST)

== Feedback and Ideas ==
*As far as I'm concerned, one of the gold standard issues for interface usability in this or any other application is the ability to pull pop up menus off the interface. If one can't do that, it doesn't matter how pretty they look; they block content and make working in the interface overly difficult. Gotta be able to pull stuff off the interface or it's more of the same with new candy colors. [Professor Beliveau/5:18SL 10/30/07]
* In the Mac instructions, if you start with 'Make a copy of the Second Life application with "Duplicate" and rename it "Second Life Visual Update"...' and move on from there then the "uninstall" step won't be needed, and people can more easily compare the two. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:14, 22 October 2007 (PDT)

* Great work on the graphics! Definitely shows off the potential for what can be done.

Well how novel: ripping off the Mac OS X metallic buttons and giving them an Aqua feel... Well, don't stop there. Read Apple's Human Interface Guidelines and implement them. Then we'll not only have the feel too, but then the whole thing may work as standard instead of being buggy, bloated, roll your own code. We would have international settings and keyboards that worked, standard window behaviour, one menu bar not two, and text editing handling that worked properly, and properly transposed keyboard shorcuts. Get that stuff sorted first then you can think of moving on to skinning.
: I would like to point out, that SecondLife client is Cross-Platform. If they stuck to the Mac guidelines, then it wouldn't fit windows or linux. To be honest, as SecondLife is effectively a game, the interface has to be a roll your own (Read Apples guidelines, it actually says that somewhere) --[[User:Nik Woodget|Nik Woodget]] 02:37, 22 October 2007 (PDT)

* Just to introduce the conservative voice *8) while I greatly appreciate thought going into the viewer and all, I wouldn't say that making the colors prettier and the buttons and icons slicker-looking would be where I'd focus efforts if it was me. Give me back a tearoffable friends list, let me tear off and move around llDialog() / GroupNotice style dropdowns, make the viewer notice and tell me something useful when packets-in-per-second drops to zero, and other actual functional enhancements would do me a world more good than shinier-looking buttons... [[User:Dale Innis|Dale Innis]] 11:06, 13 November 2007 (PST)

* Great look, how ever the big problems in the gui layout are net even addressed in this preview. Friends and group was so much more easier to use before the voice release. I really like to get that in the 18.4 viewer nice Linux bug fixes but no working friends list yet in that version. Voice i guess that will come some ware around 2010 at best. I'm not asking for much just two patches from nicholaz. (and probably a hard admittance from someone onside Linden that new look with friends inside the IM window was a bad idea.) --[[User:Balp Allen|Balp Allen]] 00:36, 14 November 2007 (PST)

== Feedback on the style itself ==

*The problem I'm having is with the fact that most of the text in search results is white on a bright blue/gray background, which makes it hard to read. Also, text in profiles and (non-editable) group descriptions is difficult to read for the same reason. I think that adding more contrast would definitely improve the usability (not to mention the accessibility) of this skin. -- ????

The theme seems to be mostly based on one of a variety of "glossy" 3d themes that have become popular in UNIX/X11 environments. I would much rather see the glossiness eliminated and something less overpowering being used as inspiration.

Specific points:
:* With a light background ALL the text needs to be dark.
:* The window close and minimize buttons look smaller in this style, even if they aren't, and I keep slowing down to hit them more precisely.
:* The translucent menu bar is an improvement. It needs to extend under the menus themselves, of course. The backdrop for the button bars on the bottom should be translucent as well, for symmetry... and with the new style I don't think the little "loops" over the buttons above the chat bar are really useful.
:* The glossiness of the buttons is a problem, and they also look more like tabs than buttons. A flatter more "matte" style would work better.
:* The slight border around the chat and nametags is VERY nice.
:* The 3d look of hover text is not so good, I think because it's light. The light colored pie menu is ''really'' a problem.
:* The inventory and appearance editor seem significantly less professional.
:At the moment I think the original style is preferrable. I would say that the dark color scheme works better, particularly for translucent windows... if the ghosted windows could turn dark (but with light text) that would work, but that's probably more than XUI can handle. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:25, 22 October 2007 (PDT)

*I'm not a fan of square buttons.
*Like Argent I struggle with some of the light backgrounds
*Would it be possible to have an instruction page? This file does... for all the images. I know its possible to open them all, and I will, but pointers for how to tweak what be nice. I'm going to try a nicer (for my eyes) skin with greens, similar to the theme I've got on my mac menus, and hack some buttons, but it will take a while to get right because I'm flying blind (particularly for .j2c's that don't automatically preview for me). --[[User:Eloise Pasteur|Eloise Pasteur]] 06:53, 22 October 2007 (PDT)
:* Good print, J2Cs aren't well supported in bitmap editors yet. -- [[User:Argent Stonecutter|Argent Stonecutter]] 09:14, 22 October 2007 (PDT)
:* In the textures folder is a textures.xml file. This is the mapping {purpose}.tga -> UUID.{any extension} --[[User:Thraxis Epsilon|Thraxis Epsilon]] 11:51, 22 October 2007 (PDT)

I too struggle with the chat history and permission/worn status in inventory, as it's light text on a light background, but I hope you'll correct this by darkening the text. I like dark text on a light background very much... but OTOH I can understand how in a dark environment, you might want the opposite, sort of like the dashboard on your car... can it be made skinnable, so people can have what they prefer? (Changing with time of day or ambient lighting is probably a bit much to ask for, but would be very cool.) --[[User:Melissa Yeuxdoux|Melissa Yeuxdoux]] 16:23, 2 November 2007 (PDT)

=== Similarity to Mac/Aqua ===
Well how novel: ripping off the Mac OS X metallic buttons and giving them an Aqua feel... Well, don't stop there. Read Apple's Human Interface Guidelines and implement them. Then we'll not only have the feel too, but then the whole thing may work as standard instead of being buggy, bloated, roll your own code. We would have international settings and keyboards that worked, standard window behaviour, one menu bar not two, and text editing handling that worked properly, and properly transposed keyboard shorcuts. Get that stuff sorted first then you can think of moving on to skinning.
: I would like to point out, that SecondLife client is Cross-Platform. If they stuck to the Mac guidelines, then it wouldn't fit windows or linux. To be honest, as SecondLife is effectively a game, the interface has to be a roll your own (Read Apples guidelines, it actually says that somewhere) --[[User:Nik Woodget|Nik Woodget]] 02:37, 22 October 2007 (PDT)
:: I don't think it looks Mac-like at all. In fact while Apple popularized the glossy look the "shiny metallic" look isn't really their schtick, and they have been moving away from the aggressive glossiness of the early OS X versions to a smoother and more professional look in Panther and Tiger. -- [[User:Argent Stonecutter|Argent Stonecutter]] 18:02, 22 October 2007 (PDT)
:::I personally wouldn’t complain if they implemented as much of Apple’s HIG as possible. I wouldn’t expect them to get rid of the in-window menubar, but it would be nice if things like keyboard layouts worked properly. —[[User:Frungi Stastny|Frungi Stastny]] 06:53, 23 October 2007 (PDT)

=== Icons ===

The icons representing prims in the object builder are too small. It is quite difficult to distinguish between similar prims as, for example, the cone and the semicone.--[[User:Eadoin Welles|Eadoin Welles]] 10:22, 22 October 2007 (PDT)

I'm not loving it... Although I do like some of the icons but color wise and color balance theme are killing my eyes. The whole "gloss jem" buttons from Window Vista and OS Mac got really really old so fast. For me, I'd like a dark theme. Something more like this theme. [[http://www.wincustomize.com/zoom.aspx?skinid=4617&libid=1]] --[[User:Vincent Nacon|Vincent Nacon]] 12:32, 22 October 2007 (PDT)

I don't think the icons on the map or in other windows should be changed from the standard client unless absolutely necessary... and again I don't think that encapsulating the icons is really a good idea. -- [[User:Argent Stonecutter|Argent Stonecutter]] 18:06, 22 October 2007 (PDT)

I have to say I am underwhelmed by the icon set. Have you considered the [http://en.wikipedia.org/wiki/Tango_Desktop_Project Tango Desktop Project]? The Tango Project seeks to create a consistent graphical user interface experience across applications and platforms. IMHO, the quality of their icon sets is very high. Have a look at the icon sets and [http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines style guidelines on their website]. — [[User:Yuu Nakamichi|Yuu Nakamichi]] 15:21, 2 November 2007 (PDT)

== Additional suggestions ==
This section should be kept for suggestions that are really beyond the scope of a theme change.

=== Multiple Monitor Support ===

Would like more than anything to see the UI windows capable of being moved onto a second monitor off the main viewer window. Now that would be very cool and make life a whole lot easier.
:This would also mean making that the second life viewer would have to use system controls. Again its a pain for cross-platform software. Though not impossible. --[[User:Nik Woodget|Nik Woodget]] 02:38, 22 October 2007 (PDT)
::Why would this require using system controls ?
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 06:59, 22 October 2007 (PDT)
:::The UI in Second Life is part of the OpenGL rendering pipeline. In order for the controls to be seperated from the main window they would have to be contained in seperate OS controls. Maybe not system independent controls, perhaps custom controls rendered into borderless windows might work.
:::: Aren't there free open-source cross platform systems already out there to do stuff like that?--[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 05:32, 13 November 2007 (PST)

=== Mac Support ===

For the Mac port, at least, the way that command and control are reversed is really hard to deal with. It would be nice if there was an option to reverse the command and control keys ''for XUI only''. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:07, 22 October 2007 (PDT)

Whilst we're talking about this - can we add a request for a proper implementation of the Mac GUIs, without the irritating internal menus as well please. Swap the menu bar menus the way the GUI guidelines suggest. It's a different code base after all. I may have got used to this structure, but it's one bit of muscle memory I'd be very happy to get rid of! --[[User:Eloise Pasteur|Eloise Pasteur]] 15:56, 22 October 2007 (PDT)

=== Widgets ===

I like the new interface. It is surely better than the black one but, by the way, the real value would be to have a choice of skins which, in my understanding, is the main goal of this test. I think that another improvement might be to have the possibility to add gadgets. For example, I would like to have, close to the PDT time, also the local time, since most of events that I prepare are located in my country, and I prefer to use local time rather than useless PDT time. Rather than adding this feature, which may be of no interest to USA people and surely not at all to California people, you may give us the possibility to create gadgets, like in Google or Vista. So I could develop a small gadget to see time in various timezones, another one that automatically convert Linden dollars to various currencies, and so forth. By facilitating the development of user gadgets, you would dramatically improve the SL interface without having to develop them yourself. IMHO Greetings from Rome, Italy --[[User:Eadoin Welles|Eadoin Welles]] 10:19, 22 October 2007 (PDT)

==== Vector Graphics Widgets ====

Would like to see a flash layer, where flash widgets could communicate to the UI via an API and either replace or partially replace bits and pieces of it. This could be a big market for companies wishing to have customized clients but still take advantage of Linden Labs robust source.
:I would actively NOT want to see a layer that can only be programmed with a closed system like flash. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:07, 22 October 2007 (PDT)
::SVG + Javascript would work- uBrowser would be the place to start with that.
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 06:59, 22 October 2007 (PDT)
:::That's one approach. Javascript based controls are used in a number of programs: Firefox (XUL), Mac OS (Dashboard), Yahoo Widgets (for that matter Adobe's Actionscript has converged on Javascript). I'm not sure that SVG is the way to go, but that's not an objection... I just don't know wnough about SVG. Another possibility is to use Tk, since that has bindings for several scripting languages already. All this is somewhat out of the scope of a theme change. -- [[User:Argent Stonecutter|Argent Stonecutter]] 08:47, 22 October 2007 (PDT)
::::SVG would provide an "open" system for vector graphics where flash provides a "closed" system.
::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 12:41, 22 October 2007 (PDT)

=== Skin Support ===
I'd like to suggest Hue changer for quick custom theme color for users.... However, for graphic artist like myself, I would like to able customize the skin with ease. Just think more like WinAmp 5. --[[User:Vincent Nacon|Vincent Nacon]] 12:32, 22 October 2007 (PDT)

is also good to make a little program in php for the second life site or a executable for create new skin in more simple way

this is my purple skin :)
[[Image:Dazzle_purple_version.JPG|thumb|300px|Purple Skin]]

--[[User:Aliceinwire Bleac|Aliceinwire Bleac]] 04:56, 7 November 2007 (PST)

* Purple skin made me smile a lot! Thanx for sharing that with Ben and I, Aliceinwire! /me open-secretly hopes for a green-and-pink skin. :D --[[User:Torley Linden|Torley Linden]] 11:26, 7 November 2007 (PST)

===Too Little===
Just looking at the pic...except for the icons, which are probably needed, I'm underwhelmed. It's the same old interface except for being white and shinier (IMO, too shiny), and the consensus among people I know tends torward the opinion that the UI needs to be reinvented, not just polished, and I'd rather see development time being taken on that. Take as an example the work being done by e-Sheep with their new custom client. I'm not saying they've done things that I necescarily want to see but they've got their goals in the right place. I could list a number of UI suggestions and pet peeves but this isn't the place for it...some day I wil actualy get around to putting them on the JIRA. That said, I agree with the people who mentioned skins and even just being able to set UI color preferences from the preferences menu; that by itself would address a lot of issues. [[User:Elle Pollack|Elle Pollack]] 15:00, 22 October 2007 (PDT)

===Enhancement?===
I would love to beable to collect a Landmark while viewing another resident's profile picks. --[[User:Sabina Stenvaag] , 1 nov 2007 (PDT)

== Buttons. ==

The gradient effect on the buttons need to weigh one way or the other. Having the 'line' go right through the text with as much contrast as it has, is distracting, and hard on the eyes.
I would suggest more smoothing to it as well.
Here is a mock up of what I mean. The lower left button is the only one modified.
[[Image:NewViewer_button_mockup.jpg|mock up]]

== what is wrong with light text on dark background? ==

for me, light text on dark background is way more comfortable for my eyes, I find light backgrounds kinda too aggressive :/

why not continue with the dark backgrounds? imitating rl paper on software is kinda lame on my opinion :\ --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 01:08, 13 November 2007 (PST)

Talk:Viewer Authentication Critique

2007-09-30T08:44:01Z

Balp Allen: /* No balance */

{{Talk}}

== Process for editing the critique ==

By virtue of jumping first, I think [[User:Matthew Dowd|Matthew Dowd]] should be the working group chair for editing this document. What I think that means is this:
* Anyone can still make no-brainer edits to the article
* Matthew will be arbiter for dispute resolution, should that be necessary.
* If there are points that Matthew is unclear about, he should delete them from the document, and move them to the talk page.
* If there are points that others are unclear about, they should bring them up on the talk page, and then later delete them from the main page if a question/concern goes unanswered on the talk page (with "see talk page" in the comment of the edit).
* If, for whatever reason, it becomes necessary to fork this document, it's best to move all critiques into the user space of the working group chair. So, for example, Matthew's version would move to [[User:Matthew Dowd/Viewer Authentication Critique]], and other critiques could also be done the same way. This page would become a list of critiques.

Sound like a reasonable process? I think this is lightweight enough that a pretty good document can evolve pretty quickly. -- [[User:Rob Linden|Rob Linden]] 12:56, 29 September 2007 (PDT)

== Third party viewers/code ==

What's the substantive difference between these two points?
# Viewer still involves running trusted code on the computer and could initiate other attacks e.g.
# Most of these attacks could be performed by any third-party software designed for use with SL
Both have many subpoints. Could they be consolidated into a single point? -- [[User:Rob Linden|Rob Linden]] 20:10, 29 September 2007 (PDT)

The first point is that keeping the client from seeing the password doesn't remove the danger of a modified client.

The second point is that *any* ancillary software (such as animation editors, sculpt editors, sculpt texture plugins) could be used in an attack, even if they don't actually connect to SL, since they would be used by SL residents.

-- [[User:Argent Stonecutter|Argent Stonecutter]] 21:00, 29 September 2007 (PDT)

Is this better, Rob? -- [[User:Argent Stonecutter|Argent Stonecutter]] 21:11, 29 September 2007 (PDT)

:Yes, that is. Thanks for the clarification! -- [[User:Rob Linden|Rob Linden]] 21:44, 29 September 2007 (PDT)

== No balance ==

This article is pretty awful, its just an attack. For real critique you have to explore the alternatives and discuss the pros and cons for each.
Even if this form of log in has these disadvantages it could still be an improvement over what we currently have.
We need a common point of reference to discuss if this is an improvement and what alternatives exist.

Having studied the original idea, each time and deeper I'm now convinced there is 0 gain on the security point, I also see many many big security risks with it. I hope this will be the first issue in the last time that actually the Lindens start to listen to criticism about the proposal. I think not there have so far been one mail in favor of the idea on the developer list. All the other issues that just ignores the users, to that extent that i have put off all investment in SL. The day an alternative comes out, Lindens and in really danger for how they handle there users. So far they have a product that is one of a kind. But the completion gain all the time. The company that did everything they could to screw there user base will loose.
--[[User:Balp Allen|Balp Allen]] 01:44, 30 September 2007 (PDT)

Viewer Authentication Critique

2007-09-30T08:33:31Z

Balp Allen: /* Signatories */

This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.

For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]

== Security ==

=== LL's Objectives ===
* To mitigate the danger of password capturing Trojans masquerading as third party viewers
* Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.

=== Pros ===
* Viewer does not have to process (and "see") username and password

=== Cons ===
* The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.
** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).
** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.
* But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.
 
* Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!
** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
*** This kind of attack is not theoretical, phishing websites are a criminal industry.
** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns
** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)
* So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.
 
* And the mechanism itself is relatively inflexible.
** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program
** Links to secondlife:// can not pass parameters to the program
*** In fact allowing that was a security flaw recently found and fixed in the SL client. :(
 
* Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)
** The issues raised in the next section would mean that people would have an incentive to use this kind of client.

=== Alternatives ===
* One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)
* lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)
* separate passwords for website account and being inworld
* Account restrictions
* CRAM-MD5 or a similar challenge-response type
* Dictionary check to reject insecure passwords
=== Other Issues ===
* The main existing vulnerability involving the viewer and passwords is that the viewer does not use a cryptographically secure mechanism to pass the password to the server, not that the viewer may be stealing the password.
* In practice, trapdoored unofficial third party clients for applications have not historically been a major problem. This seems to be attacking an exposure that is primarily theoretical, and using a mechanism that has been known to be exploited to solve it.
 
 

== Flexibility ==

=== LL's Objectives ===
* Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems
* Extension of this to allow non-LL applications and web sites to participate in this single sign on system.

=== Pros ===
* Enables username/password authentication to work on third party sites without them having to "see" username and password

=== Cons ===
* This is really an unrelated issue...
** The client doesn't need to depend on the website for this purpose, or this could be a command line option.
** The client could just as easily be the 'authentication source' as the website.
*** Via a "go to website" link in the client that passed an equivalent token.
 
* As noted in section 1, this reduces flexibility for the *users*.

=== Alternatives ===
* Use this mechanism for websites (including third party) only but not for viewers
* Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]
** OpenID - [http://openid.net/]
** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]
** CAS - [http://www.ja-sig.org/products/cas/]
 
 
 
== Persistence ==

=== LL's Objectives ===
* To integrate the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.

=== Pros ===

=== Cons ===
* As in the previous section, LL's objectives could be met without the browser logging in via the same mechanism.
* Inconvenient for those with alts
** Cumbersome to change alts and logon with multiple alts
** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL
* Inconvenient for those with multiple clients
* Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.
* Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld

=== Alternatives ===
* Is this really needed?
=== Other issues ===
* Is this kind of persistence desirable ''for the client''? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".
 
 
 

== Misc ==

* this should be an option for those who have increased security needs, users should be able to make their own risk/convenience decisions
* the feature especially forces those into an extra login step, who use an official viewer (homebrews will most likely quickly implement a way around this for convenience)
* starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.
* this would make things harder for independent grids to use the official client. Is this considered an advantage or a disadvantage by LL?
 
 
 

== Signatories ==

Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with.

* [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)
* [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)
* [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)
* [[User:Tillie Ariantho|Tillie Ariantho]] 14:53, 29 September 2007 (PDT)
* [[User:Nicholaz Beresford|Nicholaz]] 15:38, 29 September 2007 (PDT)
* [[User:Jesse Barnett|Jesse Barnett]] 20:59, 29 September 2007 (PDT)
* [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)
* [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)

Build the Viewer on Linux

2007-08-06T12:12:44Z

Balp Allen: New download location, on the FMOD home page

{{CompileNav}}

The following are instructions for building the Second Life viewer on linux. This process has been used on [http://www.debian.org/ debian] and debian based systems like [http://www.ubuntu.com/ ubuntu], and also on [http://www.fedoraproject.org/ Fedora]. For other platforms, see [[Get source and compile]].

{{vital-info|How to compile [[Source_archive#2007-Feb-20|FL-1.13.3.58185]] and [[Source_archive#2007-Feb-24|FL-1.13.3.58390]] '''with''' llmozlib (see [[Talk:Compiling_the_viewer_%28Linux%29#llmozlib|discussion]])}}

= Building the client =
To build the Second Life Viewer you will first need to install the required tools and libraries.
The following sections outline steps to build the client from source. To simplify building,
Linden labs has been nice enough to prepackage some of the libraries and bundled them up in an
additional tar file.

And while The Second Life Viewer is not a trivial build, and experience with building large
software packages will help you greatly - but don't be daunted, it should be simple once the
dependencies are in the right place.

The tasks are:
# Install required tools.
# Unpack source and art tree's from Linden Labs.
# Install libraries not shiped by Linden Labs.
# Unpack or install the other required libraries and headers.
# Compile.
 
 
== Required tools ==
There are a number of tools that need to be installed first.

* SCons build tool [package: scons]
* GCC 3.4 C/C++ compiler
** [debian/ubuntu: g++-3.4]
** [fedora: compat-gcc-34-c++]
** other GCC versions are not well-tested; GCC 4.x will NOT currently build the viewer without a few simple code adjustments. {link to them pls}
* yacc [suggest packages: bison]
* lex [suggest packages: flex]
 
 

== Unpack the source tree ==

You can get the source either from the source archives available at [[Source downloads]], or you can get it from [[Subversion]].

Using a source archive is the easier option, but if you plan to do active development and want to make your own modifications, while merging LL's changes, subversion will probably be much more convenient on the long term.

=== Getting the source from the source archives ===
Get the source from [[Source downloads]]. You will need all 3 archives: source, artwork and libraries.

Choose a location and unpack the source tree and the art work. They will be extracted into a
directory call linden.

<code>
% tar -xzf slviewer-src-<version>.tar.gz
% tar -xzf slviewer-<os>-libs-<version>.tar.gz
% unzip slviewer-artwork-<version>.zip
</code>
 

=== Getting the source from Subversion ===
Select a source [[Source branches|branch]] to check out.

Check it out with:
<code>
% svn co http://svn.secondlife.com/svn/linden/<branch> [directory]
</code>
If you don't specify the directory, it'll use the name of the branch as the default.

Now you will have a directory with the source code. This only includes the source code itself, without the libraries or artwork. You will have to get them from the [[Source downloads]] and unpack them into the tree.

If the directory SVN created is called 'linden' then you can directly unzip and untar the archives on top of it. If it's called something else, create a symlink:
<code>
% ln -sf <branch> linden
</code>

Now unpack the libraries and artwork:
<code>
% tar -xzf slviewer-<os>-libs-<version>.tar.gz
% unzip slviewer-artwork-<version>.zip
</code>

 

== Installing the required libraries (that Linden labs can not or does not provide)==
=== FMOD (audio) ===
* FMOD provides audio output, but (although 'free' in some senses) is not itself open-source. If you wish to avoid FMOD, thus disabling audio, you may make these changes:
** Comment-out the libfmod line in indra/newview/viewer_manifest.py
** Add FMOD=no to your Scons build command when compiling the source.
* If you want to use FMOD, fetch and unpack FMOD 3.75 <http://www.fmod.org/>
<code>
% wget http://www.fmod.org/index.php/release/version/fmodapi375linux.tar.gz
% tar -xzvf fmodapi375linux.tar.gz
% cd fmodapi375linux/
% cp api/inc/* ../linden/libraries/i686-linux/include/
% cp api/libfmod-3.75.so ../linden/libraries/i686-linux/lib_release_client/
</code>
 
 

== Installing the required dependencies (prepackaged by Linden labs)==

The Second Life Viewer has a number of compile/link dependencies on external libraries which
are needed - to help you, the source download page contains a link to a slviewer-linux-libs package which you unpack over the source tree to fill most of the dependencies (and thus avoid most of the fiddly work described on this page).

If you download the libs to the top folder, where the linden folder is after getting and extracting the viewer source code tarball, the following command should unpack everything to the right spot.
<code>
tar xvfz slviewer-linux-libs-<version>.tar.gz
</code>

If you choose to use the provided libraries you can skip to
[[Compiling_the_viewer_%28Linux%29#Compiling|Compiling the client]].
 
=== Doing yourself ===
If you are porting to a new architecture or wish to make a package tailored to your Linux distribution's own libraries. You will have to install the following additional dependencies
listed below. Paths and package names given here are based on Ubuntu 7.04 and may vary
according to your Linux distribution.

==== List of libraries ====
* apr-1 [ubuntu: libapr1-dev, fedora: apr-devel]

* aprutil-1 [ubuntu: libaprutil1-dev, fedora: apr-util-devel]

* boost [ubuntu: libboost-dev, fedora: boost-devel]

* boost-regex [ubuntu: libboost-regex-dev]

* curl library at least version 7.15.4 is recommended, 7.16.x is ideal.
** [ubuntu: libcurl3-dev, fedora: curl-devel]
** If you are compiling your own version of Curl, then you should consider configuring it to use the c-ares library so that DNS lookups will be asynchronous.

* ELFIO <http://sourceforge.net/projects/elfio/>
** This wants to build a static library by default. Afterwards, to create a dynamic libelfio.so
<code>
% cd ELFIO && g++-3.4 -shared *.o -o libelfio.so
</code>

* expat [ubuntu: libexpat1-dev, fedora: expat-devel]

* google-perftools library for the tcmalloc and stacktrace libraries. (memory checking)
**[ubuntu: libgoogle-perftools-dev, fedora: google-perftools-devel.i386

* GTK 2.x development headers [ubuntu: libgtk2.0-dev, fedora: gtk2-devel]

* jpeglib [ubuntu: libjpeg62-dev, fedora: libjpeg-devel]

* OpenGL development headers: gl.h, glext.h, glu.h
**[ubuntu: mesa-common-dev, libglu1-mesa-dev, fedora: mesa-libGL-devel, mesa-libGLU-devel]

* OpenJPEG <http://www.openjpeg.org/>
** note: OpenJPEG 1.1.1 or greater is required which has the macro OPJ_PATH_LEN, if the header has MAX_PATH, then upgrade or it will crash with a divide by zero error as the structures would be two different sizes.
*** ''what does this mean?''

* OpenSSL <http://www.openssl.org/> [ubuntu: libssl-dev, fedora: ?]

* SDL [ubuntu libsdl1.2-dev, fedora: SDL-devel]

* Vorbis [ubuntu: libvorbis-dev, fedora: libvorbis-devel]

* X11 development headers: Xlib.h, and Xutil.h
**[ubuntu: libx11-dev, fedora: libX11-devel]

* xmlrpc-epi 0.51 <http://xmlrpc-epi.sourceforge.net/>
** note: not xmlrpc-c (xmlrpc-c has a library and headers with the same name but is not compatible)
** Apply patches from the instructions in [[patch xmlrpc-epi]]
*** ''does this still work?''
** See also:
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-gcc4.1.patch
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-use-system-expat.patch
*** http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-rename.patch
*** You have to regenerate autotools after applying the patches:
****libtoolize -c -f
****aclocal
****automake -c -a -f
****autoconf
*** The first patch fixes compiling on gcc 4. The second patch causes it to compile against the system expat, the version xmlrpc-epi comes with is broken and will not work. The last patch renames the library from xmlrpc to xmlrpc-epi, otherwise it conflicts with xmlrpc-c - which means the viewer then needs to be patched to link against xmlrpc-epi and not xmlrpc. These patches are from my Fedora package. On linux, I recommend these patches in favor of the Linden ones, as theirs seem to be for windows. (And mine actually work)
 
 

==== Copy headers and libraries into the source tree ====

Here is a guide to the sequence of shell commands needed to copy the required headers and libraries into the Second Life Viewer source tree for building. Actual paths to system headers may vary according to Linux distribution.

If you are using the easy slviewer-linux-libs bundle then you can skip the rest of this section, otherwise you will also need to perform the following:

* ${SLSRC} refers to the top-level directory of the Second Life Viewer source tree.
* ${OPENJPEG} refers to the top-level directory of your completed OpenJPEG build.
* ${ELFIO} refers to the top-level directory of your completed ELFIO build.

<code>
cp -a /usr/include/atk-1.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/include/gtk-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/gtk-2.0/include/* ${SLSRC}/libraries/i686-linux/include/gtk-2.0/
cp -a /usr/include/glib-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/glib-2.0/include/* ${SLSRC}/libraries/i686-linux/include/glib-2.0/
cp -a /usr/include/pango-1.0 ${SLSRC}/libraries/i686-linux/include/

if your GTK is fairly recent and thus needs Cairo:
cp -a /usr/include/cairo/* ${SLSRC}/libraries/i686-linux/include

cp -a /usr/include/apr-1.0/ ${SLSRC}/libraries/i686-linux/include/apr-1

mkdir ${SLSRC}/libraries/i686-linux/include/expat
cp -a /usr/include/expat*.h ${SLSRC}/libraries/i686-linux/include/expat/

mkdir ${SLSRC}/libraries/i686-linux/include/zlib
cp -a /usr/include/zlib*.h ${SLSRC}/libraries/i686-linux/include/zlib/

mkdir ${SLSRC}/libraries/i686-linux/include/openjpeg
cp ${OPENJPEG}/libopenjpeg/openjpeg.h ${SLSRC}/libraries/i686-linux/include/openjpeg/
cp ${OPENJPEG}/libopenjpeg.a ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/ELFIO
cp ${ELFIO}/ELFIO/*.h ${SLSRC}/libraries/i686-linux/include/ELFIO/
cp ${ELFIO}/ELFIO/libelfio.so ${SLSRC}/libraries/i686-linux/lib_release_client/

mkdir ${SLSRC}/libraries/i686-linux/include/jpeglib
cp -a /usr/include/j*.h ${SLSRC}/libraries/i686-linux/include/jpeglib/
touch ${SLSRC}/libraries/i686-linux/include/jpeglib/jinclude.h

mkdir ${SLSRC}/libraries/i686-linux/include/llfreetype2
cp -a /usr/include/freetype2/freetype/ ${SLSRC}/libraries/i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h ${SLSRC}/libraries/i686-linux/include/llfreetype2/freetype/

mkdir ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h ${SLSRC}/libraries/i686-linux/include/xmlrpc-epi/
</code>
 
 

== Compiling ==
=== Build Types ===
The ''BUILD'' parameter specifies the build type. For normal usage, use '''release'''. If you plan to work on the source, choose '''releasenoopt''' or '''debug''', as these versions are unoptimized and much easier to debug.

* '''release''': Optimized build for release.
* '''releasenoopt''': Unoptimized build.
* '''debug''': Debug build with assertions.
* '''releasefordownload''': Optimized build for release, will create a .tar.gz with the files for distribution.
 
=== Building ===
=== Disable llMozLib ===
Add MOZLIB=no to your Scons build command when compiling the source.
 
<code>
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release MOZLIB=no
</code>
Expect a build time of a couple of hours. The resulting unstripped Second Life Viewer binary is newview/secondlife-i686-bin. Note that temporary object code is compiled into /tmp/$USER by default (where $USER is your username) - this can be changed by prefixing the scons command above with TEMP_BUILD_DIR="[full directory path]". For example:

<code>
$ TEMP_BUILD_DIR="/home/fred/secondlife/temp-build" scons DISTCC=no BTARGET=client BUILD=release
</code>

To build a release that has all of the shaders and optimizations enabled and resembles the official shipped Linux alpha client, use BUILD=releasefordownload

Be sure to read the [[Common compilation problems]] page if you have problems - we'll try to keep the page up to date with known problems and solutions.
 
 
== Testing and packaging the client ==

=== Testing the result from inside the tree ===

You may find it simpler and less error-prone to follow the instructions in the [[Compiling_the_viewer_%28Linux%29#Packaging_the_client|Packaging the client]] section below to run the client under the same conditions as an end-user would. Otherwise:

* Preparing to run 'in-tree'
** ensure that you have indra/newview/app_settings/static_*.db2 - if not, you'll find it in the 'slviewer-artwork' download (a zip file).
** now, from the indra directory:
<code>
$ cp ../scripts/messages/message_template.msg newview/app_settings/
$ cp ../etc/message.xml newview/app_settings/
</code>

'''Important:''' Starting from version 1.18.0, copying message.xml is also required. Missing it will cause group IMs to fail to work, although the viewer will run fine otherwise.

* Running it: The LD_LIBRARY_PATH stuff ensures that the binary looks for its libraries in the right places. From the indra directory:
<code>
$ ( cd newview && LD_LIBRARY_PATH=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_PATH}:/usr/local/lib ./secondlife-i686-bin )
</code>

 
==== The client seems kinda slow. ====

By default, the open-source Second Life Viewer uses the open-source OpenJPEG library to decode the (many) JPEG-2000 texture images it receives from the servers. This isn't quite of comparable speed to the proprietary third-party library which the Linden Lab viewer builds have traditionally used, for which we are not permitted to redistribute the source.

However, the slviewer-linux-libs package includes two pre-built libraries which facilitate the use of this slightly faster image decoding method: libkdu_v42R.so and libllkdu.so. These are provided for your testing; again, we are not permitted to grant you the right to re-distribute these libraries to downstream users, but the viewer will still work (albeit slightly slower) without them.

To use these faster image-decoding libraries, they simply need to be put into the right places relative to the viewer runtime directory - nothing needs to be reconfigured or recompiled. If you're running the client from the source tree, the following will make the KDU libraries available:
<code>
cp "$SLSRC/libraries/i686-linux/lib_release_client/libllkdu.so" "$SLSRC/indra/newview/libllkdu.so"
mkdir "$SLSRC/indra/lib"
cp "$SLSRC/libraries/i686-linux/lib_release_client/libkdu_v42R.so" "$SLSRC/indra/lib/libkdu_v42R.so"
</code>

The file indra/newview/viewer_manifest.py contains some commented-out entries describing where these libraries belong; if you uncomment the two lines corresponding to libllkdu and libkdu then they will be automatically copied into the right place in the runtime directory when you follow the 'Packaging the client' instructions below.

==== File Dialogs Don't Work on 64 bit system ====

If you run a 64 bit system, and your file dialogs don't work, or they worked before and stopped after you installed an update, it may be due to a mismatch between the headers used to compile the viewer and the library it's using. The log will contain something like this:
<code>
2007-06-21T01:28:35Z INFO: ll_try_gtk_init: Starting GTK Initialization.
2007-06-21T01:28:36Z INFO: ll_try_gtk_init: GTK Initialized.
2007-06-21T01:28:36Z INFO: ll_try_gtk_init: - Compiled against GTK version 2.10.11
2007-06-21T01:28:36Z INFO: ll_try_gtk_init: - Running against GTK version 2.10.6
2007-06-21T01:28:36Z WARNING: ll_try_gtk_init: - GTK COMPATIBILITY WARNING: Gtk+ version too old (micro mismatch)
</code>

What happens here is that your distribution includes 32 bit GTK libraries, but the package only includes the libraries themselves and not the headers. When building, the SL client will build against the headers included with the main 64 bit GTK package. This will work if the 64 bit version of the library is the same or older than the 32 bit one. However, if your 32 bit library is older, then the viewer will detect the mismatch (built with headers for a newer version of GTK than it's using) and turn GTK off.

Possible solutions:
* Download the source for the version of the 32 bit GTK libraries your distribution comes with, and build your viewer against those headers.
* Upgrade your 32 bit GTK package so that it's the same or newer as the 64 bit one.
* Downgrade your 64 bit package (may not be a good idea).

=== Packaging the client ===

If you substitute 'BUILD=release' with 'BUILD=releasefordownload' in the 'Compiling' section above, then packaging the resulting code, libraries, data and documentation into a tarball for the end-user will be done automatically as the final stage of the build process; the pristine end-user client distribution has been assembled into the directory indra/newview/SecondLife_i686_1_X_Y_Z/ and has also been tarred into indra/newview/SecondLife_i686_1_X_Y_Z.tar.bz2

The file which controls what (and where) files go into the end-user runtime viewer directory is indra/newview/viewer_manifest.py

==== Automated libraries and headers adjustments, compilation and packaging ====
 
Here is a bash script that could save you a lot of time... It basically does all what is described above, and more, and entitles you to compile a SL client very easily:

<code>
<pre>
<nowiki>
#!/bin/bash

# make-SL v1.70 (c)2007 Henri Beauchamp. Released under GPL license v2:
# http://www.gnu.org/licenses/gpl.txt

###############################################################################
######## THIS IS QUICK'N DIRTY ALPHA SOFTWARE. USE AT YOUR OWN RISKS ! ########
###############################################################################

###############################################################################
# BEWARE: this script is meant to compile a -personal- SL client. It is -NOT- #
# suitable to build client versions meant for public release, because #
# non-open source code is packaged by this script (e.g. libkdu). #
###############################################################################

# This bash script is aimed at easying up the build process of a SL client.
# It does not cover building it with custom/system openjpeg, elfio or fmodapi
# (we use the provided libraries).
# You may enable or disable the use of your system's library by editing
# the USE_SYSTEM_* variable ("yes" --> use the system library, "no" --> use
# LL's provided ones).
# The script also takes care of updating properly the viewer_manifest.py script
# accordingly, so that you (should) end up with a properly packaged client.

# To use this script, simply make it executable (chmod +x make-SL) and
# put it into /usr/local/bin (or any other directory in your PATH).
# Then, download the slviewer-src-*.tar.gz, slviewer-linux-libs-*.tar.gz,
# slviewer-artwork-*.zip and fmodapi*.tar.gz archives, and finally, invoke
# make-SL as follow:
# make-SL path_to_archives (example: make-SL ~/downloads)
# or simply:
# make-SL
# when invoking from the directory where the archives are.
# The sources will be installed into the PATH_TO_SOURCES directory,
# and the client will be built into the TEMP_BUILD_DIR directory.
# The packaged build will be moved to your home directory.
# If you want to retry a compilation after fixing something manually and
# don't want make-SL to start all over again, overwriting everything,
# you may invoke it with the --retry option, like this:
# make-SL --retry
# This script has been tested by the author, on a (very customized)
# Mandrake 10.2 distro. Tested with SL v1.17 sources.

# Where the sources of the client will be held (defaults to "./linden"):
PATH_TO_SOURCES="/usr/src/SL"
# Where to build the client:
export TEMP_BUILD_DIR="$PATH_TO_SOURCES/build"

USE_SYSTEM_GTK="yes"
USE_SYSTEM_SDL="yes"
USE_SYSTEM_SSL="yes"
# Beware: libdb4 makes use of libapr... so you should keep USE_SYSTEM_APR
# and USE_SYSTEM_DB4 in sync.
USE_SYSTEM_APR="no"
USE_SYSTEM_DB4="no"
USE_SYSTEM_OGG="yes"
USE_SYSTEM_ZLIB="yes"
USE_SYSTEM_UUID="yes"
USE_SYSTEM_CURL="no"
USE_SYSTEM_EXPAT="no"
USE_SYSTEM_VORBIS="yes"
USE_SYSTEM_XMLRPC="yes"
USE_SYSTEM_JPEGLIB="yes"
# Enabling the system freetype2 prevents the client from using the SL fonts,
# or at least, this is what happens on my system (Mandrake 10.2 with PLF
# freetype2).
USE_SYSTEM_FREETYPE2="no"
USE_SYSTEM_PERFTOOLS="yes"

# You may add tune flags here, to optimize the code for your processor.
# Example, for an Athlon XP:
# TUNE_FLAGS="-march=athlon-xp"
# BEWARE: because of a bug in the v1.17.2.0 SConstruct file, you MUST keep at
# least an -O2 flag in the TUNE_FLAGS, to avoid getting a very slooooow client...
# This problem was apparently fixed in v1.17.3.0.
TUNE_FLAGS="-fomit-frame-pointer -frename-registers -fweb -fexpensive-optimizations"

# Whether to build with the browser login screen or not:
WITH_MOZILLA="yes"

function update_manifest() {
grep -v $1 $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
}

function compile() {
cd $PATH_TO_SOURCES/indra
echo "Compiling the client into $TEMP_BUILD_DIR..."
scons DISTCC=no BTARGET=client BUILD=releasefordownload MOZLIB=$WITH_MOZILLA
if (($? == 0)) ; then
mv $PATH_TO_SOURCES/indra/newview/SecondLife*.tar.bz2 $HOME/
fi
}

if [ "$TEMP_BUILD_DIR" == "" ] ; then
export TEMP_BUILD_DIR=/tmp/$USER/SL
fi

# Check to see if we simply want to retry a compilation:
if [ "$1" == "--retry" ] ; then
compile
exit $?
fi

# Make sure we don't unpack over an old source tree:
if [ -d linden ] ; then
rm -rf linden/
fi

if [ -d $PATH_TO_SOURCES ] && [ "$PATH_TO_SOURCES" != "" ] && [ "$PATH_TO_SOURCES" != "/" ] && [ "$PATH_TO_SOURCES" != "." ] && [ "$PATH_TO_SOURCES" != ".." ] && [ "$PATH_TO_SOURCES" != "$HOME" ] ; then
rm -rf $PATH_TO_SOURCES/
fi

# Use the parameter (if any) as the path to the archives:

PATH_TO_ARCHIVES="."
if [ "$1" != "" ]; then
if [ -d $1 ] ; then
PATH_TO_ARCHIVES=$1
fi
fi

# Let's first unpack everything:
if ! [ -f $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz ] ; then
echo "You need slviewer-src !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz ] ; then
echo "You need slviewer-linux-libs !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/slviewer-artwork-*.zip ] ; then
echo "You need slviewer-artwork !"
exit 1
fi
if ! [ -f $PATH_TO_ARCHIVES/fmodapi*.tar.gz ] ; then
echo "You need fmodapi !"
exit 1
fi
echo "Extracting the files from the archives..."
tar xzf $PATH_TO_ARCHIVES/slviewer-src-*.tar.gz
tar xzf $PATH_TO_ARCHIVES/slviewer-linux-libs-*.tar.gz
unzip $PATH_TO_ARCHIVES/slviewer-artwork-*.zip >/dev/null
tar xzf $PATH_TO_ARCHIVES/fmodapi*.tar.gz

# fmodapi:
echo "Copying fmodapi files..."
cp -a fmodapi*/api/inc/* linden/libraries/i686-linux/include/
cp fmodapi*/api/libfmod-*.so linden/libraries/i686-linux/lib_release_client/
rm -rf fmodapi*/

# Move the sources to where we want to hold them:
if [ "$PATH_TO_SOURCES" != "linden" ] && [ "$PATH_TO_SOURCES" != "" ] ; then
echo "Moving the sources to $PATH_TO_SOURCES..."
mv -f linden $PATH_TO_SOURCES
fi

# Let's own the files:
chown -R $USER: $PATH_TO_SOURCES/

# Check for patches to apply. The names of the patches must be in the form
# slviewer-*.patch* (Example: slviewer-v117-EmbbededNotecard.patch.bz2).
# They must be applicable from inside the source directory with the -p1
# option, i.e. they have been built from outside the source directory
# with a diff command such as:
# diff -urN linden/ linden-patched/ >slviewer-whatever.patch
# And they may be gzipped or bzipped.
PATCHES=`/bin/ls $PATH_TO_ARCHIVES/slviewer-*.patch* 2>/dev/null`
if [ "$PATCHES" != "" ] ; then
echo "Applying patches..."
cd $PATH_TO_SOURCES
PATCHES=`/bin/ls $PATH_TO_ARCHIVES/slviewer-*.patch*`
for i in $PATCHES; do
echo "Patch: $i"
if echo $i | grep ".gz" &>/dev/null ; then
gunzip -c $i | patch -p1 -s
elif echo $i | grep ".bz2" &>/dev/null ; then
bzcat $i | patch -p1 -s
else
patch -p1 -s <$i
fi
done
fi

# Make a clean build:
if [ -d $TEMP_BUILD_DIR ] && [ "$TEMP_BUILD_DIR" != "" ] && [ "$TEMP_BUILD_DIR" != "/" ] && [ "$TEMP_BUILD_DIR" != "." ] && [ "$TEMP_BUILD_DIR" != ".." ] && [ "$TEMP_BUILD_DIR" != "$HOME" ] ; then
rm -rf $TEMP_BUILD_DIR/
fi
mkdir -p $TEMP_BUILD_DIR

# Let's use the system GTK+ if available:
if [ -d /usr/include/atk-1.0 ] && [ "$USE_SYSTEM_GTK" == "yes" ] ; then
echo "Using the system GTK+..."
cd $PATH_TO_SOURCES/libraries/i686-linux/include
rm -rf atk-1.0/ gtk-2.0/ glib-2.0/ pango-1.0/
rm -f ../lib_release_client/libgtk*
cp -a /usr/include/atk-1.0 .
cp -a /usr/include/gtk-2.0 .
cp -a /usr/lib/gtk-2.0/include/* gtk-2.0/
cp -a /usr/include/glib-2.0 .
cp -a /usr/lib/glib-2.0/include/* glib-2.0/
cp -a /usr/include/pango-1.0 .
if [ -d /usr/include/cairo ] ; then
cp -a /usr/include/cairo/* .
fi
fi

# Let's use the system freetype2 if available:
if [ -f /usr/include/ft2build.h ] && [ "$USE_SYSTEM_FREETYPE2" == "yes" ] ; then
echo "Using the system freetype2..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/freetype/ i686-linux/include/llfreetype2/*
rm -f include/ft2build.h i686-linux/lib_release_client/libfreetype.a
cp -a /usr/include/freetype2/freetype/ i686-linux/include/llfreetype2/
cp -a /usr/include/ft2build.h i686-linux/include/llfreetype2/freetype/
fi

# Let's use the system zlib if available:
if [ -f /usr/include/zlib.h ] && [ "$USE_SYSTEM_ZLIB" == "yes" ] ; then
echo "Using the system zlib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/zlib/
mkdir -p i686-linux/include/zlib
cp -a /usr/include/zlib*.h i686-linux/include/zlib/
fi

# Let's use the system jpeglib if available:
if [ -f /usr/include/jpeglib.h ] && [ "$USE_SYSTEM_JPEGLIB" == "yes" ] ; then
echo "Using the system jpeglib..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/jpeglib/ i686-linux/lib_release_client/libjpeg.a
mkdir -p i686-linux/include/jpeglib
cp -a /usr/include/j*.h i686-linux/include/jpeglib/
touch i686-linux/include/jpeglib/jinclude.h
fi

# Let's use the system xmlrpc-epi if available:
if [ -f /usr/include/xmlrpc.h ] && [ "$USE_SYSTEM_XMLRPC" == "yes" ] ; then
echo "Using the system xmlrpc-epi..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/xmlrpc-epi/ i686-linux/lib_release_client/libxmlrpc.a
mkdir -p i686-linux/include/xmlrpc-epi
cp -a /usr/include/xmlrpc*.h i686-linux/include/xmlrpc-epi/
fi

# Let's use the system ogg if available:
if [ -f /usr/include/ogg/ogg.h ] && [ "$USE_SYSTEM_OGG" == "yes" ] ; then
echo "Using the system ogg..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/ogg/ i686-linux/lib_release_client/libogg*
update_manifest libogg
fi

# Let's use the system vorbis if available:
if [ -f /usr/include/vorbis/vorbisenc.h ] && [ "$USE_SYSTEM_VORBIS" == "yes" ] ; then
echo "Using the system vorbis..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/vorbis/ i686-linux/lib_release_client/libvorbis*
update_manifest libvorbis
fi

# Let's use the system SDL if available:
if [ -f /usr/include/SDL/SDL.h ] && [ "$USE_SYSTEM_SDL" == "yes" ] ; then
echo "Using the system SDL..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/SDL/ lib_release_client/libSDL*
update_manifest libSDL
fi

# Let's use the system openssl if available:
if [ -f /usr/lib/libssl.so.0.9.7 ] && [ "$USE_SYSTEM_SSL" == "yes" ] ; then
echo "Using the system openssl..."
cd $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client
rm -f libssl.* libcrypto.*
update_manifest libssl
update_manifest libcrypto
fi

# Let's use the system apr if available:
if [ -f /usr/include/apr*/apr.h ] && [ "$USE_SYSTEM_APR" == "yes" ] ; then
echo "Using the system apr..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -rf include/apr-1/*
rm -f lib_release_client/libapr*
cp -a /usr/include/apr*/* include/apr-1/
update_manifest libapr
fi

# Let's use the system expat if available:
if [ -f /usr/include/expat.h ] && [ "$USE_SYSTEM_EXPAT" == "yes" ] ; then
echo "Using the system expat..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/expat/
rm -f i686-linux/lib_release_client/libexpat*
mkdir -p i686-linux/include/expat
cp -a /usr/include/expat*.h i686-linux/include/expat/
update_manifest libexpat
fi

# Let's use the system curl if available:
if [ -f /usr/include/curl/curl.h ] && [ "$USE_SYSTEM_CURL" == "yes" ] ; then
echo "Using the system curl..."
cd $PATH_TO_SOURCES/libraries
rm -rf include/curl/
rm -f i686-linux/lib_release_client/libcurl.*
update_manifest libcurl
fi

# Let's use the system db4 if available:
if [ -f /usr/lib/libdb-4.2.so ] && [ "$USE_SYSTEM_DB4" == "yes" ] ; then
echo "Using the system db4..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libdb*.so
update_manifest libdb
fi

# Let's use the system uuid if available:
if [ -f /lib/libuuid.so.1 ] && [ "$USE_SYSTEM_UUID" == "yes" ] ; then
echo "Using the system libuuid..."
rm -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libuuid.*
update_manifest libuuid
fi

if grep tcmalloc $PATH_TO_SOURCES/indra/SConstruct &>/dev/null ; then
if [ -f /usr/include/google/malloc_hook.h ] && [ "$USE_SYSTEM_PERFTOOLS" == "yes" ] ; then
echo "Using the system google-perftools..."
cd $PATH_TO_SOURCES/libraries/i686-linux
rm -f lib_release_client/libtcmalloc.* lib_release_client/libstacktrace.*
rm -rf include/google/
cp -a /usr/lib/libstacktrace.* /usr/lib/libtcmalloc.so* lib_release_client/
cp -a /usr/include/google include/
update_manifest tcmalloc
update_manifest stacktrace
else
# Remove the google-perftools stuff if not present in the libraries package
# (problem seen in SL v1.17):
if ! [ -f $PATH_TO_SOURCES/libraries/i686-linux/lib_release_client/libtcmalloc.so ] ; then
update_manifest tcmalloc
update_manifest stacktrace
# The following lines remove the
# "external_libs += ['tcmalloc', 'stacktrace']"
# line from SConstruct... and many other lines which renders SConstruct
# unusable to build anything else than the client... this is a quick'n
# dirty patch. :-P
grep -v tcmalloc $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct
fi
fi
fi

# Fix a bug in v1.17.1 and later SConstruct file, where some libraries are
# compiled as shared instead of static, and are yet not packaged, and where
# fmod can't be enabled for OPENSOURCE:
sed -e "s/create_dynamic_module(module=module, module_libs=module_libs)/create_static_module(module)/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
sed -e "s/enable_fmod = not opensource and/enable_fmod =/" $TEMP_BUILD_DIR/SConstruct >$PATH_TO_SOURCES/indra/SConstruct
rm -f $TEMP_BUILD_DIR/SConstruct

# Add tune flags, if any:
if [ "$TUNE_FLAGS" != "" ] ; then
sed -e "s/-g -pipe/$TUNE_FLAGS -pipe/" $PATH_TO_SOURCES/indra/SConstruct >$TEMP_BUILD_DIR/SConstruct
mv -f $TEMP_BUILD_DIR/SConstruct $PATH_TO_SOURCES/indra/SConstruct
fi

# Update the manifest file and enable libkdu packaging. I'm too lazy to use
# awk or perl, here, but that's indeed what should be done...
# The following (very dirty) code may break at some point, depending on what
# LL will put in comments in the manifest file...
# First, remove the lines with libstdc++.so.6 and the crash logger:
update_manifest libstdc
update_manifest crash_logger
# Now, any line with a '#' followed with several spaces _should_ be dealing
# with the libkdu stuff... So, we simply remove the '#"...
sed -e "s/# them/# them/" $PATH_TO_SOURCES/indra/newview/viewer_manifest.py >$TEMP_BUILD_DIR/viewer_manifest.py
sed -e "s/# / /" $TEMP_BUILD_DIR/viewer_manifest.py >$PATH_TO_SOURCES/indra/newview/viewer_manifest.py
#mv -f $TEMP_BUILD_DIR/viewer_manifest.py $PATH_TO_SOURCES/indra/newview/viewer_manifest.py
rm -f $TEMP_BUILD_DIR/viewer_manifest.py
chmod +x $PATH_TO_SOURCES/indra/newview/viewer_manifest.py

# Comment out "export LL_GL_BASICEXT=x" in the wrapper script:
sed -e "s/export LL_GL_BASICEXT=x/#export LL_GL_BASICEXT=x/" $PATH_TO_SOURCES/indra/newview/linux_tools/wrapper.sh >$TEMP_BUILD_DIR/wrapper.sh
mv -f $TEMP_BUILD_DIR/wrapper.sh $PATH_TO_SOURCES/indra/newview/linux_tools/wrapper.sh
chmod +x $PATH_TO_SOURCES/indra/newview/linux_tools/wrapper.sh

# Missing file... at least in v1.17.0.0
if grep "secondlife-i686.supp" $PATH_TO_SOURCES/indra/newview/viewer_manifest.py &>/dev/null ; then
if ! [ -f $PATH_TO_SOURCES/indra/newview/secondlife-i686.supp ] ; then
touch $PATH_TO_SOURCES/indra/newview/secondlife-i686.supp
fi
fi

# LL makes the assumption that a certain unicode true type font is installed
# on all Linux systems... which is of course wrong ! Let's check, and when
# this font is absent, replace the broken soft link with an empty file: this
# at least will prevent the viewer to issue many warnings about not being able
# to load the unicode.ttf font.
if ! [ -r $PATH_TO_SOURCES/indra/newview/linux_tools/unicode.ttf ] ; then
rm -f $PATH_TO_SOURCES/indra/newview/linux_tools/unicode.ttf
touch $PATH_TO_SOURCES/indra/newview/linux_tools/unicode.ttf
fi

compile
</nowiki>
</pre>
</code>
 
 

== FreeBSD ==

A list of patches is given for [[Compiling the viewer (FreeBSD)]].

= Submitting Patches =
This is probably far down the road, but if you make changes to the source and want to submit them, see the page about [[Submitting patches|submitting patches]].