[opensource-dev] Rainbow texture problem.

[lists . secondlife . com]

Hi all.

I've been trying to fix a rainbow texture corruption bug the past few days 
with little success. Using UDP, its ok. Using http texture fetch, it get 
corrupted.

I've managed to figure what is causing the texture to get corrupted after 
downloading and displaying it. What happens is that on textures that have the 
same file size for discard level 1 and 0, the data size sent to the decoder is 
incorrect. See http://pastebin.com/Kc9x5BNS for the detailed debug output for 
that texture.

I've managed to trace back to the function that is returning the incorrect 
data recieved in lltextruefetch.cpp, "mFormattedImage->getDataSize()". That 
function is used to calculate the amount of data to memcopy and to send to the 
decoder.

"mFormattedImage->getDataSize()" goes back to llimage.cpp and from there who 
knows, i've can't trace it back anymore.

Somewhere between libcurl returning data and lltextruefetch, the amount of 
data recieved is getting corrupted somewhere. If someone knows of this bug or 
can point me in the right direction of how the size data from libcurl gets to 
lltexturefetch.cpp I would be grateful.

--Techwolf Lupindo
___
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] VWR-20094 - Maybe still a hope for scripters with viewer 2?

[Satomi Ahn]

Hello all,

I just wanted to mention that I found how to fix the bug that was
keeping all scripters from switching to viewer 2 (the one that made
the viewer freeze on loading large scripts).

All details are here: https://jira.secondlife.com/browse/VWR-20094,
along with a patch showing one possible way to fix it (once the bug is
understood, the fix is trivial, so my patch is only here to
illustrate, as I doubt it really complies with LL coding style).

I know it is too late for 2.2 now, but, speaking for all SL scripters,
I would be very grateful if you fixed the trunk ASAP (and also fixes
the most outstanding issues of the script editor, such as ctrl+F not
showing the script search floater). That is why I am poking this
mailing list for the first time.

Regards

-- 
Satomi
___
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] New memory leak in LLUIString ?

[Boroondas Gupte]

 Looking through recently merged commits, I noticed that changeset
80af8db446df changes

LLUIString::mArgs into a pointer. This pointer gets initialized with a
new object in one of the constructors

(the other constructors set it to NULL), or lazily (i.e. when still NULL
when an actual object is required) through LLUIString::getArgs()
.

Though I can't seem to find where mArgs gets deleted again. Is it being
leaked?

As far as I can see, mArgs (which is private) doesn't get assigned any
pointers from outside the LLUIString instance and is never passed out
through any method, so it should be save to delete it in the destructor
of LLUIString.

Am I missing something obvious?
Cheers,

Boroondas
___
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] VWR-20094 - Maybe still a hope for scripters with viewer 2?

[Dave Booth]

  On 9/24/2010 04:57, Satomi Ahn wrote:
> Hello all,
>
> I just wanted to mention that I found how to fix the bug that was
> keeping all scripters from switching to viewer 2 (the one that made
> the viewer freeze on loading large scripts).
Oh trust me, its a good one to fix but it sure isnt "the" bug :) 
Personally, the one that gets furthest up my nose is the cursor drift - 
I typically have my UI sized way down and the incorrect cursor tracking 
makes editing anything text-based, script or notecard, a royal pain in 
the fundament. It doubly annoys me because one of my RL hobbies - 
letterpress printing. Sometimes I'd swear I could get the same text into 
my composing stick more efficiently than into a notecard and theres 
really no excuse for that. I appreciate that font handling and cursor 
tracking has almost as many quirks as 3d rendering but still.
___
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] VWR-20094 - Maybe still a hope for scr ipters with viewer 2?

[Opensource Obscure]

On Fri, 24 Sep 2010 08:38:38 -0500, Dave Booth 
wrote:
> On 9/24/2010 04:57, Satomi Ahn wrote:
>> Hello all,
>>
>> I just wanted to mention that I found how to fix the bug that was
>> keeping all scripters from switching to viewer 2 (the one that made
>> the viewer freeze on loading large scripts).
> Oh trust me, its a good one to fix but it sure isnt "the" bug :) 
> Personally, the one that gets furthest up my nose is the cursor drift

what is the PJIRA entry for that? 
does it affect all viewer releases?

opensource obscure
___
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] VWR-20094 - Maybe still a hope for scripters with viewer 2?

[Dave Booth]

  On 9/24/2010 08:49, Opensource Obscure wrote:
> On Fri, 24 Sep 2010 08:38:38 -0500, Dave Booth
> wrote:
>> On 9/24/2010 04:57, Satomi Ahn wrote:
>>> Hello all,
>>>
>>> I just wanted to mention that I found how to fix the bug that was
>>> keeping all scripters from switching to viewer 2 (the one that made
>>> the viewer freeze on loading large scripts).
>> Oh trust me, its a good one to fix but it sure isnt "the" bug :)
>> Personally, the one that gets furthest up my nose is the cursor drift
> what is the PJIRA entry for that?
> does it affect all viewer releases?
>
> opensource obscure
>
Theres plenty of them - most refer to notecards, because the problem 
shows up easier in paragraph-based stuff like notecards. The more text 
you have in a "line" (which a nc will wrap as a paragraph) the worse it 
gets. An explicit \n resets it but in a long code line it happens too, 
particularly when you have a UI scaling to anything other than 1.0 (some 
folks report it when scale>1.0, some when scale<1.0) You can click 
somewhere in a line of code and start typing to insert characters and 
then see them inserting several places to the left of where the click 
and the blinking cursor indicate they should, or see the cursor getting 
further and further ahead of the characters you're typing, if you're 
typing a new line.

