[opensource-dev] Toggle menu item

[Bo Rossen]

Dear List,

Completely new to SecondLife viewer development, so please be gentle ;)

In the light of all the Emerald issues, I have decided that the only viewer
I am going to trust, is one that I build myself.
For this I have created a complete Lenny chroot on my linux box, installed
all the neccesary libraries, packages and Snowglobe 2009 sources.

I want to start out simple by just creating personal patches that apply
directly to the mainstream Snowglobe sources.
As this is a personal and private viewer, I won't be releasing it to the
public (but I might do so for the patches).

My first objective is to add a menu item to the bottom of the tools menu,
allowing to show the debug menu.
The reason for this, is that the default shortcut Control-Alt-Shift-D is
already taken by my OS (and thus kinda annoying).

I have patched indra/newview/skins/default/xui/en-us/menu_viewer.xml to have
the menu item become visible.
I have also patched indra/newview/llviewermenu.cpp to add functionality to
the button.

All seems well. When I click the menu item it indeed "toggles" the
visibility of the debug menu *YAY*
However, in the Emerald viewer (which also contains this very same menu item
but in a different place) the menu item is ALSO toggled.
Eg the menu item has a nice 'X' in front of it when it's "on".

My simple question: How do I duplicate this behavior?

Thanks in advance for any assistance,
-- 
Bo Rossen
bo dot rossen at gmail dot com
--
___
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] Request for review/testing: VWR-2058 3 submenu indicators (▶ a.k.a. U+25B6) should n't be hard-coded in context menu sub menu names

[Oz Linden (Scott Lawrence)]

Esbee - this looks like a good thing for us to pull in under the general 
cleanups category.



Boroondas - please recheck the Dutch files - I pulled in those fixes 3 
days ago, and you should have them in your repo now.



On 2010-09-02 20:41, Boroondas Gupte wrote:
As far as I know, VWR-20583 
 is on neither Product 
Backlog nor Sprint List, yet, but Tofu asked 
 
me about this on jira and already imported a fix for a /symptom/ 
 
of which this issue here is IMHO the /cause/.


My fix for this underlying issue can be found at 
http://bitbucket.org/boroondas/viewer-development-vwr-20583



  How my fix works

Up to now, all menu entries except those context menus automatically 
generated the submenu indicator when they had sub-entries. Context 
menu entries didn't to that, so the "▶" had to be explicitly encoded 
in the labels in the XUI files (for all submenu labels in all 
languages). I guess this was necessary in Viewer 1.x, because the 
generic way of adding a ">" (which was the indicator back then), 
wouldn't work for pie menus.


Now though, that context menus are regular rectangular menus, their 
entries can be handled just like other menu entries 
 
(regarding the "▶", at least) and that's what the changeset does 
. 
The big bulky rest of the changeset just removes all the hard-coded 
"▶" (and some left over ">" (>) for the Portuguese localization) 
from the context menus of all supported languages (except nl, which 
doesn't seem to have localized context menus for some reason), so they 
won't display twice now.



  Impact for users

As long as all hard-coded strings are in-sync, users wouldn't notice 
VWR-20583 nor its fix, except for whether the triangles aren't 
right-aligned in context menus (as they are in the main menus, so the 
fix makes this consistent, too.) However, VWR-17801 and the left over 
">"s in the Portuguese localization 
 
show how easily inconsistencies can creep in. Having the indicators 
handled automagically diminishes the risk of that happening again in 
the future.



  Impact for translators

One less thing to worry about, once this is fixed.


  Impact for developers

While generation of one of the context menus remains 
 
in a CPP file (instead of XUI like the others), that part of the code 
at least doesn't have to bother anymore with adding the indicator to 
each entry individually.



  Impact for UI designers / implementers

With the fix, it should now be easy to change the submenu indicator 
for either all menus (main menu and context menus) or either type 
individually. Changing it for single selected entries would now be 
more difficult, but I don't see any cases where this might be needed.



  Summary

Massive code duplication is usually bad. (Duh!)

Cheers,
Boroondas

PS: Well, as this is a request for review and testing, I should 
probably write something about that, too. Because I had to touch XUI 
files of all localizations except Dutch, it'd be good if people could 
test the context menus with the Viewer set to different languages. 
More detailed test plan in this jira comment 
.



___
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] Toggle menu item

[Bo Rossen]

Solved. I need to read better and notice the difference between
menu_item_call and menu_item_check *sighs*

