Re: [opensource-dev] the snowstorm backlog

[Yoz Grahame]

On 17 August 2010 23:34, Lance Corrimal  wrote:

> ...what's with that google spreadsheet, I thought there's the jira?
>

Good point! But the JIRA interface isn't great at backlog organisation with
Scrum. Now if only there was some kind of Scrum-focused add-on that we could
use for managing scrums and the backlog in a nice JIRA-integrated and
publicly-visible way...

http://www.atlassian.com/software/greenhopper/

I guess we'd better do that, then.

(I was actually in the middle of drafting the blog post about it when I saw
this. I should probably stop reading mail and get back to it.)

-- Yoz
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Henri Beauchamp]

On Tue, 17 Aug 2010 19:55:53 -0700, Kelly Linden wrote:

> (lets move this to the scripters list?)
> 
> I need to refresh myself on this. There should be 3 names:
> user name: latif.khalifa
> full name: Latif Khalifa
> display name: The Awesome Latif
> 
> Most (all?) the existing LSL functions will return the 'full name'. I also
> find it confusing to use Kelly DifferentLastName as an example display name.
> This isn't about picking a new last name. It is about being just 'Kelly' or
> 'Teh Kellz'. Sorry, it was just part of what was confusing me about the
> previous examples.
> 
> A new user is:
> user name: john1234
> full name: john1234 Resident
> display name: john

Why restricting new user names to "Resident" ?

It will only make the choice for the first name more dificult, since
"John" will be taken by the first new resident registering it, and then
others will have no other choice than to use numbers or weird characters
to register and we will end up with IRC-like names like John12345 and
John54321, which will make it only more difficult to distinguish all the
Johns from each others in-world (for identification purpose, such as
objects ownership, anti-griefing and stuff).

Why not, instead, letting the new user choose their full name (first
and second name) as they wish (provided it doesn't collide with an
existing one, of course), just like what happens in almost all OpenSim
grids ?

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Lance Corrimal]

On Wednesday 18 August 2010 10:20:03 Henri Beauchamp wrote:


> Why restricting new user names to "Resident" ?

It's not a restriction.

the whole thing, as far as i can see, boils down to this:

there's the login, and the display name.

the login is _one_ word, chosen at account creation, and will stay the same 
forever. For example, it could be something like andromeda02 or whatever.
the display name can be anything, and can be changed once a week.
So if you would create a new account for whatever reasons, you could choose 
feedledumthebard as your login, and set your display name to "Henri Beauchamp 
the 2nd."

What will happen to old accounts is that their login will be constructed by 
using their avatar name, lowercase, and connecting the two pieces with a dot, 
and by default their Display name will be the original avatar name.

So, in my case, my login will be lance.corrimal and my dosplay name will be 
Lance Corrimal.

and in an old viewer with no display name support it will stay that way.

Now what about the fictive new account that you created?
the login name is feedledumthebard.
the display name is "Henri Beauchamp the 2nd"
and in an old viewer with no support for display names it'll show as:
"feedledumthebard Resident".


> 
> It will only make the choice for the first name more dificult, since
> "John" will be taken by the first new resident registering it, and then
> others will have no other choice than to use numbers or weird characters
> to register and we will end up with IRC-like names like John12345 and
> John54321, which will make it only more difficult to distinguish all the
> Johns from each others in-world (for identification purpose, such as
> objects ownership, anti-griefing and stuff).


only for their LOGIN, which will not be the Display Name.

Display names do NOT have to be unique.

Think of display names as "group titles that don't need a group to be in", and 
it becomes more clear.

The fact that display names don't have to be unique opens the biggest can of 
worms though.

What keeps me from, lets say, creating a throwaway alt, setting its Display 
Name to "Stiletto Moody", and hanging out at that famous shoe shop telling 
people that the place will close down and that all rights to the designs have 
been sold to (whatever the place is that will sell copybotted versions).
Other than the fear of having that throwaway alt getting permanently banned in 
maybe a year or two when the g-team gets around to doing it.

What keeps me from setting the display name to the name of a well-known land 
baron, hanging out at their hub, telling prospective tenants that there's no 
free land but "so and so that we're cooperating with still has a few free 
homesteads"...?

The fact that the login name can be seen in the profile does NOT mean that 
people will understand the difference, or pay attention to it.

Keep in mind that there are LONG TIME RESIDENTS who still don't know how to 
read a notecard. That paints a pretty black prospect of the mental capacities 
of the generic noobie...



IF those display names arenot shot down before rollout (hopefully they are) 
there needs a BIG section on discovery island covering them, and how to avoid 
being scammed.


bye,
LC
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Tateru Nino]

On 18/08/2010 6:50 PM, Lance Corrimal wrote:

On Wednesday 18 August 2010 10:20:03 Henri Beauchamp wrote:



Why restricting new user names to "Resident" ?

It's not a restriction.

the whole thing, as far as i can see, boils down to this:

there's the login, and the display name.

the login is _one_ word, chosen at account creation, and will stay the same
forever. For example, it could be something like andromeda02 or whatever.
the display name can be anything, and can be changed once a week.
So if you would create a new account for whatever reasons, you could choose
feedledumthebard as your login, and set your display name to "Henri Beauchamp
the 2nd."

What will happen to old accounts is that their login will be constructed by
using their avatar name, lowercase, and connecting the two pieces with a dot,
and by default their Display name will be the original avatar name.
That's where we connect with the viewer. Input and presentation. I can't 
say as I'm thrilled by the account name being shown as 'tateru.nino' in 
every place that the account name is displayed (or expected) by the 
viewer. I've got capital letters and a space in my original name, after 
all - and my expectation would be for the account-name to preserve that 
(or if it is transforming it because the schema can't handle an 0x20, to 
conceal that transformation from the viewer presentation layers insofar 
as is possible to do so).


Heck, make my account/login '93ede1c5e1363385eb577efc312ae11d' and I'm 
still just as happy - so long as what is /displayed /and /typed /as my 
account name is still "Tateru Nino"


Having my account name visibly changed as a part of the process 
(regardless of what is or is not done with display names) seems 
unnecessary and lazy.

So, in my case, my login will be lance.corrimal and my dosplay name will be
Lance Corrimal.

and in an old viewer with no display name support it will stay that way.

Now what about the fictive new account that you created?
the login name is feedledumthebard.
the display name is "Henri Beauchamp the 2nd"
and in an old viewer with no support for display names it'll show as:
"feedledumthebard Resident".



It will only make the choice for the first name more dificult, since
"John" will be taken by the first new resident registering it, and then
others will have no other choice than to use numbers or weird characters
to register and we will end up with IRC-like names like John12345 and
John54321, which will make it only more difficult to distinguish all the
Johns from each others in-world (for identification purpose, such as
objects ownership, anti-griefing and stuff).


only for their LOGIN, which will not be the Display Name.

Display names do NOT have to be unique.

Think of display names as "group titles that don't need a group to be in", and
it becomes more clear.

The fact that display names don't have to be unique opens the biggest can of
worms though.

What keeps me from, lets say, creating a throwaway alt, setting its Display
Name to "Stiletto Moody", and hanging out at that famous shoe shop telling
people that the place will close down and that all rights to the designs have
been sold to (whatever the place is that will sell copybotted versions).
Other than the fear of having that throwaway alt getting permanently banned in
maybe a year or two when the g-team gets around to doing it.

What keeps me from setting the display name to the name of a well-known land
baron, hanging out at their hub, telling prospective tenants that there's no
free land but "so and so that we're cooperating with still has a few free
homesteads"...?