https://jira.secondlife.com/browse/VWR-20178 and its dupes are the 
clearest description of it for notecards,
https://jira.secondlife.com/browse/VWR-18875 and 
https://jira.secondlife.com/browse/VWR-21388 point it out in the script 
editor

As for versions, I screamed and fled from the 2.0.x viewers... only came 
back to the 2.1 beta so I can tell you its definitely in 2.1 beta and later

 From a printers perspective, it looks to me very much like the kerning 
and tracking data in the fonts used are a little off. This would have 
least effect with UI scale = 1, but as soon as you apply a scaling 
factor other than unity then it show much more rapidly - my digital 
typography knowledge is a little rusty but I believe that particularly a 
tracking error would grow as a square function with line length when 
scaled that way. If the data in the font itself is good, then its in the 
editor code.
___
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] Congratulations on 2-2-0-beta

[Ponzu]

Pat yourselves on the back 8-)

By the way, will there be a 2-1-0-beta tag on the viewer-beta and
viewer-development bitbucket repositories?
___
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] off the wall idea of the day

[Joshua Bell]

On Thu, Sep 23, 2010 at 6:41 PM, Ponzu  wrote:

> "Logging in" is so *boring*.  You log in to the mainframe, or your prison
> cell.  When a user connects to Second Life, we need a better metaphor and a
> more "fun" experience.
>
> I am thinking of something like ENTER THE METAVERSE  or UPLOAD YOURSELF
> NOW.  Then, instead of the boring progress bar, how about swirling lights or
> a visual whirl pool or something, like a music visualization plug in from
> iTunes.
>

I seem to recall an internal idea discussed circa 2006 (so I think the
statute of limitations has expired...) that presented progress starting with
a tunnel of swirly lights which resolved into a view of the world map zoomed
all the way out. As login progressed, the map would zoom in to your
destination until it finally just tipped to match your initial view.

Cool as that would be, I'd rather dedicate engineering time to reducing
login time as much as possible first.

Has anyone recently profiled what the viewer is doing during launch (app
start to login screen display) and login (while the progress bar is showing)
to make sure that regressions haven't been introduced, and see what could be
optimized?

Joshua
___
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] Third Party Plug-ins?

[miss c]

Would it be a plausible feature in the future to have the code accept third 
party plug-ins instead of creating whole new viewers?  Then have a Third party 
directory approved plug-in list.  As I mentioned before, my husband is making 
an 
external installer for people that may have difficulty installing skins into 
the 
new viewer, this will be a directory that all skin designers can add their 
skins 
to.  Wouldn't it be better to have a RLV plug in or an AO plug in, or a radar 
plugin that displays distance, then have to add all that to each viewer?  I do 
realize that there may be some things that Linden Lab might not want to add to 
their code but if its switched to a plug in system, people can pick and choose 
which additional features they prefer without having whats considered competing 
iewers.

TY

Miss



  ___
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] Third Party Plug-ins?

[Daniel Smith]

On Fri, Sep 24, 2010 at 10:57 AM, miss c  wrote:

> Would it be a plausible feature in the future to have the code accept third
> party plug-ins instead of creating whole new viewers?
>

+1

How workable is the 2.x codebase to some sort of modularity, to allow
plugins, a la chrome/safari/firefox?

The problem with the SL viewer being a huge monolithic client is that it
becomes something that does more, on fewer machines, due to memory footprint
and increasing resource consumption.

If the current codebase isnt workable towards allowing plugins, it may be
time to put on the brakes and consider the course.



-- 
Daniel Smith - Sonoma County, California
http://daniel.org/resume
___
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] major problem with beta 2.2

[Erin Mallory]

As a User I expect and NEED usernames to be displayed in group chat and used 
properly in group and conference chat logs.
Instead I am seeing in both chat and in logs, usernames replaced with the group 
or conference name!!!

  ___
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] major problem with beta 2.2

[Kent Quirk (Q Linden)]

Yup, that's a genuine bug:

https://jira.secondlife.com/browse/VWR-23168

We'll try to get it fixed for Beta 2.
   Q


On Sep 24, 2010, at 2:36 PM, Erin Mallory wrote:

> As a User I expect and NEED usernames to be displayed in group chat and used 
> properly in group and conference chat logs.
> Instead I am seeing in both chat and in logs, usernames replaced with the 
> group or conference name!!!
> 
> ___
> 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] Third Party Plug-ins?

[malachi]

i for one particularly love this idea. i think there should be a way for  
the default LL issued viewer to be a plain jane for every user client. but  
allow third party devs to create plugins that do whatever they want. the  
idea of the radar and ao are amazing. but dont stop there. there are tons  
of things that average users DO NOT use in the client already. LL could  
simply remove those items and offer them as plugins. i am for this idea of  
modularity 100%. my only question is where do we start?

On Fri, 24 Sep 2010 13:57:16 -0400, miss c  wrote:

> Would it be a plausible feature in the future to have the code accept  
> third
> party plug-ins instead of creating whole new viewers?  Then have a Third  
> party
> directory approved plug-in list.  As I mentioned before, my husband is  
> making an
> external installer for people that may have difficulty installing skins  
> into the
> new viewer, this will be a directory that all skin designers can add  
> their skins
> to.  Wouldn't it be better to have a RLV plug in or an AO plug in, or a  
> radar
> plugin that displays distance, then have to add all that to each  
> viewer?  I do
> realize that there may be some things that Linden Lab might not want to  
> add to
> their code but if its switched to a plug in system, people can pick and  
> choose
> which additional features they prefer without having whats considered  
> competing
> iewers.
>
> TY
>
> Miss
>
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
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] major problem with beta 2.2