-- 
Bo Rossen
bo dot rossen at gmail dot com
--
___
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] Dutch localization (was: Request for review/testing: VWR-20583 submenu indicators (▶ a.k.a. U+25B6) shouldn't be hard-coded in context me nu sub menu names)

[Boroondas Gupte]

 On 09/03/2010 12:01 PM, Oz Linden (Scott Lawrence) wrote:
> Boroondas - please recheck the Dutch files - I pulled in those fixes 3
> days ago, and you should have them in your repo now.
>
OK, looks like (some?) context menu entry labels are localized for
Dutch, but the localization has different file names and file structures
than other localizations: For example in
indra/newview/skins/default/xui/*en*/menu_*wearable_list_item*.xml line
43f

there's

<*context*_menu
 label="Attach to HUD"
 layout="topleft"
 *name="wearable_attach_to_hud"* />

while the corresponding Dutch entry is probably
indra/newview/skins/default/xui/*nl*/menu_*inventory*.xml line 77




Note the different file names, different element types and different
name attribute values. Especially regarding the latter, I have to wonder
how the Dutch string even gets found at all. (Apparently it /gets/
found. Or maybe I'm just reading the XUI wrong.)

However, looks like the labels in the Dutch localization were already
missing the "▶"s, ">"s or ">"s, so don't have to be adapted for my fix.

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] Request for review/testing: VWR-2058 3 submenu indicators (▶ a.k.a. U+25B6) should n't be hard-coded in context menu sub menu names

[Boroondas Gupte]

 On 09/03/2010 02:41 AM, Boroondas Gupte wrote:
> My fix for this underlying issue can be found at
> http://bitbucket.org/boroondas/viewer-development-vwr-20583
If you already cloned or pulled that, please re-pull, I've found

some more ">" to remove.

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] Plugins/Modular architecture

[Lawson English]

  On 9/2/10 8:13 AM, Talia Tokugawa wrote:
> [...]
> I know this has been suggested before as friends have suggested it. 
> Why not make the viewer more Modular? Introduce a plugin architecture. 
> Allow any user to "build" their own client that fits their needs and 
> requirements.
>

Its a HUGE undertaking to do that. LL wasn't willing to tackle the issue 
directly years ago and they probably don't have the resources to do it 
now. It would have to be a community-lead effort and I'm not sure that 
developers are willing to invest the time to refactor the viewer at that 
level unless LL will be willing to seriously consider using the 
resulting re-architectured viewer.


Lawson
___
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] Plugins/Modular architecture

[Oz Linden (Scott Lawrence)]

  On 2010-09-03 9:14, Lawson English wrote:
>On 9/2/10 8:13 AM, Talia Tokugawa wrote:
>> [...]
>> I know this has been suggested before as friends have suggested it.
>> Why not make the viewer more Modular? Introduce a plugin architecture.
>> Allow any user to "build" their own client that fits their needs and
>> requirements.
>>
> Its a HUGE undertaking to do that. LL wasn't willing to tackle the issue
> directly years ago and they probably don't have the resources to do it
> now. It would have to be a community-lead effort and I'm not sure that
> developers are willing to invest the time to refactor the viewer at that
> level unless LL will be willing to seriously consider using the
> resulting re-architectured viewer.

Try us...

___
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] Plugins/Modular architecture

[Ann Otoole]

Has this project code been brought forward to Visual Studio 2010?





From: Oz Linden (Scott Lawrence) 
To: opensource-dev@lists.secondlife.com
Sent: Fri, September 3, 2010 9:32:54 AM
Subject: Re: [opensource-dev] Plugins/Modular architecture

  On 2010-09-03 9:14, Lawson English wrote:
>On 9/2/10 8:13 AM, Talia Tokugawa wrote:
>> [...]
>> I know this has been suggested before as friends have suggested it.
>> Why not make the viewer more Modular? Introduce a plugin architecture.
>> Allow any user to "build" their own client that fits their needs and
>> requirements.
>>
> Its a HUGE undertaking to do that. LL wasn't willing to tackle the issue
> directly years ago and they probably don't have the resources to do it
> now. It would have to be a community-lead effort and I'm not sure that
> developers are willing to invest the time to refactor the viewer at that
> level unless LL will be willing to seriously consider using the
> resulting re-architectured viewer.

Try us...

___
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] Plugins/Modular architecture

[Brandon Husbands]

What id like to see is the viewer be distributed as a library. And we can
init our own project with can create the window etc and setup the ui..
Since you went lgpl you should have a compile option for a lib with a
established interface. Otherwise lgpl is kinda blargh.

On Fri, Sep 3, 2010 at 9:11 AM, Ann Otoole  wrote:

> Has this project code been brought forward to Visual Studio 2010?
>
> --
> *From:* Oz Linden (Scott Lawrence) 
> *To:* opensource-dev@lists.secondlife.com
> *Sent:* Fri, September 3, 2010 9:32:54 AM
> *Subject:* Re: [opensource-dev] Plugins/Modular architecture
>
>   On 2010-09-03 9:14, Lawson English wrote:
> >On 9/2/10 8:13 AM, Talia Tokugawa wrote:
> >> [...]
> >> I know this has been suggested before as friends have suggested it.
> >> Why not make the viewer more Modular? Introduce a plugin architecture.
> >> Allow any user to "build" their own client that fits their needs and
> >> requirements.
> >>
> > Its a HUGE undertaking to do that. LL wasn't willing to tackle the issue
> > directly years ago and they probably don't have the resources to do it
> > now. It would have to be a community-lead effort and I'm not sure that
> > developers are willing to invest the time to refactor the viewer at that
> > level unless LL will be willing to seriously consider using the
> > resulting re-architectured viewer.
>
> Try us...
>
> ___
> 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
>



-- 
---
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] Plugins/Modular architecture

[Storm Thunders]

This.

On Fri, Sep 3, 2010 at 10:11 AM, Ann Otoole wrote:

> Has this project code been brought forward to Visual Studio 2010?
>
>
___
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] Plugins/Modular architecture

[Oz Linden (Scott Lawrence)]

  On 2010-09-03 11:17, Brandon Husbands wrote:
> What id like to see is the viewer be distributed as a library. And we 
> can init our own project with can create the window etc and setup the 
> ui..  Since you went lgpl you should have a compile option for a lib 
> with a established interface. Otherwise lgpl is kinda blargh.

Anyone who wants to work on making build rules to construct such a 
library is welcome to do so.

There is significant room for interpretation when using the LGPL.  At 
Linden Lab, our intent is to enable the development of third party 
viewers and the improvement of our own viewer through mutual sharing of 
the requisite common technology.

Our interpretation is that modifying the build procedures provided in 
the source code to produce a library containing whatever subset of the 
licensed code the developer desires is a minor programming exercise.  
The result of linking that library (which may be either a static library 
or a shared one, and either is allowed) with whatever other code the 
developer requires to build a viewer is again a minor problem, and the 
results are essentially indistinguishable from one in which the 
developer just modified the build procedures in place to produce an 
executable application.  Essentially, the details of the linkage 
procedures used are a matter of packaging and have no end user effect.   
In practical programming terms a library is just a convenient package - 
it's like requiring that a grocery store sell a product only if it is 
first placed into a shopping cart while inside the store.   Essentially 
a library is just that - a shopping cart full of individually compiled 
modules, so there's no real difference between that and just using the 
modules separately (one could build a library containing exactly one 
module, or build an application that had only one module and one library).

It is our intent that developers be able to use the components that we 
have licensed under the LGPL to produce viewer applications, regardless 
of the linkage procedures used, so long as they make available any 
changes to those components as specified in the license.
___
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] J2C fast decoder

[Nicky Fullton]

Hello,

>> i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000
>> images, after a short test with openjpeg2000 from EPFL we have tested
>> last 3 days JasPer (only a POC apps to do some bench), we must do a lot
>> of work too, but this is a lil question... anybody here around never
>> tried it as alternative to OpenJPEG/KDU in a viewer?

>I'm not aware of anyone publishing results for such a test, but if you
>have the time it would be interesting reading.

You might be interested in:
http://bitbucket.org/NickyD/viewer-development/changeset/027bf44c5582

I made a rather quick hack to try Jasper instead of OpenJpeg to decode
images.

The patch has some very rough edges. In fact is the decoding into the
LLImageRaw buffer not correct.

I did not fix this (yet) because the results so far are not very promising.
Jasper can only decode around 20% of the jpeg, for the other 80% it will
create an error and then my code falls back to OpenJpeg.
This fallback makes the whole decoding rather slow, so it is hard to say
if Jasper would really be any faster.

Right now I am not sure if it would be reasonable to invest more time 
looking at Jasper. First the code would need to fixed upstream, so all 
images can be properly decoded. As this project looks rather dead, one
with JPEG2000 knowledge might have to step up for this.

On another note, you might like to try:
http://bitbucket.org/NickyD/viewer-development/changeset/e4eff3e2af39

This will at least skip the step of calling OpenJpeg in  
LImageJ2COJ::getMetadata (if possible, it will do sanity checks first).

>Some things to keep in
>mind. OpenJpeg has patches floating around on its ML against 1.3 that
>reports have claimed up to 40% speed increase in places due to
>unrolling the inner loops so finding them and testing would be good.