The fact that the login name can be seen in the profile does NOT mean that
people will understand the difference, or pay attention to it.

Keep in mind that there are LONG TIME RESIDENTS who still don't know how to
read a notecard. That paints a pretty black prospect of the mental capacities
of the generic noobie...



IF those display names arenot shot down before rollout (hopefully they are)
there needs a BIG section on discovery island covering them, and how to avoid
being scammed.


bye,
LC
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges



--
Tateru Nino
http://dwellonit.taterunino.net/

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Henri Beauchamp]

On Tue, 17 Aug 2010 19:24:48 -0700, Yoz Grahame wrote:

> On 17 August 2010 02:44, Henri Beauchamp  wrote:
> 
> > On Mon, 16 Aug 2010 19:27:34 -0700, Yoz Grahame wrote:
> >
> > > Linden Lab has the final say in what goes into the Linden Lab viewer. A
> > > third-party viewer team has the final say in what goes into their viewer.
> >
> > Indeed, but if LL is so close-minded as to reject any change to the UI
> > that would allow v1 lovers to adopt v2, then there is no chance that
> > any v1 developer will migrate to the v2 code base...
> >
> 
> That's not what I meant, and if I gave that impression, I apologise.
> 
> Requests for well-specified elements of the v1.x UI, backed up by reasoned
> arguments, are something we can put in the backlog for discussion. Requests
> for either reverting the entire v2.x UI to that of v1.x, or keeping both
> running in parallel, will not make it into the backlog; firstly because
> neither is feasible for us, and secondly because such a request in no way
> helps us to focus on what the specific UI problems are.

I tend to disagree strongly with the "non-feasability" of a dual-fold UI,
especially when taken, element per element.
As an example, I could take the pie menu: someone in this list
(Aidan Thornton) gave damned good reasons for reverting the v2 UI
context menus on avatars and objects to pie menus, which I would fully
second.
It is *perfectly* possible to let the user choose between both via an UI
setting that when changed would take effect after a viewer restart (I
implemented such settings for other UI elements in the Cool VL Viewer,
so I know first hand what I'm speaking about here): this would make
everyone happy and could be contributed to Snowtorm code base by open
source developers.

Now, think about your stance: if you keep refusing such changes on the
pretext it's "not feasible", here is what will happen:

- TPV developers will first stay with the v1.23/SG v1 viewer code base
  and will keep producing backport patches for the few new features of
  v2 that are necessary or useful to keep up using SL. To give you a
  little idea of how long this statu quo could last, I'll simply cite
  my own experience with the v1.19 code base: I could maintain it from
  november 2007 to this year, and only decided this year that I'll stop
  maintaining it (for the backports become more and more difficult and
  time consuming). QUESTION: Do you want to delay the contributions to
  Snowstorm by TPV developers by 2 years ? Sure, you might still be
  able to incorporate some of the new features developed in TPVs, but
  you will have to do it *yourself*, because no TPV developer will
  bother submiting patches for Snowstorm during this period !

- TPV developers will then finally (and reluctantly) migrate to the v2
  code base and will concentrate their efforts on reverting all UI
  elements they know their users dislike (or simply can't accept !),
  which will hamper their ability to produce new useful features by
  consuming their time on things that could have been changed earlier
  (by spending the time they "lost" producing backports to implement
  the UI switches in Snowstorm instead). Also, they will change the UI
  in a way that doesn't preserve the v2 way of doing things, since I
  don't see anyone (but for Lindens...) bothering with something that
  80% of the SL user base rejects. Instead of having the UI changes
  implemented as options in Snowstorm, you will then end up with
  radical and incompatible changes implemented in TPVs and as many
  forked v2 viewers that will keep attracting like magnets SL users,
  making Snowstorm look like the ugly duck. QUESTION: do you think it
  is at all producive ? For LL ? For us, OS developers ? The answer to
  the latter is "no, but we won't have a choice, it's LL's fault !".

> There have been several hundred UI changes between 1.23 and 2.1.1, ranging
> from the creation of the sidebar to individual checkbox relocation. Many of
> those came from resident feedback,

Oh ?... Where are the polls about the changes you made, behind the
scene ?

In fact this "resident feedback" is simply the result of a ridiculous
minority of very vocal residents who took the time to give you *their*
feedback. Don't you see the *REAL* feedback of your *CUTSOMERS BASE* as
a *WHOLE* ?... just LOOK at the v2 usage stats on the grid, damned it,
and stop the corporate lies, *pretty* please !

I can understand that LL is pissed off that the amount of money and
time they spent in viewer 2 results in the end in 80% of their
customers rejecting it, but I (and with me, 80% of the residents)
*can't* understand your suicidal stance which consists on trying to
force the new UI of viewer 2 down everyone's throat !

> or from many hours of user experience testing.

Are you speaking about the closed beta testers who now complain that
their feedback wasn't listened to and even less taken into account ?
And how did you choose these few beta-testers ?... How would they
r

Re: [opensource-dev] Open Viewer Development Announcement

[Argent Stonecutter]

On 2010-08-16, at 13:23, Henri Beauchamp wrote:
> Well, the first improvement to do is to actually revert 80% of the UI
> to the way v1.23's one was working, especially getting rid of that
> moronic side bar is its modal tools which impair productivity and
> user-friendliness... The question is: will LL finally admit that the
> viewer 2 UI is a failure and widely rejected by 80% of its regular user
> base, and accept a move in the way of "going back" (actually repairing)
> UI-wise ?...

At this point I just want to see them fix the focus in Viewer 2, so that the 
chat bar is part of the world (and stays focussed when you interact with 
in-world objects), at least as an option.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Mailing lists for viewer-development commits & builds

[Oz Linden (Scott Lawrence)]

 Commits to the http://hg.secondlife.com/viewer-development repository 
now generate email notices to the mailing list 
viewer-development-comm...@lists.secondlife.com


You can subscribe with the usual mailman mechanisms - the URL for the 
lists info page is:


   
https://lists.secondlife.com/cgi-bin/mailman/listinfo/viewer-development-commits

I've got a list set up for build notices (same addresses as above, but 
'viewer-development-builds'), but actually sending the notices to it 
from TeamCity is not working yet.



___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Jesse Barnett]

(Illustrative example)
I am so relieved that Linden Lab does actually listen to feedback from the
residents that have supported it for so long. This should guarantee that the
proposed user name/display name never goes into affect then.

Back to OP subject thou; the spreadsheet does look pretty good and gives
more hope then any of the discussions so far.

Jesse Barnett
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[David M Chess]

Lance wrote:

> What keeps me from, lets say, creating a throwaway alt, setting its 
Display 
> Name to "Stiletto Moody", and hanging out at that famous shoe shop 
telling 
> people that the place will close down and that all rights to the designs 
have 
> been sold to (whatever the place is that will sell copybotted versions).
> Other than the fear of having that throwaway alt getting permanently 
banned in 
> maybe a year or two when the g-team gets around to doing it.

This isn't much different from what you can do today, by creating a 
throwaway group with the tag "Moody Customer Service" and doing the same 
thing. 

Is it a huge problem?  I don't see any evidence that it is.  It does 
happen occasionally, but y'know: welcome to Earth.

Will it become a huge problem with it can be the display name, rather than 
the group tag, that can be anything? 

I don't see any reason to think so, myself. 

Certainly it *will* be a good idea to stress to people that display names 
can be anything.  But of course since everyone will have chosen their own, 
and known that they could choose anything, they will sort of know that! :)

DC
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[David M Chess]

Jesse wrote:

> I am so relieved that Linden Lab does actually listen to feedback from 
the residents that have supported it for so long. This should guarantee 
that the proposed user name/display name never goes into affect then.