[Kent Quirk (Q Linden)]

On Sep 24, 2010, at 2:36 PM, Erin Mallory wrote:

> As a User I expect and NEED usernames to be displayed in group chat and used 
> properly in group and conference chat logs.
> Instead I am seeing in both chat and in logs, usernames replaced with the 
> group or conference name!!!
> 


I see this in the development tip (210412) but NOT in the beta (210127). Is 
anyone seeing it in the beta?

___
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] merchant/customer transaction userstory

[Erin Mallory]

As a user/Merchant I expect SL to properly and reliably handle marketplace 
transactions, and to give the customer matching transaction numbers for the 
merchant and customer as per universal standards. (see 
https://jira.secondlife.com/browse/web-2920 and 
https://jira.secondlife.com/browse/WEB-2628)  

I realize this is mostly more a web problem, but this affects in world too. 
 and is one more nightmare for merchants and creators in a growing list. 
  ___
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] Third Party Plug-ins?

[Brandon Husbands]

I have already started work on a plugin system with embeded mono. Which you
expose methods to the api.. This allows anyone to use any CLI language to
create plugins.

I can post more info on this later. A tad bit busy at the moment.

On Fri, Sep 24, 2010 at 4:20 PM, malachi  wrote:

> i for one particularly love this idea. i think there should be a way for
> the default LL issued viewer to be a plain jane for every user client. but
> allow third party devs to create plugins that do whatever they want. the
> idea of the radar and ao are amazing. but dont stop there. there are tons
> of things that average users DO NOT use in the client already. LL could
> simply remove those items and offer them as plugins. i am for this idea of
> modularity 100%. my only question is where do we start?
>
> On Fri, 24 Sep 2010 13:57:16 -0400, miss c  wrote:
>
> > Would it be a plausible feature in the future to have the code accept
> > third
> > party plug-ins instead of creating whole new viewers?  Then have a Third
> > party
> > directory approved plug-in list.  As I mentioned before, my husband is
> > making an
> > external installer for people that may have difficulty installing skins
> > into the
> > new viewer, this will be a directory that all skin designers can add
> > their skins
> > to.  Wouldn't it be better to have a RLV plug in or an AO plug in, or a
> > radar
> > plugin that displays distance, then have to add all that to each
> > viewer?  I do
> > realize that there may be some things that Linden Lab might not want to
> > add to
> > their code but if its switched to a plug in system, people can pick and
> > choose
> > which additional features they prefer without having whats considered
> > competing
> > iewers.
> >
> > TY
> >
> > Miss
> >
> >
> >
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> ___
> 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
>



-- 
---
This email is a private and confidential communication. Any use of email may
be subject to the laws and regulations of the United States. You may not
Repost, Distribute nor reproduce any content of this message.
---
---
___
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] VWR-20094 - Maybe still a hope for scripters with viewer 2?

[Ricky]

This bug, and it's relations, are recurring characters. (No pun
intended!) A few years ago I ran across this in one of the 1.x viewer
editions, and it was rapidly fixed.  But it doesn't look like a
regression test got built.  Either that or the test didn't make it
into 2.x.

Some of the relations of this bug are in other areas.  To me it seems
that QA seems to miss testing the viewer with a UI scale setting other
than 1.0.  I figure that this will be one of the big advantages of the
Snowstorm process: More testers with different setups and
configurations.  Personally I prefer a UI size of 0.875, but since I
upgraded to a higher rez screen it's not been so much of an issue.
2.x also seems to have a smaller default font size than 1.x, but that
may be an artifact of my screen upgrade!

Ricky
Cron Stardust

On Fri, Sep 24, 2010 at 7:27 AM, Dave Booth  wrote:
>  On 9/24/2010 08:49, Opensource Obscure wrote:
>> On Fri, 24 Sep 2010 08:38:38 -0500, Dave Booth
>> wrote:
>>> On 9/24/2010 04:57, Satomi Ahn wrote:
 Hello all,

 I just wanted to mention that I found how to fix the bug that was
 keeping all scripters from switching to viewer 2 (the one that made
 the viewer freeze on loading large scripts).
>>> Oh trust me, its a good one to fix but it sure isnt "the" bug :)
>>> Personally, the one that gets furthest up my nose is the cursor drift
>> what is the PJIRA entry for that?
>> does it affect all viewer releases?
>>
>> opensource obscure
>>
> Theres plenty of them - most refer to notecards, because the problem
> shows up easier in paragraph-based stuff like notecards. The more text
> you have in a "line" (which a nc will wrap as a paragraph) the worse it
> gets. An explicit \n resets it but in a long code line it happens too,
> particularly when you have a UI scaling to anything other than 1.0 (some
> folks report it when scale>1.0, some when scale<1.0) You can click
> somewhere in a line of code and start typing to insert characters and
> then see them inserting several places to the left of where the click
> and the blinking cursor indicate they should, or see the cursor getting
> further and further ahead of the characters you're typing, if you're
> typing a new line.
>
> https://jira.secondlife.com/browse/VWR-20178 and its dupes are the
> clearest description of it for notecards,
> https://jira.secondlife.com/browse/VWR-18875 and
> https://jira.secondlife.com/browse/VWR-21388 point it out in the script
> editor
>
> As for versions, I screamed and fled from the 2.0.x viewers... only came
> back to the 2.1 beta so I can tell you its definitely in 2.1 beta and later
>
>  From a printers perspective, it looks to me very much like the kerning
> and tracking data in the fonts used are a little off. This would have
> least effect with UI scale = 1, but as soon as you apply a scaling
> factor other than unity then it show much more rapidly - my digital
> typography knowledge is a little rusty but I believe that particularly a
> tracking error would grow as a square function with line length when
> scaled that way. If the data in the font itself is good, then its in the
> editor code.
> ___
> 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] Third Party Plug-ins?