I did not find any of those, but then again maybe I did not look hard
enough.
There is certainly some potential in OpenJpeg.
There are some loops in t1_dec_sigpass and t1_dec_refpass that can be
easily rewritten. But there is some pretty tricky stuff in t1_dec_clnpass
that would need some cleaning and mqc decoder (mqc_decode) burns a lot
of time. But that one is especially hairy as it has side effects on its
input parameter.

I am not sure if anyone without enough deep knowledge of OpenJpeg (and
the dedication to recode a good part of it) would be able to improve
much of it.

Cheers,
   Nicky


  

___
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] Plugins/Modular architecture

[Glen Canaday]

This is the project I've started 50 times and never got further than
"YES! It compiles on all platforms! ...just.. need... everything. else."

Since it's LGPL now, we can make a modular plugin-based viewer that uses
LL's code as a starting point, and even incorporate BSD-licensed bits...
just convert all of the relevant sections of code into loadable libs
with a built-in that manages all of the plugin data centrally. That way
you can load and unload things like UIs and renderers on the fly without
ever logging out, and you can also include cool new things like "local
data" on your own computer, thus, if desired, having an integrated
desktop<->inworld presence.

Like I said... 50 times, never got further than the first sentence. Too
much work and not enough single geek. I had even named it "GROND" after
Sauron's battering ram.

Had trouble turning it into an acronym, though... "Generic Reusable
Omnipotent Networking Disaster," anyone?

--GC

On Fri, 2010-09-03 at 09:32 -0400, Oz Linden (Scott Lawrence) wrote:
> On 2010-09-03 9:14, Lawson English wrote:
> >On 9/2/10 8:13 AM, Talia Tokugawa wrote:
> >> [...]
> >> I know this has been suggested before as friends have suggested it.
> >> Why not make the viewer more Modular? Introduce a plugin architecture.
> >> Allow any user to "build" their own client that fits their needs and
> >> requirements.
> >>
> > Its a HUGE undertaking to do that. LL wasn't willing to tackle the issue
> > directly years ago and they probably don't have the resources to do it
> > now. It would have to be a community-lead effort and I'm not sure that
> > developers are willing to invest the time to refactor the viewer at that
> > level unless LL will be willing to seriously consider using the
> > resulting re-architectured viewer.
> 
> Try us...
> 
> ___
> 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] Plugins/Modular architecture

[Sythos]

On Fri, 03 Sep 2010 12:40:05 -0400
Glen Canaday  wrote:

> 
> Like I said... 50 times, never got further than the first sentence.
> Too much work and not enough single geek. I had even named it "GROND"
> after Sauron's battering ram.

this is why now all code is public and following few step you can
contribute all code you want... a optional switchable theme/UI/XUI can
be merged giving to all residents the freedom to choose the aspect on
monitor (viewer 1.x style too).

Is hard take LL base code, patch it, merge a LL-next-version to fit
newfeatures and patch again everything, i think this way to work is
great why all can fit a features (a single click in setup panel
enable/disable it maybe...) without care to merge everytime a new
features will be implemented by LL
___
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] J2C fast decoder

[Tofu Linden]

Altair Sythos Memo wrote:
> i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000
> images, after a short test with openjpeg2000 from EPFL we have tested
> last 3 days JasPer (only a POC apps to do some bench), we must do a lot
> of work too, but this is a lil question... anybody here around never
> tried it as alternative to OpenJPEG/KDU in a viewer?
> 
> ref: 
> http://www.ece.uvic.ca/~mdadams/jasper/

Chiming in late - when we were looking for a happy-licensed KDU
alternative (mid-late 2007) we tested both OpenJPEG and JasPer against a
typical SL data set.

OpenJPEG was (a bit) faster and better-maintained, so we went with
that.

Lots of things (dominant system architectures, our usage patterns,
project churn) have changed since then - re-evaluation is a great
idea.  Although the library's speed is only one of many axes. :)

Cheers,
-tofu
___
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] Proposed user story for inclusion in product backlog--- request list comments and a yea or nay.

[Nicky Perian]

As a developer, using VC++ 2008 Express Edition or Visual Studio 2008, I want 
correct boost and llqtwebkit library versions downloaded from Linden Lab. This 
would streamline the build process.
VWR-20739



  ___
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] code review request

[Kent Quirk (Q Linden)]

Hi, all, getting back into it a little during recovery. Can I please get a 
review and perhaps pull for:

http://jira.secondlife.com/browse/VWR-20945

Code is here:

Fix is in
https://bitbucket.org/kentquirk/vwr-20945

changeset 123b6d316c16

This issue is important to our release team.

Thanks!

   Q___
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] System Folders to Top