I don't think that what you're implying there is true at all.  I know the 
Lab has heard from *many* folks that they'd like to be able to choose 
their names, rather than having to pick a first name and one of a list of 
set last names.

On the other hand, there have been less than a dozen people here 
complaining about it, and something like half of the complaints have been 
due to misunderstanding the impact it will have on scripts etc.  (That 
page in the Wiki really needs work!)

This is one issue where I think the Resi (and potential Resi) feedback 
would be overwhelmingly in favor of the change.  So not a good one to 
choose for the inevitable "they aren't listening!!" message.  :)

DC

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Argent]

Well, look there, the ability to type in chat while interacting with objects
in the world isn't on the spreadsheet anywhere.

This is a complete show-stopper for viewer 2 for me, and for many of my
friends who interact primarily in text and do not use voice chat.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Argent]

On Tue, Aug 17, 2010 at 6:47 PM, Michael Schlenker  wrote:

> Am 18.08.2010 um 01:16 schrieb Bryon Ruxton:
> > And 2. you should also prevent anyone to use a display name baring the
> name
> > of an existing username in my opinion.
>


> NO. That would limit the usefulness for some kind of RP for sure.


Can you elaborate on what kind of RP would require you to be able to set
your display name to "Argent Stonecutter"?
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Timothy Horrigan]

Scripters have already had to deal with the case where an avi's name 
changes.  The Lindens have always had the option to rename avis (e.g., 
if an offensive name falls through the filters during registration, if 
an innoucuous name becomes offensive due to news events, if a Linden 
loses his or her job, etc.)  That's why most scripts specify the 
identity of a user through his or her UUID rather than his or her name.  
In fact the only way to use the avi name in a script is to have it first 
look up the UUID.


--Tammy Nowotny (I forget what my UUID is)



David M Chess wrote:


Jesse wrote:

> I am so relieved that Linden Lab does actually listen to feedback 
from the residents that have supported it for so long. This should 
guarantee that the proposed user name/display name never goes into 
affect then.


I don't think that what you're implying there is true at all.  I know 
the Lab has heard from *many* folks that they'd like to be able to 
choose their names, rather than having to pick a first name and one of 
a list of set last names.


On the other hand, there have been less than a dozen people here 
complaining about it, and something like half of the complaints have 
been due to misunderstanding the impact it will have on scripts etc. 
 (That page in the Wiki really needs work!)


This is one issue where I think the Resi (and potential Resi) feedback 
would be overwhelmingly in favor of the change.  So not a good one to 
choose for the inevitable "they aren't listening!!" message.  :)


DC



___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Lance Corrimal]

On Wednesday 18 August 2010 14:58:07 Argent wrote:
> Well, look there, the ability to type in chat while interacting with
> objects in the world isn't on the spreadsheet anywhere.

why would you need to type anyways when you can use voice... and if you don't 
want others to hear your voice you can simply buy a morph!

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Oz Linden (Scott Lawrence)]

  On 2010-08-17 0:16, Joel Foner wrote:
> Providing text transcription of voice speakers for the disabled, as 
> well as those who for various reasons cannot enable voice at the time, 
> and for capture of a text searchable archive of the whole event, is a 
> solved problem. Totally solved. It needs no figuring out or 
> experimentation.
>
> Real-time voice to text transcription by a person during the event, as 
> well as an after-the-fact voice recording to transcription can be 
> done, and is often done, in Second Life, in various presentation, 
> discussion and meeting contexts. It costs some real money, but not an 
> outrageous amount for the service provided, and this has been done 
> inworld for years in various settings, providing ample precedent for 
> the fact that this approach "just works" just fine in Second Life.

We'll be doing most of our meetings in chat (or at least with as much 
substantive information as possible in chat).

If you are at one of our regular meetings and feel you're unable to 
follow what's happening, please let us know and we'll do our best to do 
better.

We don't have a budget to pay for transcribers, but we'll do what we can 
to make what we do accessible short of that.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Oz Linden (Scott Lawrence)]

 On 2010-08-18 6:38, Henri Beauchamp wrote:

- DO NOT SEGREGATE SUBMISSIONS: since you made Snowstorm LGPL, there
   is now*no more need*  for the FLOSS exception and for contribution
   agreements (since you can take a snapshot of the Open Source viewer
   at anytime and incorporate them to your own closed source viewer,
   and this without any LGPL contributor additional permission).


There is no longer any FLOSS exception; as you point out, it would be 
redundant with the LGPL.


We still do require a Contribution Agreement, for good and valid reasons 
I've explained many times - most notably that it allows us to improve 
our license in the future.  Had we not required the CA in the past, we 
would not have been able to change from GPL to LGPL.



___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Oz Linden (Scott Lawrence)]

  On 2010-08-18 8:58, Argent wrote:
> Well, look there, the ability to type in chat while interacting with 
> objects in the world isn't on the spreadsheet anywhere.
>
> This is a complete show-stopper for viewer 2 for me, and for many of 
> my friends who interact primarily in text and do not use voice chat.
>

That list is not static.  Feel free to suggest additions.

It's also true that the Snowstorm Product backlog is not the complete 
list of what LL is doing in the viewer - there are other teams (which 
may vary in how visible they make their own lists).

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Arrehn Oberlander]

I realize that there's pros and cons to this UI selection vs box
popups. However I don't believe the choice is at all cut and dry. When
I stopped using the pie menu (because it doesn't exist in viewer 2.x)
I discovered all sorts of navigation difficulties that where
previously unknown.


- The box dropdown requires the user to have greater precision and
care when making selections
- The pie menu supported muscle-memory for choices better
- The pie menu does a better job of hiding the rarely used options and
conversely making the most popular options highly visible.
- The pie menu obscured less of the screen when it was active
- The pie menu as implemented does a better job of cloaking/disabling
unusable choices, the box menu greys them out but they are still
visually harder to navigate.
- The pie menu always pops up directly under the cursor, the box menu
pops up to an indeterminent side depending on position. This is more
predictable behavior and requires less mouse movement.
- There's a large number of users already familiar with the pie menu.
- After using both methods for a while, the pie menu is my personal
preference by a fair margin.


I looked at the XUI API docs to see what would be involved in bringing
them back. I was concerned to see that the pie menu status lists as
"deprecated". I believe this should be re-examined and hopefully be in
the backlog for debate.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Oz Linden (Scott Lawrence)]

  On 2010-08-18 11:54, Arrehn Oberlander wrote:
> I looked at the XUI API docs to see what would be involved in bringing
> them back. I was concerned to see that the pie menu status lists as
> "deprecated". I believe this should be re-examined and hopefully be in
> the backlog for debate.

I'm going to channel comments I've heard Q make here because he's not 
able to do it himself at the moment.

While there were some good things about the v1 implementation of pie 
menus, they also had some flaws - such as not opening a submenu centered 
on the mouse click.

I think that if someone were to step up and do the work to create a 
better pie menu implementation that we could do good comparisons with 
(and especially if it allowed menu style to be a preference setting), 
then it would be a much more interesting discussion.

Note: that in no way should be interpreted as "we would take it if it 
happened" - I can't make any such commitment on my own at this time.  If 
someone wants to sign up for the work, I'm willing to sponsor the 
discussion.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Adding open dev items to the Snowstorm sprint

[Oz Linden (Scott Lawrence)]

 To be a candidate for integration during the current two-week 