[Ricky]

Please read these threads for the discussions we had on the types and
limits of various plugin schemes:
* "Client-side scripting in Snowglobe" -
https://lists.secondlife.com/pipermail/opensource-dev/2010-February/88.html
* "Consensus? was: Client-side scripting in Snowglobe" -
https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000167.html
* "Client Plugin System Design" -
https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000624.html

There are many useful ideas and documented pitfalls to avoid.  With
due consideration of these conversations many of the expected
issues/fears can be "headed off at the pass" you might say.

Ricky
Cron Stardust

On Fri, Sep 24, 2010 at 3:14 PM, Brandon Husbands  wrote:
> I have already started work on a plugin system with embeded mono. Which you
> expose methods to the api.. This allows anyone to use any CLI language to
> create plugins.
>
> I can post more info on this later. A tad bit busy at the moment.
>
> On Fri, Sep 24, 2010 at 4:20 PM, malachi  wrote:
>>
>> i for one particularly love this idea. i think there should be a way for
>> the default LL issued viewer to be a plain jane for every user client. but
>> allow third party devs to create plugins that do whatever they want. the
>> idea of the radar and ao are amazing. but dont stop there. there are tons
>> of things that average users DO NOT use in the client already. LL could
>> simply remove those items and offer them as plugins. i am for this idea of
>> modularity 100%. my only question is where do we start?
>>
>> On Fri, 24 Sep 2010 13:57:16 -0400, miss c  wrote:
>>
>> > Would it be a plausible feature in the future to have the code accept
>> > third
>> > party plug-ins instead of creating whole new viewers?  Then have a Third
>> > party
>> > directory approved plug-in list.  As I mentioned before, my husband is
>> > making an
>> > external installer for people that may have difficulty installing skins
>> > into the
>> > new viewer, this will be a directory that all skin designers can add
>> > their skins
>> > to.  Wouldn't it be better to have a RLV plug in or an AO plug in, or a
>> > radar
>> > plugin that displays distance, then have to add all that to each
>> > viewer?  I do
>> > realize that there may be some things that Linden Lab might not want to
>> > add to
>> > their code but if its switched to a plug in system, people can pick and
>> > choose
>> > which additional features they prefer without having whats considered
>> > competing
>> > iewers.
>> >
>> > TY
>> >
>> > Miss
>> >
>> >
>> >
>>
>>
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>> ___
>> 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
>
>
>
> --
> ---
> This email is a private and confidential communication. Any use of email may
> be subject to the laws and regulations of the United States. You may not
> Repost, Distribute nor reproduce any content of this message.
> ---
> ---
>
> ___
> 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] Third Party Plug-ins?

[Ricky]

Missed one:
"Client-side scripting REST/HTTP doc sample" -
https://lists.secondlife.com/pipermail/opensource-dev/2010-March/001050.html

This was the basis for https://jira.secondlife.com/browse/SNOW-375

Ricky
Cron Stardust

On Fri, Sep 24, 2010 at 3:54 PM, Ricky  wrote:
> Please read these threads for the discussions we had on the types and
> limits of various plugin schemes:
> * "Client-side scripting in Snowglobe" -
> https://lists.secondlife.com/pipermail/opensource-dev/2010-February/88.html
> * "Consensus? was: Client-side scripting in Snowglobe" -
> https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000167.html
> * "Client Plugin System Design" -
> https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000624.html
>
> There are many useful ideas and documented pitfalls to avoid.  With
> due consideration of these conversations many of the expected
> issues/fears can be "headed off at the pass" you might say.
>
> Ricky
> Cron Stardust
>
> On Fri, Sep 24, 2010 at 3:14 PM, Brandon Husbands  wrote:
>> I have already started work on a plugin system with embeded mono. Which you
>> expose methods to the api.. This allows anyone to use any CLI language to
>> create plugins.
>>
>> I can post more info on this later. A tad bit busy at the moment.
>>
>> On Fri, Sep 24, 2010 at 4:20 PM, malachi  wrote:
>>>
>>> i for one particularly love this idea. i think there should be a way for
>>> the default LL issued viewer to be a plain jane for every user client. but
>>> allow third party devs to create plugins that do whatever they want. the
>>> idea of the radar and ao are amazing. but dont stop there. there are tons
>>> of things that average users DO NOT use in the client already. LL could
>>> simply remove those items and offer them as plugins. i am for this idea of
>>> modularity 100%. my only question is where do we start?
>>>
>>> On Fri, 24 Sep 2010 13:57:16 -0400, miss c  wrote:
>>>
>>> > Would it be a plausible feature in the future to have the code accept
>>> > third
>>> > party plug-ins instead of creating whole new viewers?  Then have a Third
>>> > party
>>> > directory approved plug-in list.  As I mentioned before, my husband is
>>> > making an
>>> > external installer for people that may have difficulty installing skins
>>> > into the
>>> > new viewer, this will be a directory that all skin designers can add
>>> > their skins
>>> > to.  Wouldn't it be better to have a RLV plug in or an AO plug in, or a
>>> > radar
>>> > plugin that displays distance, then have to add all that to each
>>> > viewer?  I do
>>> > realize that there may be some things that Linden Lab might not want to
>>> > add to
>>> > their code but if its switched to a plug in system, people can pick and
>>> > choose
>>> > which additional features they prefer without having whats considered
>>> > competing
>>> > iewers.
>>> >
>>> > TY
>>> >
>>> > Miss
>>> >
>>> >
>>> >
>>>
>>>
>>> --
>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>>> ___
>>> 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
>>
>>
>>
>> --
>> ---
>> This email is a private and confidential communication. Any use of email may
>> be subject to the laws and regulations of the United States. You may not
>> Repost, Distribute nor reproduce any content of this message.
>> ---
>> ---
>>
>> ___
>> 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] Congratulations on 2-2-0-beta