[Charlene Trudeau]

  "As a user, I would like to be able to sort the inventory folders by 
name and without setting the system folders to top. I would prefer to do 
this on the fly as the usefulness of having the system folders at the 
top or mixed in changes during my workflow. I often need 'my' folders to 
be preeminent over the system folders so that I can find things I have 
created or need for my work more readily than if I have to scroll below 
the system folders."

***

Unfortuantely, in Second Life 2.1.2 (208921) Sep  2 2010 03:43:01 
(Second Life Development), this debug setting 
(Inventory.SystemFoldersToTop) seems to have NO effect whatsoever, nor 
did it persist across logins to see if  relog would resort things.

This appears to be true in Second Life 2.1.1 (208043) Aug 11 2010 
16:07:37 (Second Life Release) also, because I can't sort the system 
folders back to the top using the debug menu but apparently it held 
settings from prior releases, which are now fixed/permanent without the 
debug setting to change things. In fact, 'restore to default' restores 
it to 'FALSE'. As if its now hard coded depending on how the setting was 
prior to some lost upgrade point.

Please restore this functionality. The only reason I have not placed a 
JIRA sooner is that the loss of functionality was 'hidden' by hard 
coding my former choice as the default through the upgrade cycle.

Should I be opening JIRA issues on things like this at this time?

Char




On 9/1/2010 13:49, Lance Corrimal wrote:
> Am Wednesday 01 September 2010 schrieb Suz Dollar:
>> As a user, I would like to be able to turn off the forced system
>> folders to top. This used to be an obvious and easy thing to
>> change back and forth on the fly and now seems to have been
>> removed and relegated to the debug menu.
> there's a debug menu item for that??? where which what how
>
>
>
> 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
>

___
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 Names open source

[Oz Linden (Scott Lawrence)]

  We had some technical difficulties with getting it properly prepared 
for publication (resolved with the able help of Aimee), but the source 
for the Display Names branch is now available at:

http://hg.secondlife.com/viewer-identity

It is worthy of notice that this is the first Project release under our 
new development methodology - source code and a running viewer available 
from an internal Linden Lab team other than Snowstorm.


___
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] Plugins/Modular architecture

[Glen Canaday]

> 
> this is why now all code is public and following few step you can
> contribute all code you want... a optional switchable theme/UI/XUI can
> be merged giving to all residents the freedom to choose the aspect on
> monitor (viewer 1.x style too).
> 
> Is hard take LL base code, patch it, merge a LL-next-version to fit
> newfeatures and patch again everything, i think this way to work is
> great why all can fit a features (a single click in setup panel
> enable/disable it maybe...) without care to merge everytime a new
> features will be implemented by LL

Like I said... lots of ideas, but not enough geek nor enough singlehood
to commit as much time to this kind of thing as it would need. It's like
looking through the window at some Shiny Animal you might be able to buy
and dearly want, but you could never afford to feed and you know it. It
makes me sad, heh.

The base idea for the GROND project was only a plugin manager,
memory/data manager, and these basic plugins:

1. A UI plugin. Allows for hot-loading a UI and handles all human I/O
that isn't related to rendering or audio.

2. A viewer plugin. Allows for hot-loading renderers since all scene
information is maintained by the data manager and not the renderer
library.

3. A protocol plugin. Would allow for protocol upgrades to occur on a
per-grid basis.Each grid could provide a plugin or just a protocol spec
to handle their own grid's communications needs, so that things like SL
2's incompatibility with OpenSim doesn't have to happen again. That was
a HUGE pain trying to get used to 2.0 on my own grid... it just didn't
work.

Some extras I came up with were:

1. An audio plugin. This plugin could handle all audio input and output
to and from the viewer. This would permit the use of voice (VOIP)
technology as well as play inworld sounds and streaming. Doesn't have to
only be audio, could be a "direct gstreamer" plugin. If it ate too much
bandwidth, it could be unloaded by the user or just self-throttled.

2. A client-side physics plugin. This plugin would handle all soft-body
physics to be displayed by the viewer. Note that all rigid-body physics
must be simulated on the server, with the collisions only reported to
the client. If it ate too much processor, it could be disabled.

3. A local filesystem plugin. This one's cool. Upload / download from
within an inworld object or from your own inventory - which could
display your own local filesystem as well as your inworld inventory.

This kind of thing could easily evolve into the first viable 3D desktop
that could also integrate emerging web technologies and do it completely
transparently.

But like has been said, it's HUGE. There's no WAY I could devote enough
time to it. It's the next Mosaic, and LL's already written the first
versions of all of the most important parts.

--GC


___
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