Snowstorm sprint, a change should be on the Snowstorm Sprint list 
.  
If it is not, then we can't be sure that we'll have the review and 
integration resources ready in time (which at worst means it waits for 
the next sprint to be re-prioritized, so it's not as bad as all that).


If you are or would like to be working on an item that is on that list 
now, or you have some item you'd like us to be considering for adding to 
it, the window is open, but not for long.  Send mail to Esbee and I 
today, or come to my Office Hours today with what the issue is and what 
you'd like to do about it.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Aidan Thornton]

On 8/18/10, Oz Linden (Scott Lawrence)  wrote:
> While there were some good things about the v1 implementation of pie
> menus, they also had some flaws - such as not opening a submenu centered
> on the mouse click.

I actually puzzled over this a bit when I first realised that Second
Life's pie menus worked this way. Originally, the pie menus worked
well when you didn't click too close to the edge of the screen but
didn't actually open under the mouse cursor if you did. Since the
"More..." item is sensibly always the southmost one, opening new
submenus centered on the mouse would cause the pie menu to drift down
the screen until it hit the bottom and caused problems.

Also, opening the submenu at the same location has the nice
side-effect that the mouse remains over the "More..." option for the
pie menus that are nested 3 or more levels deep.

What I have been contemplating is how to make it possible to open the
next layer of a pie menu without moving the mouse at all. Sadly, it'd
probably break too much from normal UI conventions to be worth doing.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Michael Schlenker]

Am 18.08.2010 um 15:05 schrieb Argent:

> On Tue, Aug 17, 2010 at 6:47 PM, Michael Schlenker  
> wrote:
> Am 18.08.2010 um 01:16 schrieb Bryon Ruxton:
> > And 2. you should also prevent anyone to use a display name baring the name
> > of an existing username in my opinion.
>  
> NO. That would limit the usefulness for some kind of RP for sure.
> 
> Can you elaborate on what kind of RP would require you to be able to set your 
> display name to "Argent Stonecutter"?
> 

Sure. Anywhere you wanna have uniform appearance, like having a bunch of 'Agent 
Smith' AVs in black suits to give the 
impression of identical twins or clones.

And compare to reality, where you cannot totally prevent anyone to use your 
name either, unless its used as a corporate name.

It would have loved to ban others to use the firstname 'Michael', but that 
wasn't possible in RL, and so 7 of 28 of my classmates
in 1st school class were named Michael. Its just like that, names are not 
unique if your horizon in time and space gets large enough.

BUT there you have of course a point when you fear imposters and other people 
that try to make your name look bad due to their actions
under your 'name'. Same issue in RL, you can go to court over it, or file 
criminal charges, not nice.

The limitation is kind of arbitrary. Maybe if 'Display Names' got some hinting 
(e.g. by using a different font or some other UI hint),
to distinguish them from 'transplanted' usernames it would be good enough for 
the trivial imposter cases.

Michael






 

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Henri Beauchamp]

On Wed, 18 Aug 2010 11:41:38 -0400, Oz Linden (Scott Lawrence) wrote:

>   On 2010-08-18 6:38, Henri Beauchamp wrote:
> > - DO NOT SEGREGATE SUBMISSIONS: since you made Snowstorm LGPL, there
> >is now*no more need*  for the FLOSS exception and for contribution
> >agreements (since you can take a snapshot of the Open Source viewer
> >at anytime and incorporate them to your own closed source viewer,
> >and this without any LGPL contributor additional permission).
> 
> There is no longer any FLOSS exception; as you point out, it would be 
> redundant with the LGPL.
> 
> We still do require a Contribution Agreement, for good and valid reasons 
> I've explained many times - most notably that it allows us to improve 
> our license in the future.  Had we not required the CA in the past, we 
> would not have been able to change from GPL to LGPL.

Since the license is now LGPL, you do not need any more such an agreement,
even to change the license later. Every new submission to the code falls
under the LGPL License, which allows you to reuse the said code together
with more code under another License (including closed source code).
You'd need an agreement only after changing the license (for example if
you want to go back to a mixed GPL+FLOSS License) for people who would
submit patches *after* the License is changed from LGPL.

SL is the ONLY so-called (but actually still not, obviously: a Canada-Dry
LGPL, perhaps ?) LGPL Open Source project requiring a License agreement
from its contributors !!!  This makes strictly no sense and is a clear
impairement.

I'd also be curious to know any other of your "good and valid reasons"...

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Oz Linden (Scott Lawrence)]

 On 2010-08-18 14:14, Aidan Thornton wrote:

On 8/18/10, Oz Linden (Scott Lawrence)  wrote:

While there were some good things about the v1 implementation of pie
menus, they also had some flaws - such as not opening a submenu centered
on the mouse click.

I actually puzzled over this a bit when I first realised that Second
Life's pie menus worked this way. Originally, the pie menus worked
well when you didn't click too close to the edge of the screen but
didn't actually open under the mouse cursor if you did. Since the
"More..." item is sensibly always the southmost one, opening new
submenus centered on the mouse would cause the pie menu to drift down
the screen until it hit the bottom and caused problems.

Also, opening the submenu at the same location has the nice
side-effect that the mouse remains over the "More..." option for the
pie menus that are nested 3 or more levels deep.

What I have been contemplating is how to make it possible to open the
next layer of a pie menu without moving the mouse at all. Sadly, it'd
probably break too much from normal UI conventions to be worth doing.


If I understood him correctly, what Q seemed to think was the right 
behavior is:


   * The first mouse-down opens the pie centered on the mouse location,
 so no choice is under the mouse
   * If the choice is a submenu, each new menu is also centered on the
 mouse

that way, you are never making a choice within the submenu if you 
accidentally double click, because the center is never a choice.  this 
does mean that the nested menus 'creep', but that has the effect that 
each nested choice is a 'gesture-like' unique series of clicks.


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Zi Ree]

Am Mittwoch 18 August 2010 21:04:21 schrieb Oz Linden (Scott Lawrence):

> If I understood him correctly, what Q seemed to think was the right
> behavior is:
> 
> * The first mouse-down opens the pie centered on the mouse location,
>   so no choice is under the mouse
> * If the choice is a submenu, each new menu is also centered on the
>   mouse

In my opinion, the way it worked on 1.x was the best way to do it. You open 
the menu in one place on the screen of your choosing, and it stays there, not 
creeping over the screen and potentially blocking the view on something you 
wanted to watch while selecting an entry.

I wouldn't change that behavior. It worked well for years, nobody ever 
complained about it. And we should not fix something that's not broken. ;)

Zi
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Kadah]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 8/18/2010 12:04 PM, Oz Linden (Scott Lawrence) wrote:
> If I understood him correctly, what Q seemed to think was the right
> behavior is:
> 
> * The first mouse-down opens the pie centered on the mouse location,
>   so no choice is under the mouse
> * If the choice is a submenu, each new menu is also centered on the
>   mouse
> 
> that way, you are never making a choice within the submenu if you
> accidentally double click, because the center is never a choice.  this
> does mean that the nested menus 'creep', but that has the effect that
> each nested choice is a 'gesture-like' unique series of clicks.

I think he thinks that the proper behavior should have been that the
cursor recenters on the new sub pie menu.