[Trilo Byte]

Hard to feel congratulatory when the beta was pushed out with a known major 
regression (anti-aliasing has been broken since build 208569).

On Sep 24, 2010, at 8:08 AM, Ponzu wrote:

> Pat yourselves on the back 8-)
>  
> By the way, will there be a 2-1-0-beta tag on the viewer-beta and 
> viewer-development bitbucket repositories?
> ___
> 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] major problem with beta 2.2 - link

[miss c]

Here is a screen shot of the bug

http://www.flickr.com/photos/toxiancity/5021728112/#/photos/toxiancity/5021728112/lightbox/





From: Kent Quirk (Q Linden) 
To: Erin Mallory 
Cc: opensource-dev@lists.secondlife.com
Sent: Fri, September 24, 2010 4:39:37 PM
Subject: Re: [opensource-dev] major problem with beta 2.2



On Sep 24, 2010, at 2:36 PM, Erin Mallory wrote:

As a User I expect and NEED usernames to be displayed in group chat and used 
properly in group and conference chat logs.
>Instead I am seeing in both chat and in logs, usernames replaced with the 
>group 
>or conference name!!!
>
>


I see this in the development tip (210412) but NOT in the beta (210127). Is 
anyone seeing it in the beta?



  ___
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] major problem with beta 2.2 - link

[Trilo Byte]

I've seen the problem as well (and voted on the issue), but did not see it in 
the 2.2.0 beta (build 210127).  This only broke in a more recent build (one of 
the ones from yesterday, I believe).

On Sep 24, 2010, at 4:11 PM, miss c wrote:

> 
> Here is a screen shot of the bug
> 
> http://www.flickr.com/photos/toxiancity/5021728112/#/photos/toxiancity/5021728112/lightbox/
> 
> From: Kent Quirk (Q Linden) 
> To: Erin Mallory 
> Cc: opensource-dev@lists.secondlife.com
> Sent: Fri, September 24, 2010 4:39:37 PM
> Subject: Re: [opensource-dev] major problem with beta 2.2
> 
> 
> On Sep 24, 2010, at 2:36 PM, Erin Mallory wrote:
> 
>> As a User I expect and NEED usernames to be displayed in group chat and used 
>> properly in group and conference chat logs.
>> Instead I am seeing in both chat and in logs, usernames replaced with the 
>> group or conference name!!!
>> 
> 
> 
> I see this in the development tip (210412) but NOT in the beta (210127). Is 
> anyone seeing it in the beta?
> 
> 
> ___
> 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] Third Party Plug-ins?

[Brandon Husbands]

Any discussion is ok about any feature thats wanted. Just cause there were
previous discussions does not mean you are to attempt to close this thread.
Do not hinder development by attempting to moderate a thread ricky.

On Fri, Sep 24, 2010 at 5:56 PM, Ricky  wrote:

> Missed one:
> "Client-side scripting REST/HTTP doc sample" -
>
> https://lists.secondlife.com/pipermail/opensource-dev/2010-March/001050.html
>
> This was the basis for https://jira.secondlife.com/browse/SNOW-375
>
> Ricky
> Cron Stardust
>
> On Fri, Sep 24, 2010 at 3:54 PM, Ricky  wrote:
> > Please read these threads for the discussions we had on the types and
> > limits of various plugin schemes:
> > * "Client-side scripting in Snowglobe" -
> >
> https://lists.secondlife.com/pipermail/opensource-dev/2010-February/88.html
> > * "Consensus? was: Client-side scripting in Snowglobe" -
> >
> https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000167.html
> > * "Client Plugin System Design" -
> >
> https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000624.html
> >
> > There are many useful ideas and documented pitfalls to avoid.  With
> > due consideration of these conversations many of the expected
> > issues/fears can be "headed off at the pass" you might say.
> >
> > Ricky
> > Cron Stardust
> >
> > On Fri, Sep 24, 2010 at 3:14 PM, Brandon Husbands 
> wrote:
> >> I have already started work on a plugin system with embeded mono. Which
> you
> >> expose methods to the api.. This allows anyone to use any CLI language
> to
> >> create plugins.
> >>
> >> I can post more info on this later. A tad bit busy at the moment.
> >>
> >> On Fri, Sep 24, 2010 at 4:20 PM, malachi  wrote:
> >>>
> >>> i for one particularly love this idea. i think there should be a way
> for
> >>> the default LL issued viewer to be a plain jane for every user client.
> but
> >>> allow third party devs to create plugins that do whatever they want.
> the
> >>> idea of the radar and ao are amazing. but dont stop there. there are
> tons
> >>> of things that average users DO NOT use in the client already. LL could
> >>> simply remove those items and offer them as plugins. i am for this idea
> of
> >>> modularity 100%. my only question is where do we start?
> >>>
> >>> On Fri, 24 Sep 2010 13:57:16 -0400, miss c 
> wrote:
> >>>
> >>> > Would it be a plausible feature in the future to have the code accept
> >>> > third
> >>> > party plug-ins instead of creating whole new viewers?  Then have a
> Third
> >>> > party
> >>> > directory approved plug-in list.  As I mentioned before, my husband
> is
> >>> > making an
> >>> > external installer for people that may have difficulty installing
> skins
> >>> > into the
> >>> > new viewer, this will be a directory that all skin designers can add
> >>> > their skins
> >>> > to.  Wouldn't it be better to have a RLV plug in or an AO plug in, or
> a
> >>> > radar
> >>> > plugin that displays distance, then have to add all that to each
> >>> > viewer?  I do
> >>> > realize that there may be some things that Linden Lab might not want
> to
> >>> > add to
> >>> > their code but if its switched to a plug in system, people can pick
> and
> >>> > choose
> >>> > which additional features they prefer without having whats considered
> >>> > competing
> >>> > iewers.
> >>> >
> >>> > TY
> >>> >
> >>> > Miss
> >>> >
> >>> >
> >>> >
> >>>
> >>>
> >>> --
> >>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> >>> ___
> >>> 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
> >>
> >>
> >>
> >> --
> >>
> ---
> >> This email is a private and confidential communication. Any use of email
> may
> >> be subject to the laws and regulations of the United States. You may not
> >> Repost, Distribute nor reproduce any content of this message.
> >>
> ---
> >>
> ---
> >>
> >> ___
> >> 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
> >>
> >
>



