Second Life Wiki - User contributions [en]

Talk:Landmarks and Navigation Project

2009-11-09T13:23:50Z

Melissa Yeuxdoux: listed some drawbacks of current landmarks

'''Del.icio.us for SL'''

Why start with a outdated bookmark model that doesn't scale properly after many years of use. Most people that I know have so many bookmarks in their browser that they stopped using them. Wouldn't it be better to just start with a tagging model at the heart of this, instead of shoving that of as some future feature?

Tags make searching for land/book marks much easier, specifically when you made them long ago and don't remember the exact name of the place, but do know it was a shop that sold red shoes and umbrellas. And lets remember bookmarks are used for storing place you wish to '''find''' on a later date, shouldn't you use the best system that helps people find things?

I don't know (yet) if there is any opensource bookmark tagging software, but I really think that should be looked into. That way most of the development can be offloaded to web devs, and api's could be created for people to create plugins for social networking sites, blogs, etc.

You could also opt to use del.icio.us as the place where landmarks are saved, but that would make us depended on their service, which doesn't have to be a bad thing. Or see if LL can buy a license of their software and neatly hook it up with Second Life. (Or any other bookmark tagging service can be used)

[[User:Frans Charming|Frans]] 10:50, 23 April 2008 (PDT)

1. Move landmarks out of inventory? No! Landmarks as inventory items that can be passed around is a powerful metaphor.

2. Deprecate picks? Picks are my "home page" (no, I'm not going to put a web home page in my profile ... or use anyone else's ... not until LL provides hosting for it).

3. Extend web search further into SL? Not to replace landmarks, see #1.

4. The #1 thing I want is to be able to limit what landmarks show up in the map landmarks pulldown to the ones in my Landmarks folder, so it doesn't get cluttered up with dozens of duplicate "hi, you bought something at my shop, now I get to spam your map" landmarks.

[[User:Argent Stonecutter|Argent Stonecutter]] 04:46, 20 May 2008 (PDT)

== Landmarks: "Tradeable assets" ==

If landmarks are moved out of the inventory altogether (I'm a bit undecided about it; in-world, I tend to pass SLURLs more frequently, since it's far easier to open the map, create a SLURL, and copy & paste it to someone who's waiting for it in IM — to do the same for landmarks would require me to drop everything I'm doing, teleport to the destination, create a landmark, and come back), can we have a ''simple'' way of passing them as assets somehow?

They might work like the del.icio.us suggestion above, of course: a way for residents to exchange SLURLs and have them stored "somewhere" (many of us use SL on different locations with different hardware and it's nice to know that landmarks are currently persistent — stored on the grid), and easily loaded back into the client when needed. Sort of like what .Mac does for Safari, Foxmarks for FireFox, or, well, del.icio.us for pretty much any browser.

[[User:Gwyneth Llewelyn|Gwyneth Llewelyn]] 07:55, 30 May 2008 (PDT)

Gwyn your own personal use case is never a reason to bork the entire world. There are 1.5 million people here, many of whom don't even know what a SLURL is or can't make or use them but who can handle landmarks. In my experience, people have trouble with the Google-like search much much more than landmarks, and rely on landmarks as a very easy means of travel. You're talking about real-time communications and forgetting how to handle asynchronous communications that are at the heart of the SL experience given the diversity of time zones and countries, enabling people to view sites and interact with each other and trade experience outside of real-time contact.

The issue isn't the "how" of how they are passed as assets; it's assuring that they *will* remain discrete, concrete assets containable and sortable *in both prims and inventory and not just browser boxes*.

[[User:Prokofy Neva|Prokofy]] 6 November 2009

I agree that landmarks as a tradeble assests would be prefered, perhaps the inventory item could be a just a pointer to the landmark in the new landmark system.

[[User:Frans Charming|Frans]] 11:56, 31 May 2008 (PDT)

== Landmarks & Navigation Project suggestion: Mozilla Weave ==

Rather than duplicating the body of the message here, I'm merely pasting the link to the mailing list post: https://lists.secondlife.com/pipermail/sldev/2008-August/011304.html
<br />[[User:SignpostMarv Martin|SignpostMarv Martin]] 08:17, 10 August 2008 (PDT)

== Removing Landmarks as Shareable Objects Destroys Socialability and Commerce ==

This concept of removing landmarks as objects in the inventory -- and in fact removing them as objects in the world -- is all wrong.

Would you *please* stop trying to make this interactive 3-D virtual world "like a web page browser"? It's *not a web page*. It's a *world*.

You will really destroy commerce models already thriving inworld if you remove landmarks as an object that can be put in prims. Every single business in SL uses landmark giver objects onsite or in ads or gives people landmarks as part of their advertising. And that's all good.

The idea that you "can't find or use" the landmarks in inventory is false. Of course you can find them. You use "search inventory" with the name of the store or sim and the landmark is found in the search.

People constantly hand each other landmarks to interesting places precisely because there isn't enough space on the Picks. By putting these "bookmarking" functions into a browser, you remove the sharability. How will I share my landmarks if I can't push them as inventory to other people, individually?!

Again, SL is *not a web page*. It's a 3-D interactive social world that has objects in it that people share and move. Landmarks are one of them. They are sharable sortable objects and inventory access them just fine now.

It's noted in the design description that removing landmarks from the data base will be some kind of "save" for the dbase. Is that what this is all about? It doesn't seem warranted if it kills of interactivity and commerce, exchanging that robustness of socialibility and economic life for a static solo-user's experience of his own bookmarks.

--[[User:Prokofy Neva|Prokofy Neva]] 21:20, 29 September 2008 (PDT)

Uh-oh. The Lindens are back to removing landmarks again as inventoriable user-made shareable content. They want to have "the world like the web" and have instant browser-based transport with one-click travel, they appear to be getting rid of landmarks again. M Linden has indicated this in an interview today in massively.com and confirmed it with me when I asked him inworld, and said that browser-based travel would be happening but said there would still be tradeable links. How??? By cut and paste?! The landmark as an object for asynchronous travel outside of browsers but inworld in clickable objects are absolutely vital to commerce and socializing. There is absolutely no reason for this, and if they are fussing about database calls, the Lindens could police through the G-term more of the automatic spam landmark-givers all over now, that are causing clutter in inventories and accidental and excessive use of landmarks, if that is the issue.

A SLURL is not something that can be manipulated with scripts in the same way -- it would mean pasting manually into notecards and I'm not sure a randomizer or serialer script to deliver SLURLs exists or could be made. Currently such scripts have been made to deliver landmarks randomly or in serial fashion.

I have three such objects that all function with a combination of the portal script that pulls up the map with a landmark, and serializer and randomizer scripts. I'll leave aside the hundreds of hours I've spent for years creating and updating these links for travel and socializing in SL to help both newbies and oldbies, and the work that tens of thousands of merchants have done to put landmarks inside stores, rental offices, products, etc. etc. If all those landmarks in world are suddenly deprecated because of a browser solution, it leaves the world deaf, dumb, and blind utterly dependent only on closed friendship networks or groups to deliver links rather than open mechanisms of serendipity, free travel, asynchronous contacts at sites, etc.

--[[User Prokofy Neva|Prokofy Neva]] 6 November 2009

== Do Not Destroy User Generated Content ==

My mind absolutely boggles at the thought that you would want to get rid of User Picks.

This is *resident content*. *You do not get to destroy resident content*.

Deprecate picks? In favour of landmarks that will be shareable somehow? (when you're going to remove them out of the inventory? and have them shareable as...what exactly? how? off a browser? all of them at once?)

Why? People go to enormous trouble to make their Picks. It's the heart of their identity. I know as a landlord in SL that people record all kinds of special moments as well as places they like on their picks. The picks are *not just places*. The picks are a *story*. The picks have things like descriptions of your best friends. Or your business policies. Or information about using your product.

Could you people *look at how these things are actually used inworld* before you set about destroying them?!

There's no objective need to remove a page off the avatar, used to put his best selection of picks/story pages he wants to tell about his Second Life, in favour of some giant grab bug of landmarks, that does not tell that narrative.

Can you grasp that Picks are not just bookmarked spots, but *a story*? Can you please see this narrative on thousands of people and not tamper with it?!

I fail to see why your need to tinker with the viewer involves destroying what is already established *as user-generated content*. Try to remember that's what it is: *user-generated content*. Linden Lab should not be in the business of "deprecating" *user-generated content* under the guise of "new easier-to-use features".

--[[User:Prokofy Neva|Prokofy Neva]] 21:31, 29 September 2008 (PDT)

== Corrected some errors ==

I've corrected some errors in the (former) "Should we move Landmarks out of inventory?" section (including renaming it); it seems to have been originally written without an accurate knowledge of how landmarks currently work. In particular, Landmarks are not all in one huge list in inventory (this is true only of Landmarks that the user has made himself, and has not moved into other folders), although they are on the currently-useless Map "Landmarks" pulldown, and the names of Landmarks are not useless (they contain the region and parcel name, which is often exactly the right thing). The current inventory provides a powerful way (folders) to sort and organize landmarks, and this was not reflected in the existing "Food for Thought". This being a Wiki, I assume this sort of improvement is okay. :) -- [[User:Dale Innis|Dale Innis]] 06:54, 30 September 2008 (PDT)

== Restated idea about Picks ==

Residents love Picks; talking about "deprecating" them will just anger people (with good reason). What's really being talked about here is better linking Picks and Landmarks. So I've reworded (and renamed) that section to reflect that. -- [[User:Dale Innis|Dale Innis]] 07:27, 30 September 2008 (PDT)

== Fiddled with "Should we extend Web-type search further into SL? How, and how far?" some too ==

Just to correct more errors (Landmarks aren't rezzable) and to add a few more obvious thoughts. I'm somewhat concerned that the ideas represented here are some Web-Browser-derived preconceived notions, not very well informed by SL history and Resi expectations. I hope my edits have helped with this somewhat. -- [[User:Dale Innis|Dale Innis]] 07:27, 30 September 2008 (PDT)

== "To create a new navigation panel" should not be a project goal ==

New navigation panels, as fun as I'm sure they are to create, are not good in themselves. A new navigation panel should be created only if it actually makes the user experience better. -- [[User:Dale Innis|Dale Innis]] 07:34, 30 September 2008 (PDT)

== Relevant JIRA ==

There doesn't seem to be any linkage in this wiki discussion (or article) to the very relevant [http://jira.secondlife.com/browse/VWR-7900 VWR-7900] issue in the public SL jira. (This was formerly NAV-28.) This shows the outside developer's user interface, though there doesn't seem to be a lot of information about implementation under the covers. :: [[User:Latransa Pera|Latransa Pera]] 11:14, 30 September 2008 (PDT)

''I stuck in a link in the obvious place.'' -- [[User:Dale Innis|Dale Innis]] 11:46, 30 September 2008 (PDT)

== Regressed my change to "Food for Thought" ==

Since someone in a comment on Prokofy's weblog pointed out that there's a June mailinglist posting that obsoletes the entire "Food for Thought" section, this page is apparently not intended as a working document, so I've regressed it to how it used to look, and just added a note and pointers to that mailinglist posting. I think it would be great if someone on the Vectorform team or in LL, or some Resident who's following the relevant mailinglist(s), would keep this page up to date so those of us not as centrally involved could keep up, but I'm not signing up to do that myself! --[[User:Dale Innis|Dale Innis]] 07:24, 1 October 2008 (PDT)

== Landmarks, affinities, suggestions, and been there done that ==

A pointer to
[https://lists.secondlife.com/pipermail/sl-ux/2008-October/000127.html my post to SL-UX] that describes an idea for providing suggestions for places for residents to
visit similar to the "customers who bought this also bought..." systems
found on commercial web sites.

--[[User:Mm Alder|Mm Alder]] 16:35, 9 October 2008 (PDT)

== Landmarks Certainly Aren't Perfect As They Stand ==

Frankly, they're a pain in a lot of ways.

Redundant landmarks accumulate--I wouldn't mind at all if the client told me "You already have a landmark with coordinates within X meters of there--do you REALLY want to clutter your inventory?"

Landmarks become obsolete. You save a landmark because of what's there--if it moves, the landmark is useless. I'd like something that isn't a landmark but a pointer to a landmark. Vendors could hand out these new landmarks and then take the responsibility of updating the underlying landmark if the store/night club/etc. moves, rather than having untold numbers of landmarks suddenly become useless clutter. I wish I had L$1 for every time I looked at someone's picks, thought "gee, that sounds neat--I think I'll go there", clicked, and found myself falling into the sea, or at some store/building/etc. obviously _not_ the one described in the pick. (And if Picks are so darned important, why don't people update them?)

[[User:Melissa Yeuxdoux|Melissa Yeuxdoux]] 13:23, 9 November 2009 (UTC)

Talk:Build the Viewer on Linux

2008-12-31T01:33:37Z

Melissa Yeuxdoux: explanation of gcc -W option and why it complains about printf format/argument type mismatch.

I had to add "class LLUICtrlFactory;" to llui/lluictrl.h and llui/llviewborder.h to avoid a bunch of problems about that class missing --[[User:Eddy_Stryker|Eddy Stryker]]

----

== llmozlib ==

As [https://lists.secondlife.com/pipermail/sldev/2007-February/000545.html Tofu wrote (Feb 23 2007)], "you shouldn't generally need to download and build LLMozLib for a SL viewer build unless you're hacking on LLMozLib itself or porting SL to a platform which we don't supply pre-built libraries for".

Nonetheless, there's a need of instructions on
*how to '''disable''' llmozlib in [[Source_archive#2007-Feb-20|FL-1.13.3.58185]] and [[Source_archive#2007-Feb-24|FL-1.13.3.58390]] as explained at [https://lists.secondlife.com/pipermail/sldev/2007-February/thread.html#487 a thread of SLDev@lists.secondlife.com]
**Add MOZLIB=no to your Scons build command when compiling the source
'''and/or'''
*how to compile those versions '''with''' the [https://lists.secondlife.com/pipermail/sldev/2007-February/000545.html current llmozlib from ubrowser.com]
--[[User:Boroondas Gupte|Boroondas Gupte]] 06:10, 26 February 2007 (PST)
:I edited it so it's complete if you want llMozLib off, getting llMozlib compiled and working with the viewer is actually nontrivial, compiling llMozLib is just about as hard as compiling the viewer itself! [[User:Gigs Taggart|Gigs Taggart]] 08:06, 27 February 2007 (PST)
::What functionality is lost if you do not use llmozlib? [[User:Meyaden Beck|Meyaden Beck]] 20:11, 12 April 2007 (PDT)
:::You won't have any in-viewer browser windows (e.g. F1-Help) as well as no HTML login screen (you'll get the old login screen with the static picture instead). Opening pages in an external browser from within SL (e.g. links in chat/IM) won't be affected, nor will be inworld actions triggered by your external browser (e.g. SLUrl). --[[User:Boroondas Gupte|Boroondas Gupte]] 06:57, 7 May 2007 (PDT)

=== mozjs ===

A similar problem seems to be present with [[Source_archive#2007-Feb-27|beta-1.13.4.3]], only that it's '''-lmozjs''' not '''-lllmozlib''' that's failing at linktime. I can't even seem to locate the corresponding header file (expected filename 'mozjs.h') so it might well be that the problem only looks similar to the llmozlib one, but actually isn't. I'll post to the [sldev] list as soon as I have investigated this further. --[[User:Boroondas Gupte|Boroondas Gupte]] 11:22, 1 March 2007 (PST)

=== FMOD ===

This non-open-source audio library is a continuous source of irritation to open-source devotees and 64-bit devotees alike (it only comes in 32-bit), so it needs early replacement. But not replacement by another full-function audio subsystem. A much better approach is available.

Every platform has audio players available, or 20 of them, so why reinvent the wheel and bloat the client unnecessarily? Write only a software mixer to combine the various audio sources together, and present the output at an Icecast-type stream listener interface on a local socket. Then the local player of choice can connect to it just like to any Internet radio, and you're done. You can even launch the player to make it seamless.

I bet that this would make the client shrink enormously too! And the icing on the cake is that the separate player will naturally run on another core on modern multicore machines. --[[User:Morgaine Dinova|Morgaine Dinova]] 18:03, 12 October 2007 (PDT)

== Help? ==

Would it be useful to add a blurb on where people can get help compiling, specifically in Linux. Or at least an internal link to another wiki page that has a list of places to get help in each version, MAC/WIN/LIN/BSD/(however far people want to break it down, etc.).

== little helper script ==

For those of you who don't want to copy-paste from this article for every build they compile, I put a little bash script I'd liked to share in my user space: [[User:Boroondas_Gupte/unpack.sh]]. It just does a part of what's explained in this article. --[[User:Boroondas Gupte|Boroondas Gupte]] 09:59, 6 March 2007 (PST)

== Error? ==

Under the heading "fix shell scripts" there is a header file listed. can someone else confirm this should not be in that list, and if it should, why does it not have a #!/bin/sh at the top of it?

* linden/libraries/i686-linux/include/apr-1/arch/unix/apr_arch_threadproc.h

== Required Headers ==

Is there a reason that the instructions include copying header files to the source tree?

I have not attempted the install yet, that will probably be in a few days for me. However, most packages don't require the copying of header files from any standard lib into their own source directories. I am not sure if this practice is really a good one.

Will the package not compile if the headers are simply in their proper locations? If so, this is something that the developers may want to consider fixing. I would personally consider that a bug.

Normal procedure with most apps is to have the librarries propperly installed, and have the code or makefile written so that it looks in the right place. [[User:Meyaden Beck|Meyaden Beck]] 19:41, 12 April 2007 (PDT) (I forgot to sign before I think)

Autoconf is a wonderful tool. :P

:This setup is so that a fixed build of included libraries are setup for each branch and platform. The host platform can change independently of the SL build. Also, isolation of these libraries greatly reduce debug issues. There are a few patches to use the host platform's installed libraries instead. However, a few changes still need to be made for consistency. [[User:Dzonatas Sol|Dzonatas Sol]] 11:58, 12 April 2007 (PDT)

::Hmmm... I see, I think. My next question (and if I get the time I may fix this one myself), why the choice to pretty much ignore compilation of llMozlib? Stating that "Compiling it is a pain, and this is how you disable it", doesn't look good. I haven't gotten that far in my current Linux install yet. I just finished installing XFce4, but as soon as I get OpenOffice.org and Blender installed, I will likely move on to Second Life. When I do, I will go through the steps of compiling llMozlib and take notes on what I did to make it work. :-) I should probablly also make sure to include a warning that I am using an LFS build. However, the instructions the LFS site uses to build most packages should theoretically work for just about any system. ^_^[[User:Meyaden Beck|Meyaden Beck]] 19:41, 12 April 2007 (PDT)

----
Hmm. I believe older versions of this page clearly showed instractions for those who just want to compile viewer only and for those who want to build everything. I believe the older style is better.

Are there anyone who objects to such reorganization?

--[[User:Alissa Sabre|Alissa Sabre]] 22:51, 8 June 2007 (PDT)

I agree to every kind of reorganization, since this page is a bit messy. We should provide a simplified version of it, at least. I think it's a bit scary for newbies. So today I moved the 'Packaging errors' section to Common compilation problems page (we may want to give more visibility to that link); I removed the 'Fix Shell Scripts' because I think it has been fixed; I added some questions where I think we need to being more informative; It looks like you only need to add FMOD=no to the scons command, and I think we should give this information only - i'm not sure about this, so in the meantime I just made some changes to both 'Prerequisites' and 'Copy headers and libraries into the source tree' sections.

Please reverse my changes if not appropriate! I'm OK with a reorganization of this page. Pleae do a new page version for every edit, using proper comments, so revert is easier.
--[[User:Signore Iredell|Signore Iredell]] 06:42, 9 June 2007 (PDT)

----

Note that gcc-3.4 is NOT required, patches to fix compiling on gcc 4.x were among the first to be merged after the source release. I've been compiling with gcc 4.x from the beginning and it works fine. I'm not sure how to rework the article though, SConstruct is hardwired to call g++-3.4 which won't even work with Fedora's compat compiler (which is named g++34), which does not seem to be mentioned in the article either. Please merge VWR-218 ;P [[User:Seg Baphomet|Seg Baphomet]] 12:39, 13 June 2007 (PDT)

== Gentoo 64bits? ==

Hello,

Did anyone get it compile on Gentoo 64bits? [[User:Iann Alderson|Iann Alderson]] 04:19, 7 October 2007 (PDT)
* Needed packages:
** dev-libs/boost
** dev-util/scons
** media-libs/gstreamer

Ok, it compiles alright for well over an hour, which is better than I expected. ;o)

But the, I get

<pre>
cc1plus: warnings being treated as errors
/tmp/yann/usr/local/src/linden/indra/i686-linux-client-release/newview/viewer.cpp: In function 'BOOL do_elfio_glibc_backtrace()':
/tmp/yann/usr/local/src/linden/indra/i686-linux-client-release/newview/viewer.cpp:2423: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
scons: *** [/tmp/yann/usr/local/src/linden/indra/i686-linux-client-release/newview/viewer.o] Error 1
scons: building terminated because of errors.
</pre>

Does anyone know what that means? Thanks, [[User:Iann Alderson|Iann Alderson]] 11:24, 7 October 2007 (PDT)

It's been a while, but for completeness's sake: gcc lets one make the compiler very finicky, so that things that are normally just warnings are considered errors that will make the compile fail--that way you can fix more stuff at compile time, rather than leaving possible errors to barf at runtime. In this particular case, someone has a *printf() call that has a constant format string, so that the compiler can type check the corresponding arguments, and there's a %d (which is used to print int values) corresponding to a value of type size_t, which is typically unsigned, and for a 64-bit system may well be larger than int, which is likely to make printf fail to properly access any following values to be printed. --[[User:Melissa Yeuxdoux|Melissa Yeuxdoux]] 01:33, 31 December 2008 (UTC)

http://pastebin.ca/729141

Talk:Viewer Visual Update

2007-11-02T23:23:16Z

Melissa Yeuxdoux: /* Feedback on the style itself */

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

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

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

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

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

Snapshot resources

2007-04-29T20:18:41Z

Melissa Yeuxdoux: /* Useful utilities */ Noted that Picasa does now have a Linux version

The following consists of miscellaneous info which often isn't easy to find, but very useful if you take Second Life snapshots, including postcards. Historically, documentation in this area has been sparse, and Residents have provided some great resources, so this is an ongoing endeavor at compiling those in an easy place — please help keep this updated!

== A state of snapshots ==
The history of snapshots in Second Life hasn't been well-chronicled. Every Resident ''vérité'' takes a picture at one point during their Second Life or another, but until recently, there's been a poor understanding of fundamental "pillars", including how many postcards get sent out, how many snapshots are uploaded to inventory, as well as the finer points of taking beautiful pictures.

Dismissing snapshots as "just for fun" neglects much context: in increasing amounts, the first exposure someone who's not yet part of Second Life may get of our world are Resident-taken snapshots. Especially on sites with a much broader audience like [http://www.flickr.com/photos/torley/ Flickr], the art of fine photography helps communicate our passion for capturing real emotions experienced in our online world.

In addition, taking better snapshots also helps increase your self-confidence. Snapshots require a combination of skills, including precise camera control, knowledge of lateral features (like adjusting the sun to get desired lighting), and frequently, avatar customization. Putting all of them together to get "the perfect shot" is a testament to how "[http://en.wikipedia.org/wiki/Meta meta]" quality snapshotting can be.

Better snapshots also hint at dreams for a lovelier Second Life. Applied post-processing effects are done in absence of the ability to perform the same magic in realtime. But as new features emerge, avid virtual shutterbugs can indulge in them, and build on their repertoire of techniques used to create beauty as they see it! For example, the [http://torley.com/be-luminous-enjoy-with-renderglow-true RenderGlow] ([[Help:Glow_Rendering|more info]]) feature added in 1.15, and planned to be a more accessible part of the interface, has already captured the imaginations of photogs in search of softer looks.

So where do we stand today? Bert Linden recently began work on regular metrics reports for postcards. For the first quarter of 2007, over 300,000 postcards were sent out. That's substantially more than the almost-269,000 sent during the whole year of 2006! We've seen an enormous surge in postcard sending, much of it prompted by the new Orientation Islands, which feature a postcard station as a basic first step in learning your Second Life. Also, as Resident-run social sites continue to expand, there can be no stopping the sharing!

With so much photographic activity trackable, and much of it not (we don't know how many snapshots you saved to disk), it's clear that more resources prominently be put forth to educate and entertain snapshot enthusiasts, new, old, and everything in-between. By improving our quality in quantity, we gain more of an appreciation for the Grid we live on, and preserve our digital cultures in ways never thought possible before. All of this also challenges preconceived norms: parallel to [http://en.wikipedia.org/wiki/Machinima machinima] being taken seriously, are Second Life snapshots merely ''computer screenshots'', or a ''new form of art''? Hindsight will make us wiser, as it tends to do.

In the present, as the old adage goes, "practice makes perfect", and what's important is you're enjoying yourself as you "capture the moments". The resources below are intended to aid in rewarding your continued self-discovery.

Enjoy your photographic memories!

: -[[User:Torley Linden|Torley Linden]], 2007-04-26

== Tips 'n' tricks ==
From the [http://secondlife.com/knowledgebase/ Knowledge Base] (these links may break soon as we move to a new KB system, please fix them if you notice they're broke!):

* '''[http://secondlife.com/knowledgebase/article.php?id=132 How do I take pictures or snapshots of things inworld?]''' - Start here first!

* '''[http://secondlife.com/knowledgebase/article.php?id=176 Guide to the snapshot window's options]''' - Intermediate-level skillz!

* '''[http://secondlife.com/knowledgebase/article.php?id=393 Advanced Snapshot Magic]''' - A video tutorial that shows you how to zoom, get great lighting effects, and more. You'll also want to see the "personal lighting" tip in [http://secondlife.com/knowledgebase/article.php?id=394 this followup installment].

Did you know you can:

* '''[http://secondlife.com/knowledgebase/article.php?id=391 Save textures to your hard drive?]''' For example, if you've uploaded snapshots to your inventory, this lets you export them so you can upload them to other sites and post them outside of Second Life.

* '''[http://torley.com/snapshot-tip-turn-render-ground-off Hide the ugly gap between the water and horizon?]''' (This is workaround for a bug, SL-24381.)

* '''Hide foot shadows?''' [http://secondlife.com/knowledgebase/article.php?id=339 Client menu] > Rendering > Features > Foot Shadows.

* '''[http://www.flickr.com/groups/secondlife/discuss/72157600062846532/ Use "Slow Motion Animations" to make action shots easier?]'''

* '''[http://www.flickr.com/groups/secondlife/discuss/72157600055309030/ Move the camera around while taking a freeze-frame snapshot?]''' Great for getting an ideal angle with little fuss.

* '''[http://emmanowhere.blogspot.com/2007/04/using-flickr-photos-in-second-life.html Use Flickr photos as streaming media in SL?]'''

Also:

* '''Changing image size and quality settings has ''no'' effect on sending postcards.''' Postcards will always be 640x480 (or smaller, depending on aspect ratio) and have [http://torley.com/bigger-better-postcards-for-sl lousy JPEG compression]. This is a bug (internally, SL-21141) which has persisted to this day. Hopefully, it'll be fixed. It hasn't been reported in the [https://jira.secondlife.com/ Issue Tracker] yet, but if you happen to, garner support from fellow Residents with votes and let [[User:Torley Linden|Torley Linden]] know.

== Social sites featuring postcards ==
* '''[http://slpics.com Snapzilla]''' - The original pioneer to really make use of postcards in such a widespread manner, its success has encouraged many Residents to share their inworld memories. As of April 2007, Snapzilla currently boasts over 150,000 pictures and is en route to a "2.0" upgrade.

* '''[http://slbuzz.com SLBuzz]''' - Postcards are [http://snapshots.slbuzz.com/search part of] SLBuzz's community site offerings. It also allows uploading of [http://photos.slbuzz.com/search photos] from your hard drive.

* '''[http://slprofiles.com/postcards.asp SL Profiles]''' - This page allows you to quickly add Second Life pictures to your profile on this community site.

* '''[http://flickr.com Flickr]''' - The popular photo-sharing service. They recently abolished their [http://tinyurl.com/2f4hx6 NIPSA restrictions] in favor of a [http://blog.flickr.com/flickrblog/2007/03/introducing_fil.html content filtering system], so Residents can show their SL snapshots in public searches.
** Via '''[http://www.sluniverse.com/pics/flickr.aspx Snapzilla-to-Flickr]''' and '''[http://snapshots.slbuzz.com/crosspost SLBuzz-to-Flickr]''', Residents can crosspost to another service to have their pictures also show up on Flickr, where they can be easily organized.
** '''[http://www.flickr.com/groups/secondlife/ Flickr's Second Life group]''' - The largest. Look inside the [http://www.flickr.com/groups/secondlife/discuss/ discussion] area for varied photographic tips 'n' tricks.
** '''[http://www.flickr.com/groups/secondlife/discuss/72157594588674941/ Links to all Second Life Groups on Flickr]''' - There are many Second Life-related groups. More keep appearing, so this likely isn't "all" of them — add ones you notice are missing!
** You can also use Flickr's [http://www.flickr.com/tools/ tools] to upload snapshots from your hard drive, and there are a variety of 3rd-party amusements like [http://bighugelabs.com/flickr/ fd's Flickr toys] and [http://www.dumpr.net/ Dumpr] which you can apply to your images.

== Useful utilities ==
Add programs you've personally found valuable.

* '''[http://picasa.google.com/ Picasa] (free, Windows and Linux)''' - Elegant photo organizer. Add your folders to be scanned and perform some light image enhancement while you're at it.

* '''[http://www.den4b.com/projects.php ReNamer] (free, Windows-only)''' - Batch-renames your files. Great for taking a heap of snapshots named "Snapshot" and turning them into something more descriptive. Also see [http://torley.com/renamer-great-utility-to-rename-your-files Torley's review].

* '''[http://www.cs.ubc.ca/~mbrown/autostitch/autostitch.html Autostitch] (free, Windows-only, Mac and Linux versions planned)''' - Easy-to-use 2D image stitcher that turn a collection of snapshots into a breathtaking, wide-angle panorama. Also see [http://torley.com/tutorial-how-to-make-a-beautiful-second-life-panorama-in-15-minutes/ Torley's tutorial] on how to specifically use it with Second Life.

* '''[http://www.optikvervelabs.com/ virtualPhotographer] (free, Windows-only)''' - Incredibly tasty little Photoshop plugin to add extra "pop" to your snapshots. Had a nice collection of presets and can simulate film grain, sepia, bloom, etc.

* '''[http://www.gimp.org GIMP] (free, Windows, Mac and Linux )''' GNU Image Manipulation Program. It is a freely distributed piece of software for such tasks as photo retouching, image composition and image authoring. It works on many operating systems, in many languages. Pretty much anything you can do in Photoshop you can do in GIMP

== Related resources ==
You may also be interested in seeing this wiki's compilation of:
* '''[[Texture Tools]]''' - Image-editing stuff you can use to prettify your pictures. Some overlap with this page.
* '''[[Video Tutorials]]''' - An assortment of multimedia guides, good for those who enjoy seeing how things actually work inworld.