I liked how for something like inspect was down, click, right, and
delete was down, up-right. As long as the item in the submenu in that
spot was either blank or nonharmfull, which it mostly was, I'd have
nearly no problems. Unlike with the context menus used now, I'm always
hunting for the option and frequently hit the wrong one.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMbDWkAAoJEIdLfPRu7qE2hRMH/RNLyOFVogQGaMfBnax20dbp
D+vQ2b6ANu48R4vCZtPDidvlWXde6cGBYpZrCrzzUKK+HeF4+KrW9IcDH+hnOPq7
YGUz2Q1CuYjuVWz9gVxioFe8zTQHKD92F+Mm3mkB+2PaFjxclejGf8nE54dft8Yc
6jEQTJ/bZB17KMIjMMWf+9fjPej6eF0zFjN0+6UpFXvMDiQHpllfY2KlJodd677P
NhDTVPIOZELC3pJ4ssMGfJUK3CdyYXyEhJiRTV99qs1gn3VKT/Tbc/QuLM4NdcFk
kchWh03rYVXG41rPEGJjjunayK6Qn2BpAwPbHbZTY7MWJ4P6Te1M1ZccwpfdvSo=
=C9qT
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Yoz Grahame]

On 18 August 2010 09:53, Oz Linden (Scott Lawrence) wrote:

>
> I think that if someone were to step up and do the work to create a
> better pie menu implementation that we could do good comparisons with
> (and especially if it allowed menu style to be a preference setting),
> then it would be a much more interesting discussion.
>

Existing JIRA here, for further discussion and patch submission:
http://jira.secondlife.com/browse/VWR-17388

If someone wants to argue for changing the sub-menu placement behaviour,
that should probably go in a sub-task. Might be interesting to prototype
both, though what those requesting this are primarily arguing for is
"exactly how it used to be".  There may be potential problems if new menu
items have been added for particular contexts, requiring rearrangement. I
have no idea how real this problem currently is, but it would need
investigation before we can assume that pie menus are easily added back.

-- Yoz
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Bryon Ruxton]

I am not sure if that's what you meant as "not opening a submenu centered
on the mouse click". or whether my suggestion would resolves it but I think
the pie menu repetition on sub level is prone to confusion indeed.

I would envision a pie menu on the first root level. And more normal
submenus on subsequent levels,
or something like this can be evaluated and perhaps improved:
http://usabilitynews.usernomics.com/2008/05/circular-menus-and-usability.htm
l

But I prefer the pie menu as well personally. It fits better in the context
of a 3d interaction. Flat pull down menus kind of break that immersive charm
of the pie menu to me.

On 8/18/10 9:53 AM, "Oz Linden (Scott Lawrence)"  wrote:

> I'm going to channel comments I've heard Q make here because he's not
> able to do it himself at the moment.
> 
> While there were some good things about the v1 implementation of pie
> menus, they also had some flaws - such as not opening a submenu centered
> on the mouse click.
> 
> I think that if someone were to step up and do the work to create a
> better pie menu implementation that we could do good comparisons with
> (and especially if it allowed menu style to be a preference setting),
> then it would be a much more interesting discussion.
> 
> Note: that in no way should be interpreted as "we would take it if it
> happened" - I can't make any such commitment on my own at this time.  If
> someone wants to sign up for the work, I'm willing to sponsor the
> discussion.


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Mike Monkowski]

Henri Beauchamp wrote:
> SL is the ONLY so-called (but actually still not, obviously: a Canada-Dry
> LGPL, perhaps ?) LGPL Open Source project requiring a License agreement
> from its contributors !!!  This makes strictly no sense and is a clear
> impairement.
> 
> I'd also be curious to know any other of your "good and valid reasons"...

I, obviously, am not in a position to speak for Linden Lab, but let me 
offer my opinion.  This project is somewhat different from most LGPL 
projects in that if there is no CA, it places Linden in the position of 
being sued for copyright infringement if someone contributes plagiarized 
code.  Most LGPL projects don't have a corporate owner with money worth 
suing for.

Mike
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Dickson, Mike (ISS Software)]

There are loads of open source projects that are LGPL (in whole or part) and 
that require a contributors agreement. Joomla, Alfresco, OpenChange, Evolution, 
etc.  It's a very common practice when a legal entity is the corporate sponsor 
for the project.  The only impairment here is the constant bickering over 
useless details.  Either you want to contribute or you don't.  If you do LL is 
the copyright holder and has every right to insist you sign a contributors 
agreement in order to make code contributions so that they can administer the 
project.

Mike

-Original Message-
From: opensource-dev-boun...@lists.secondlife.com 
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Mike Monkowski
Sent: Wednesday, August 18, 2010 4:52 PM
To: Henri Beauchamp
Cc: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] Open Viewer Development Announcement

Henri Beauchamp wrote:
> SL is the ONLY so-called (but actually still not, obviously: a Canada-Dry
> LGPL, perhaps ?) LGPL Open Source project requiring a License agreement
> from its contributors !!!  This makes strictly no sense and is a clear
> impairement.
> 
> I'd also be curious to know any other of your "good and valid reasons"...

I, obviously, am not in a position to speak for Linden Lab, but let me 
offer my opinion.  This project is somewhat different from most LGPL 
projects in that if there is no CA, it places Linden in the position of 
being sued for copyright infringement if someone contributes plagiarized 
code.  Most LGPL projects don't have a corporate owner with money worth 
suing for.

Mike
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Anders Arnholm]

2010-08-18 00:54, Brian McGroarty skrev:
> This is correct. Andromeda Quonset will be Andromeda Quonset forever.
> At some point, new residents won't be able to choose a last name -
> only these will be "Resident"
>
> No existing script function will return different results than it does
> today. New script functions are added for fetching/referencing Display
> Names.
>

It will, the existsing functuons will give a name that users of the new 
viewers have no possibility to see, unless they use a script. Thats 
something totally different that the username today is. The name will 
have changed it definition. As by that the think the functions return 
have changed. It's no longer a unique name you can use to tell users 
around you who a person is. It's a hell of a change in use case.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Anders Arnholm]

2010-08-18 01:42, Aimee Linden skrev:
> No, that's not the case, display names are not returned to the existing LSL 
> functions. Your existing account will always be seen as Andromeda Quonset to 
> existing scripts no matter what you change your display name to.
>
> New LSL calls used to return display names to new scripts equally will not be 
> a problem for older viewers either, what viewer you are running makes no 
> difference to a script which is running on the server.
>
> Aimee.
>
It will be, depenign on the use of the name returned.

If you used the old LSL functions, users of the old viewers will 
understand the output of the scripts. But new users only having 
DispalyName-UserName will not have the connections and see chat as the 
old usernames, Using that for llSay() would be very confusing for the user.

Script using the new interfaces will on the other hand be writing out 
DisplayNames, These displaynames will be impossible for users of the old 
viewers to connect to any person around. This makes the scripts not work 
for users of the old viewers.

As scripter you Can't write a product that uses the name of the people 
around and get any good result. Any of the three names you choose will 
not work for one of the user groups. You are borked.

Having unique names to be used for residents solved all the probems we 
have in like email systems with joe.a@example.com ... 
joe.z@example.com where no one knew who was a, b, z etc.

The change will not only make working products fail for users of the new 
viewer, it will make it impossible to make a product that works for all 
users in the sim.

/ Balp

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Anders Arnholm]

2010-08-18 15:11, Timothy Horrigan skrev:
Scripters have already had to deal with the case where an avi's name 
changes.  The Lindens have always had the option to rename avis (e.g., 
if an offensive name falls through the filters during registration, if 
an innoucuous name becomes offensive due to news events, if a Linden 
loses his or her job, etc.)  That's why most scripts specify the 
identity of a user through his or her UUID rather than his or her 
name.  In fact the only way to use the avi name in a script is to have 
it first look up the UUID.


With the new change the crips can't male a simple llSay() with the name 
the users around expect to see, one of the usergroups will see a name 
they have no idea what it is or is super ugly.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Anders Arnholm]