-- 
---
This email is a private and confidential communication. Any use of email may
be subject to the laws and regulations of the United States. You may not
Repost, Distribute nor reproduce any content of this message.

Re: [opensource-dev] Third Party Plug-ins?

[Brandon Husbands]

Yikes... I misread your post. LOL There are plenty on this list that try to
close threads with links to past discussions. LOL my bad.. Ty for the links.

On Fri, Sep 24, 2010 at 5:54 PM, Ricky  wrote:

> Please read these threads for the discussions we had on the types and
> limits of various plugin schemes:
> * "Client-side scripting in Snowglobe" -
>
> https://lists.secondlife.com/pipermail/opensource-dev/2010-February/88.html
> * "Consensus? was: Client-side scripting in Snowglobe" -
>
> https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000167.html
> * "Client Plugin System Design" -
>
> https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000624.html
>
> There are many useful ideas and documented pitfalls to avoid.  With
> due consideration of these conversations many of the expected
> issues/fears can be "headed off at the pass" you might say.
>
> Ricky
> Cron Stardust
>
> On Fri, Sep 24, 2010 at 3:14 PM, Brandon Husbands 
> wrote:
> > I have already started work on a plugin system with embeded mono. Which
> you
> > expose methods to the api.. This allows anyone to use any CLI language to
> > create plugins.
> >
> > I can post more info on this later. A tad bit busy at the moment.
> >
> > On Fri, Sep 24, 2010 at 4:20 PM, malachi  wrote:
> >>
> >> i for one particularly love this idea. i think there should be a way for
> >> the default LL issued viewer to be a plain jane for every user client.
> but
> >> allow third party devs to create plugins that do whatever they want. the
> >> idea of the radar and ao are amazing. but dont stop there. there are
> tons
> >> of things that average users DO NOT use in the client already. LL could
> >> simply remove those items and offer them as plugins. i am for this idea
> of
> >> modularity 100%. my only question is where do we start?
> >>
> >> On Fri, 24 Sep 2010 13:57:16 -0400, miss c  wrote:
> >>
> >> > Would it be a plausible feature in the future to have the code accept
> >> > third
> >> > party plug-ins instead of creating whole new viewers?  Then have a
> Third
> >> > party
> >> > directory approved plug-in list.  As I mentioned before, my husband is
> >> > making an
> >> > external installer for people that may have difficulty installing
> skins
> >> > into the
> >> > new viewer, this will be a directory that all skin designers can add
> >> > their skins
> >> > to.  Wouldn't it be better to have a RLV plug in or an AO plug in, or
> a
> >> > radar
> >> > plugin that displays distance, then have to add all that to each
> >> > viewer?  I do
> >> > realize that there may be some things that Linden Lab might not want
> to
> >> > add to
> >> > their code but if its switched to a plug in system, people can pick
> and
> >> > choose
> >> > which additional features they prefer without having whats considered
> >> > competing
> >> > iewers.
> >> >
> >> > TY
> >> >
> >> > Miss
> >> >
> >> >
> >> >
> >>
> >>
> >> --
> >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> >> ___
> >> 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
> >
> >
> >
> > --
> >
> ---
> > This email is a private and confidential communication. Any use of email
> may
> > be subject to the laws and regulations of the United States. You may not
> > Repost, Distribute nor reproduce any content of this message.
> >
> ---
> >
> ---
> >
> > ___
> > 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
> >
>



-- 
---
This email is a private and confidential communication. Any use of email may
be subject to the laws and regulations of the United States. You may not
Repost, Distribute nor reproduce any content of this message.
---
---
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting priv

Re: [opensource-dev] Third Party Plug-ins?

[Rob Nelson]

 Lua's been implemented in a TPV successfully, meaning client-side 
scripting is definitely possible.  The only problem is that the viewer 
was never intended to have a scripting engine built-in, so lots of 
hacking on the backend to expose useful methods to the scripting engine 
is required.  The threading is also a mess right now.


Another consideration is what restrictions LL will want on these 
plugins.  I've already gone ahead and assumed that LL doesn't want 
scripts to have raw access to the messaging system, to avoid having 
malicious plugins sending disruptive or dangerous packets to the 
network.  I've also placed a policy on viewer development where access 
to economic functions must be approved by the user (via a warning dialog 
or a settings checkbox), and TPV policies (such as checking for creator 
permissions before accessing an object) have also been implemented.


Rob Nelson
Luna Viewer

On 9/24/2010 5:43 PM, Brandon Husbands wrote:
Yikes... I misread your post. LOL There are plenty on this list that 
try to close threads with links to past discussions. LOL my bad.. Ty 
for the links.


On Fri, Sep 24, 2010 at 5:54 PM, Ricky > wrote:


Please read these threads for the discussions we had on the types and
limits of various plugin schemes:
* "Client-side scripting in Snowglobe" -

https://lists.secondlife.com/pipermail/opensource-dev/2010-February/88.html
* "Consensus? was: Client-side scripting in Snowglobe" -

https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000167.html
* "Client Plugin System Design" -
https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000624.html

There are many useful ideas and documented pitfalls to avoid.  With
due consideration of these conversations many of the expected
issues/fears can be "headed off at the pass" you might say.

Ricky
Cron Stardust

On Fri, Sep 24, 2010 at 3:14 PM, Brandon Husbands
mailto:xot...@gmail.com>> wrote:
> I have already started work on a plugin system with embeded
mono. Which you
> expose methods to the api.. This allows anyone to use any CLI
language to
> create plugins.
>
> I can post more info on this later. A tad bit busy at the moment.
>
> On Fri, Sep 24, 2010 at 4:20 PM, malachi mailto:mala...@tamzap.com>> wrote:
>>
>> i for one particularly love this idea. i think there should be
a way for
>> the default LL issued viewer to be a plain jane for every user
client. but
>> allow third party devs to create plugins that do whatever they
want. the
>> idea of the radar and ao are amazing. but dont stop there.
there are tons
>> of things that average users DO NOT use in the client already.
LL could
>> simply remove those items and offer them as plugins. i am for
this idea of
>> modularity 100%. my only question is where do we start?
>>
>> On Fri, 24 Sep 2010 13:57:16 -0400, miss c mailto:miss_c...@yahoo.com>> wrote:
>>
>> > Would it be a plausible feature in the future to have the
code accept
>> > third
>> > party plug-ins instead of creating whole new viewers?  Then
have a Third
>> > party
>> > directory approved plug-in list.  As I mentioned before, my
husband is
>> > making an
>> > external installer for people that may have difficulty
installing skins
>> > into the
>> > new viewer, this will be a directory that all skin designers
can add
>> > their skins
>> > to.  Wouldn't it be better to have a RLV plug in or an AO
plug in, or a
>> > radar
>> > plugin that displays distance, then have to add all that to each
>> > viewer?  I do
>> > realize that there may be some things that Linden Lab might
not want to
>> > add to
>> > their code but if its switched to a plug in system, people
can pick and
>> > choose
>> > which additional features they prefer without having whats
considered
>> > competing
>> > iewers.
>> >
>> > TY
>> >
>> > Miss
>> >
>> >
>> >
>>
>>
>> --
>> Using Opera's revolutionary e-mail client:
http://www.opera.com/mail/
>> ___
>> 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
>
>
>
> --
>

---
> This email is a private and confidential communication. Any use
of email may
> be subject to the laws and regulations of the United States. You
may not
> Repost, Distribute nor reproduce any content of this message.
>

--

Re: [opensource-dev] major problem with beta 2.2 - link

[miss c]

I just uninstalled and installed the latest 2.2.1 (210446)  and the bug is 
still 
there.  There is something incorrect with the commands "user_name" as I have 
combed through the working version and this one and every xml file is stil the 
same.





From: Trilo Byte 
To: miss c 
Cc: opensource-dev@lists.secondlife.com
Sent: Fri, September 24, 2010 6:13:58 PM
Subject: Re: [opensource-dev] major problem with beta 2.2 - link

I've seen the problem as well (and voted on the issue), but did not see it in 
the 2.2.0 beta (build 210127).  This only broke in a more recent build (one of 
the ones from yesterday, I believe).


On Sep 24, 2010, at 4:11 PM, miss c wrote:


>Here is a screen shot of the bug
>
>http://www.flickr.com/photos/toxiancity/5021728112/#/photos/toxiancity/5021728112/lightbox/
>
>
>
>

From: Kent Quirk (Q Linden) 
>To: Erin Mallory 
>Cc: opensource-dev@lists.secondlife.com
>Sent: Fri, September 24, 2010 4:39:37 PM
>Subject: Re: [opensource-dev] major problem with beta 2.2
>
>
>
>On Sep 24, 2010, at 2:36 PM, Erin Mallory wrote:
>
>As a User I expect and NEED usernames to be displayed in group chat and used 
>properly in group and conference chat logs.
>>Instead I am seeing in both chat and in logs, usernames replaced with the 
>>group 
>>or conference name!!!
>>
>>

>
>
>I see this in the development tip (210412) but NOT in the beta (210127). Is 
>anyone seeing it in the beta?
>
>___
>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] Congratulations on 2-2-0-beta

[Ponzu]

It's a step forward.  Personally, I don't care about AA anyway.  Now,
the Too Many Files bug.  That MUST be fixed???!?!?!?  Waht the
hells wrong with those damn Lindens anyway!?!?!!??