2010-08-18 20:19, Michael Schlenker skrev:
> Am 18.08.2010 um 15:05 schrieb Argent:
>
>
>> On Tue, Aug 17, 2010 at 6:47 PM, Michael Schlenker 
>>  wrote:
>> Am 18.08.2010 um 01:16 schrieb Bryon Ruxton:
>>  
>>> And 2. you should also prevent anyone to use a display name baring the name
>>> of an existing username in my opinion.
>>>
>>
>> NO. That would limit the usefulness for some kind of RP for sure.
>>
>> Can you elaborate on what kind of RP would require you to be able to set 
>> your display name to "Argent Stonecutter"?
>>
>>  
> Sure. Anywhere you wanna have uniform appearance, like having a bunch of 
> 'Agent Smith' AVs in black suits to give the
> impression of identical twins or clones.
>

On the other hand in RL yuou can usally hear fomr where the voice comes, 
in text chat you can't. FOr the people, not LL, handling the most of the 
abuse greifing an other stuff, and the most common problem in any 
roleplay group Drama, text logs where names aint unique will be a 
terrible mess to sort out. They wil case new drama's as well.  All sl 
roleplayers I know think this is about the worst they heard off EVER.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Brian McGroarty]

On Wed, Aug 18, 2010 at 11:27 AM, Henri Beauchamp  wrote:
>
> SL is the ONLY so-called (but actually still not, obviously: a Canada-Dry
> LGPL, perhaps ?) LGPL Open Source project requiring a License agreement
> from its contributors !!!  This makes strictly no sense and is a clear
> impairement.


Axiom, OpenOffice, NetBeans, Joomla!, Alfresco, ...


-- 
Brian McGroarty | Linden Lab
Sent from my Newton MP2100 via acoustic coupler
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Display Name & Viewer 1.x vs. Viewer 2.x

[aklo]

Display Name:

i don't want my name to *ever* appear in a login screen or anywhere else
as something like "aklo.modan"  If there's a reason to have that kind of
construct as a name used by scripts or whatever, that's fine so long as
it's kept "under the covers."  But no simple user should ever see it.

Same thing goes for "Resident".  It's an awful last (or any other) name to
*force* on people and shouldn't be something users have to *ever* look at
even though it may be necessary or reasonable or whatever for development,
administration & all that.  If someone picks it, that's their deal, but
there's other ways to solve development problems that don't have to be put
in the faces of people who aren't doing dev or admin kinds of things.

Appearances can be whatever and some people change them faster than they
go through toilet paper.  Display Names will make identity even less
certain, but why not?  i gotta say, though, if the name you see over an
avi's head doesn't mean anything to someone just looking at a screen, then
why not make any display of it at all an option?  What i mean is, just
have an option to turn off the entire ID bubble since it won't be very
meaningful anyway.

Basically, i think there's a really big diff between people liking the
idea of being able to pick their entire name (even if it's all small
letters or special characters or ...) and forcing them into a "Resident
clan" bucket, garbaging up their favorite name with a bunch of numbers so
it's unique, or making them look at some ugly string that's been computer
friendlied for them.

Viewer 1.x vs. Viewer 2.x:

i tried really hard to not only use, but to actually *like* Viewer 2.  i
failed.  i used it at least some every time i did SL for over 3 months and
got to where i could do almost everything i do with Viewer 1.23 
Somethings were easier, some were harder.  i wrote out a long list of
stuff that i'm not going to bother people with about what i did and didn't
like.  Most of it's been covered recently on this list, anyway.

Basically, the improvements in what it can do are great, but the UI is
*awful*.  The most disappointing thing to me is the impact on immersion. 
i'm not going to bother people with my weird ideas about the potential for
SL to expand reality for us, avatar compared to vihaya, and all the other
esoteric stuff that goes through my mind.  i think it's enough to say that
i want more out of my SL experience than a browser class "game."  i don't
play games.

The last straw for me was the second time a Viewer 2 auto-update disabled
the viewer so it wouldn't even start.  i gave up testing it after that. 
Please note that it was the *second* time.  The original Viewer 2
installation i did during the beta had already died over the same type of
problem and been replaced by a completely fresh installation of the
current Viewer 2 about 2 months ago.

Extra:

i like the UI to be sort of a "Terminator" style HUD.  That is, all
virtual world with all the controls & chat stuff in windows or widgets
that maybe stay on screen, but fade in and out from some variable degree
of transparency as requested or whatever.  And highly configurable, like
being able to be put anywhere on the screen, resized, recolored, and so
on.  Just sayin'.  i think i've been sorta asked for my opinion?

The draw distance setting is a real problem.  There are some sims (like
the one where i live) where tp with it set much over 150 will cause a
crash almost every time.  It would be super cool if there were an onscreen
widget like the movement & camera controls so it could be changed more
easily.  It makes sense several ways.  And, if tp with high draw distance
values is a problem for lots of people, then why not have it effectively
detuned to 0 or whatever by tp just before the actual tp is executed, and
then put back before tp completely exits?  Am i the only one who has the
problem?

i see that some avis with some viewers & HUDs have awesome prescience. 
Like, super radar & stuff like that.  Why can't all those tools be
available as UI options in the standard viewers?  i'm pitying the noob and
casual user here.  Or for that matter, just trying to even things out so
we all have a chance to have a good time in SL.  Except the griefers. 
They suck.

Like Lance says,

bye.

- AK


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Pie menu ideas (was: Re: Open Viewer Development Announcement)

[Celierra Darling]

Seems like this should be in a different thread

To get rid of creep, perhaps slide the pie instead of the mouse cursor while
moving the mouse.  As an example, if you move your mouse south to the
"More..." option, the actual cursor can remain in the same position on the
screen, but the pie can slide northward under the mouse cursor.

On the submenus-extending-out-from-the-wedge mockup that someone linked to
before [1], I think something like that is probably what users would expect.
 But I don't like the kludge that the article uses - it expands "View" at
the edge of the menu to avoid making the submenu's wedges annoyingly thin.
 That suddenly eats into a lot of the space for the neighboring wedges
(especially as SL's wedges expand infinitely out), so I can imagine a lot of
unintentional actions like, say, if you accidentally hover over "View" on
the way to "This Page" in the mockup.

There could be some zoom going on instead.  I am imagining the submenu's
wedges widening and filling a semicircle, with the backwards direction
indicating 'Back'.  The Dasher text input system does something like what I
mean, although Dasher's is linear (and it has way way too many options) [2].
 It might be a little weird to have buttons growing as you approach them;
Apple seems to like the visual effect (ex. the dock) but I can't think of
any other examples.

Celi

[1] http://techknack.net/circular-menus-and-usability/
[2] http://www.inference.phy.cam.ac.uk/dasher/, Java demo at
http://www.inference.phy.cam.ac.uk/dasher/TryJavaDasherNow.html

On Wed, Aug 18, 2010 at 3:04 PM, Oz Linden (Scott Lawrence) <
o...@lindenlab.com> wrote:

>  On 2010-08-18 14:14, Aidan Thornton wrote:
>
> On 8/18/10, Oz Linden (Scott Lawrence)  
>  wrote:
>
>  While there were some good things about the v1 implementation of pie
> menus, they also had some flaws - such as not opening a submenu centered
> on the mouse click.
>
>  I actually puzzled over this a bit when I first realised that Second
> Life's pie menus worked this way. Originally, the pie menus worked
> well when you didn't click too close to the edge of the screen but
> didn't actually open under the mouse cursor if you did. Since the
> "More..." item is sensibly always the southmost one, opening new
> submenus centered on the mouse would cause the pie menu to drift down
> the screen until it hit the bottom and caused problems.
>
> Also, opening the submenu at the same location has the nice
> side-effect that the mouse remains over the "More..." option for the
> pie menus that are nested 3 or more levels deep.
>
> What I have been contemplating is how to make it possible to open the
> next layer of a pie menu without moving the mouse at all. Sadly, it'd
> probably break too much from normal UI conventions to be worth doing.
>
>
> If I understood him correctly, what Q seemed to think was the right
> behavior is:
>
>- The first mouse-down opens the pie centered on the mouse location, so
>no choice is under the mouse
>- If the choice is a submenu, each new menu is also centered on the
>mouse
>
> that way, you are never making a choice within the submenu if you
> accidentally double click, because the center is never a choice.  this does
> mean that the nested menus 'creep', but that has the effect that each nested
> choice is a 'gesture-like' unique series of clicks.
>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] To Pie or To List