Oh, sorry, 

lee


On Fri, Sep 24, 2010 at 7:09 PM, Trilo Byte  wrote:
> Hard to feel congratulatory when the beta was pushed out with a known major 
> regression (anti-aliasing has been broken since build 208569).
>
> On Sep 24, 2010, at 8:08 AM, Ponzu wrote:
>
>> Pat yourselves on the back 8-)
>>
>> By the way, will there be a 2-1-0-beta tag on the viewer-beta and 
>> viewer-development bitbucket repositories?
>> ___
>> 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] Which viewer should I use as the new beta?

[miss c]

The version I have is much higher than the public release.  It looks like an 
update was pulled 9 hours ago from the repro, but I just downloaded this new 
version a couple of hours ago.

I am on 2.2.1 (210446) 

The official beta release appears to be 2.2.0 (210127)

Was the release reverted or do I have the bug tester version or something?  The 
whole group chat displaying group names instead of avatar names is really 
frustrating, but I do not want to revert any new features by installing the 
older.

Please Advise,

TY

Miss



  ___
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] Third Party Plug-ins?

[Brandon Husbands]

My idea would be like installing a android app it says what it wants access
to and asks user permission.
Using embeded mono also the dlls have to be compiled.  Threading will be
fine you just have to know where to abstract it. Unlike lua mono handles its
own threading. LUA is too much a scripting lang IMHO.

On Fri, Sep 24, 2010 at 8:29 PM, Rob Nelson wrote:

>  Lua's been implemented in a TPV successfully, meaning client-side
> scripting is definitely possible.  The only problem is that the viewer was
> never intended to have a scripting engine built-in, so lots of hacking on
> the backend to expose useful methods to the scripting engine is required.
> The threading is also a mess right now.
>
> Another consideration is what restrictions LL will want on these plugins.
> I've already gone ahead and assumed that LL doesn't want scripts to have raw
> access to the messaging system, to avoid having malicious plugins sending
> disruptive or dangerous packets to the network.  I've also placed a policy
> on viewer development where access to economic functions must be approved by
> the user (via a warning dialog or a settings checkbox), and TPV policies
> (such as checking for creator permissions before accessing an object) have
> also been implemented.
>
> Rob Nelson
> Luna Viewer
>
>
> On 9/24/2010 5:43 PM, Brandon Husbands wrote:
>
> Yikes... I misread your post. LOL There are plenty on this list that try to
> close threads with links to past discussions. LOL my bad.. Ty for the links.
>
> On Fri, Sep 24, 2010 at 5:54 PM, Ricky  wrote:
>
>> Please read these threads for the discussions we had on the types and
>> limits of various plugin schemes:
>> * "Client-side scripting in Snowglobe" -
>>
>> https://lists.secondlife.com/pipermail/opensource-dev/2010-February/88.html
>> * "Consensus? was: Client-side scripting in Snowglobe" -
>>
>> https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000167.html
>> * "Client Plugin System Design" -
>>
>> https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000624.html
>>
>> There are many useful ideas and documented pitfalls to avoid.  With
>> due consideration of these conversations many of the expected
>> issues/fears can be "headed off at the pass" you might say.
>>
>> Ricky
>> Cron Stardust
>>
>> On Fri, Sep 24, 2010 at 3:14 PM, Brandon Husbands 
>> wrote:
>> > I have already started work on a plugin system with embeded mono. Which
>> you
>> > expose methods to the api.. This allows anyone to use any CLI language
>> to
>> > create plugins.
>> >
>> > I can post more info on this later. A tad bit busy at the moment.
>> >
>> > On Fri, Sep 24, 2010 at 4:20 PM, malachi  wrote:
>> >>
>> >> i for one particularly love this idea. i think there should be a way
>> for
>> >> the default LL issued viewer to be a plain jane for every user client.
>> but
>> >> allow third party devs to create plugins that do whatever they want.
>> the
>> >> idea of the radar and ao are amazing. but dont stop there. there are
>> tons
>> >> of things that average users DO NOT use in the client already. LL could
>> >> simply remove those items and offer them as plugins. i am for this idea
>> of
>> >> modularity 100%. my only question is where do we start?
>> >>
>> >> On Fri, 24 Sep 2010 13:57:16 -0400, miss c 
>> wrote:
>> >>
>> >> > Would it be a plausible feature in the future to have the code accept
>> >> > third
>> >> > party plug-ins instead of creating whole new viewers?  Then have a
>> Third
>> >> > party
>> >> > directory approved plug-in list.  As I mentioned before, my husband
>> is
>> >> > making an
>> >> > external installer for people that may have difficulty installing
>> skins
>> >> > into the
>> >> > new viewer, this will be a directory that all skin designers can add
>> >> > their skins
>> >> > to.  Wouldn't it be better to have a RLV plug in or an AO plug in, or
>> a
>> >> > radar
>> >> > plugin that displays distance, then have to add all that to each
>> >> > viewer?  I do
>> >> > realize that there may be some things that Linden Lab might not want
>> to
>> >> > add to
>> >> > their code but if its switched to a plug in system, people can pick
>> and
>> >> > choose
>> >> > which additional features they prefer without having whats considered
>> >> > competing
>> >> > iewers.
>> >> >
>> >> > TY
>> >> >
>> >> > Miss
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>> >> ___
>> >> 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
>> >
>> >
>> >
>> > --
>> >
>> ---
>> > This email is a private and confidential communication. Any use of email
>> may
>> > be subject to the laws