[Ricky]

(Figured this topic needed it's own thread)

I've had issues myself with the new list format menu... But they wind
up being different issues than I had with the old pie menu.

With the old pie menu I found myself accidentally deleting objects, or
otherwise having problems, when I moved my mouse rapidly: I'm
occasionally fumble-fingered with my mouse when I lift it for
repositioning, especially when I'm tired and working fast. With the
new menu, I've not had this issue.  +1.

With the new menu, I've almost reported abuse/returned/etc my own
items. -1.  It seems to me a little weird that those options show up
when clicking on something you are both the creator and owner of.
It's still a little weird even if not the creator, but still the
owner!  Since the only item in that sublist that makes any sense (to
me) in this context is the delete option, I believe it should be the
topmost, if not the only option.  Furthermore, if I don't have the
privileges to return an item the return option should be either
removed or grayed out.

The new menu has (almost) everything at the highest level, with less
often (or long) sets grouped into hover menus. +1.  The list format is
also a more common, and thusly an easier to (re)learn, UI element than
the pie, which took me months to get familiar with.  I was used to the
list in a day, so was the rest of my family. +1.

However, there were items in the old pie that were really useful, and
those weren't in the new list. -1.  Some of those were listed in the
mods on the wiki, and are being re-introduced. +1.

Ricky
Cron Stardust
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Open Inventory Transfer

[Ricky]

My mom is relatively new to SL.  (Meaning that she's had an account
for a while, been doing things for a while, but still sees through the
eyes of a new user.  Unlike myself...)

Well, she was recently instructed by my dad (an advanced user like
myself) to send him a notecard she was editing.  She asked how.  My
dad instructed her to "drag it to the IM window."  This she knew how
to find.  She then complained that it didn't work.  This brought me to
look at what she was doing.  She was trying to drag the notecard edit
window onto the chat popup to send him the notecard.

Because of this, I would like to put forth the suggestion for further
study of allowing the user to drag asset windows (notecards, textures,
etc.) onto the varied existing ways of sending content. (IMs, Profile
pages, etc)

The main counter I can think of for this is that sending inventory
accidentally would become more prevalent.  There are ways to solve
that, but shows that the above solution may not be optimal.
Suggestions?

Ricky
Cron Stardust
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Snowstorm Request: Draw Distance Slider (and other useful buttons)

[Hitomi Tiponi]

Trilobyte,
   I agree that those two, or many other features from StarLight (left-handed 
sidebar option, smaller camera controls, revised "Me" menu, "inventory" button 
etc.) may be useful additions to the Viewer - the Snowstorm team (well at least 
Esbee) are aware of it and may use what they want.  StarLight is a true example 
of community co-operation - for example, the 'About Land' button came from 
Alexandrea Fride and the draw distance slider was a modification by me of work 
by Avi Arrow.  None of them are particularly wonderful, but they do seem 
popular 
:).

Hitomi Tiponi



  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Pie menu ideas (was: Re: Open Viewer Development Announcement)

[Ricky]

Ah, was writing my post, didn't see that you had already posted a topic!

Ricky
Cron Stardust

On Wed, Aug 18, 2010 at 4:40 PM, Celierra Darling  wrote:
> Seems like this should be in a different thread
> To get rid of creep, perhaps slide the pie instead of the mouse cursor while
> moving the mouse.  As an example, if you move your mouse south to the
> "More..." option, the actual cursor can remain in the same position on the
> screen, but the pie can slide northward under the mouse cursor.
> On the submenus-extending-out-from-the-wedge mockup that someone linked to
> before [1], I think something like that is probably what users would expect.
>  But I don't like the kludge that the article uses - it expands "View" at
> the edge of the menu to avoid making the submenu's wedges annoyingly thin.
>  That suddenly eats into a lot of the space for the neighboring wedges
> (especially as SL's wedges expand infinitely out), so I can imagine a lot of
> unintentional actions like, say, if you accidentally hover over "View" on
> the way to "This Page" in the mockup.
> There could be some zoom going on instead.  I am imagining the submenu's
> wedges widening and filling a semicircle, with the backwards direction
> indicating 'Back'.  The Dasher text input system does something like what I
> mean, although Dasher's is linear (and it has way way too many options) [2].
>  It might be a little weird to have buttons growing as you approach them;
> Apple seems to like the visual effect (ex. the dock) but I can't think of
> any other examples.
> Celi
> [1] http://techknack.net/circular-menus-and-usability/
> [2] http://www.inference.phy.cam.ac.uk/dasher/, Java demo
> at http://www.inference.phy.cam.ac.uk/dasher/TryJavaDasherNow.html
> On Wed, Aug 18, 2010 at 3:04 PM, Oz Linden (Scott Lawrence)
>  wrote:
>>
>> On 2010-08-18 14:14, Aidan Thornton wrote:
>>
>> On 8/18/10, Oz Linden (Scott Lawrence)  wrote:
>>
>> While there were some good things about the v1 implementation of pie
>> menus, they also had some flaws - such as not opening a submenu centered
>> on the mouse click.
>>
>> I actually puzzled over this a bit when I first realised that Second
>> Life's pie menus worked this way. Originally, the pie menus worked
>> well when you didn't click too close to the edge of the screen but
>> didn't actually open under the mouse cursor if you did. Since the
>> "More..." item is sensibly always the southmost one, opening new
>> submenus centered on the mouse would cause the pie menu to drift down
>> the screen until it hit the bottom and caused problems.
>>
>> Also, opening the submenu at the same location has the nice
>> side-effect that the mouse remains over the "More..." option for the
>> pie menus that are nested 3 or more levels deep.
>>
>> What I have been contemplating is how to make it possible to open the
>> next layer of a pie menu without moving the mouse at all. Sadly, it'd
>> probably break too much from normal UI conventions to be worth doing.
>>
>> If I understood him correctly, what Q seemed to think was the right
>> behavior is:
>>
>> The first mouse-down opens the pie centered on the mouse location, so no
>> choice is under the mouse
>> If the choice is a submenu, each new menu is also centered on the mouse
>>
>> that way, you are never making a choice within the submenu if you
>> accidentally double click, because the center is never a choice.  this does
>> mean that the nested menus 'creep', but that has the effect that each nested
>> choice is a 'gesture-like' unique series of clicks.
>>
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Snowstorm Backlog Request: SNOW-766

[Aleric Inglewood]

Status: reviewed by Merov, committed to snowglobe 1.4, 1.5 and 2.1.

Background:

When developing many viewers in parallel (and snowstorm with it's many
clones that need to be checked out
won't change that), it becomes necessary to automate certain things with
scripts. One of the things those
scripts need to know is the current build directory.

However, the build directory is a function of the configuration of the
viewer. In order to remove human
maintenance (and possible errors therein) it is desirable to have an
automated way to convert configuration
to build directory name.

I wrote such scripts and they "break down" with the current
viewer-development:

hikaru:/usr/src/secondlife/viewers/snowstorm/test-20100818>source
env.source
Error: unknown subcommand 'printbuilddirs'
(run 'develop.py --help' for help)
CONFIGURE_OPTS = "--type=Release -m64 --standalone"
CMAKE_DEFS = "-DLL_TESTS:BOOL=ON -DPACKAGE:BOOL=ON
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON"
CMAKE_PREFIX_PATH = "/sl:/sl/usr"
CMAKE_INCLUDE_PATH =
"/usr/src/secondlife/llqtwebkit/install2/include:/usr/src/secondlife/viewers/snowstorm/test-20100818/include:/sl/usr/include"
CMAKE_LIBRARY_PATH = "/usr/src/secondlife/llqtwebkit/install2/lib:"

Sprint plan:

Port this patch to viewer-development for the next sprint and test it.

Before patch:

hikaru:/usr/src/secondlife/viewers/snowstorm/test-20100818/linden/indra>./develop.py
--type=Release -m64 --standalone printbuilddirs
setting DISTCC_DIR to
/usr/src/secondlife/viewers/snowstorm/test-20100818/linden/indra/.distcc
Error: unknown subcommand 'printbuilddirs'
(run 'develop.py --help' for help)

After patch:

This should print (on this box): viewer-linux-x86_64-release



Please let me know if anything is wrong or missing in this post,
Aleric
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Update Linux Build Documentation, please?

[Tapple Gao]

I'm on Gentoo Linux, and the build instructions for Linux [1] have
never worked for me (./develop.py cmake; ./develop.py build).
I've talked with some people on IRC, and I'm now under the
impression that develop.py is rather obsolete, which may be part
of my problem. However, that doesn't really help me, as I have
no idea how to use cmake.

Also, the build instructions have a lot of caveats for
standalone builders, which, as someone who has never even been
able to complete a non-standalone build, I am rather confused
by.

So, I'd like it if someone could update the linux build
documentation, and make it really easy for first-time
(non-standalone) builders to follow:

- Show how to use cmake rather than develop.py
- seperate out standalone and non-standalone into seperate
  documents

As an aside, the Imprudence viewer team has really overhauled
the build process, and as a result, Imprudence is the only
viewer that is actually able to find all my libraries and
complete a build from an svn checkout. I would strongly suggest
you integrate their build changes into the main viewer.

If there is really going to be more focus on open source, it is
really important to make sure new people like me are able to
compile the viewer from source.

[1] Linux build instructions:
http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux)

-- 
Matthew Fulmer (a.k.a. Tapple)
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Tateru Nino]

  You can also revoke the copyright assignment at (almost) any time.

On 19/08/2010 6:57 AM, Dickson, Mike (ISS Software) wrote:
> There are loads of open source projects that are LGPL (in whole or part) and 
> that require a contributors agreement. Joomla, Alfresco, OpenChange, 
> Evolution, etc.  It's a very common practice when a legal entity is the 
> corporate sponsor for the project.  The only impairment here is the constant 
> bickering over useless details.  Either you want to contribute or you don't.  
> If you do LL is the copyright holder and has every right to insist you sign a 
> contributors agreement in order to make code contributions so that they can 
> administer the project.
>
> Mike
>
> -Original Message-
> From: opensource-dev-boun...@lists.secondlife.com 
> [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Mike 
> Monkowski
> Sent: Wednesday, August 18, 2010 4:52 PM
> To: Henri Beauchamp
> Cc: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Open Viewer Development Announcement
>
> Henri Beauchamp wrote:
>> SL is the ONLY so-called (but actually still not, obviously: a Canada-Dry
>> LGPL, perhaps ?) LGPL Open Source project requiring a License agreement
>> from its contributors !!!  This makes strictly no sense and is a clear
>> impairement.
>>
>> I'd also be curious to know any other of your "good and valid reasons"...
> I, obviously, am not in a position to speak for Linden Lab, but let me
> offer my opinion.  This project is somewhat different from most LGPL
> projects in that if there is no CA, it places Linden in the position of
> being sued for copyright infringement if someone contributes plagiarized
> code.  Most LGPL projects don't have a corporate owner with money worth
> suing for.
>
> Mike
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Viewer Development Announcement

[Oz Linden (Scott Lawrence)]

  On 2010-08-18 22:42, Tateru Nino wrote:
>You can also revoke the copyright assignment at (almost) any time.
No, you can not.  There is no such provision in the Contribution Agreement.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Please - enough about the CA

[Oz Linden (Scott Lawrence)]

On Wed, Aug 18, 2010 at 11:27 AM, Henri Beauchamp  wrote:

SL is the ONLY so-called (but actually still not, obviously: a Canada-Dry
LGPL, perhaps ?) LGPL Open Source project requiring a License agreement
from its contributors !!!  This makes strictly no sense and is a clear
impairement.


Axiom, OpenOffice, NetBeans, Joomla!, Alfresco, ...




   and all projects under the Apache Foundation.

   http://www.apache.org/licenses/#clas

   and the Perl Foundation

   http://www.perlfoundation.org/contributor_license_agreement

   and the Python Foundation

   http://www.python.org/psf/contrib/contrib-form-python/


none of which are in any way commercial, and all of whom embody the 
ideals to which other open source projects aspire.


I know that some of you won't sign an agreement, and that you have 
reasons you think are good.  I accept that whether I agree with those 
reasons or not, while deeply regreting not being able to share in your 
work.


If any of you are unsure what the implications of the agreement are, I 
am happy to provide what assistance I can if you contact me _off_ of the 
list (but I am not a lawyer, and crucially I am not _your_ lawyer).


There may come a time when Linden Lab will revisit the requirement for 
or the terms of the CA.  If I'm still here, I'll let the community know 
when that is happening.


For the time being, changing the CA is not on the table - we've got 
other things to spend our time and energy on at the moment - like making 
Second Life Fast, Easy, and Fun.


If you feel the need to continue to rail against the CA, please take it 
somewhere else and leave this list to people who are trying to do the 
things that are possible now.



___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Correcting Height Displayed in Appearance Editor / Improved Default Camera Position

[Penny Patton]

  I'm proposing these two changes together because they are related to the
larger issue of building/visual design and scale in SL. Correcting either
will help a bit, correcting both will help content creators a lot. This is
my first contribution to the dev list, and as per the wiki I've tried to
keep the story for each issue nice and short.

 The Jira pages explain these problems, and how they affect content
creation, in much more detail.

 Correcting Height Displayed in Appearance Editor
 - https://jira.secondlife.com/browse/VWR-19767

 AgentHeight does not actually match the size of the avatar mesh so the
avatar height that is displayed in the appearance editor is incorrect. This
creates confusion and provides false information on which people base avatar
design decisions.

 This leads to larger avatars which present problems to both environment
designers and animators. Environment designers are forced to build larger to
compensate. The disparity between "average" avatar sizes that this
contributes to creates issues animators cannot work around. The confusion it
creates regarding avatar size causes animators to present incorrect
information to customers with regards to purchasing animations designed for
specific avatar sizes.

=


Improving Default Camera Placement
 - https://jira.secondlife.com/browse/VWR-19238

 The current default camera placement requires users to zoom out
significantly to get a good view of their avatar and surroundings, the
camera moves up as well as back creating conflicts between the camera and
the environment unless the environment is substantially up-scaled to
compensate

  Improving the camera placement used by the average resident would allow
builders to create larger, more detailed environments by building at a
reduced scale.

- Penny Patton
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges