Re: [opensource-dev] Externally controllable viewers?

[Dana Moore]

ditto an interest here.
Specifically what we are interested in doing is capturing a human user's
motion via a cam and turning a set of those into avatar controls (e.g., move
left/right/forward, fly, sit). Any useful inputs or comments would help get
us on track.
thanks
ElectricSheep Expedition

On Sat, Sep 18, 2010 at 7:17 PM, Vex Streeter  wrote:

>  Who's currently working on doing external control of viewer functions,
> especially avatar control?  I know of a few people doing AR sorts of
> things that would qualify and some of the viewer-plugin and modularity
> work would certainly help.  I'm going to be doing some viewer hacking to
> allow some additional input devices and would like to be as general as
> possible (and not reinvent the wheel).
>
> Many thanks
> Vex
> ___
> 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
>



-- 
Dana
"Criticize by creating." — Michelangelo
___
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] UI Map

[miss c]

I noticed that when I go into the debug menu on the login page to access the UI 
tools, under the widget option there is a link to view widget lists, but it 
takes me to wiki.lindenlab.com which is password protected.  Would be so nice 
to 
have access to those lists.

TY

Miss





From: miss c 
To: opensource-dev@lists.secondlife.com
Sent: Mon, September 20, 2010 11:56:44 PM
Subject: [opensource-dev] UI Map


Hello,

I am working on a new skin for Viewer 2.XX.  I noticed that some of the 
textures 
aren't even used and I am having difficulty finding the referencing commands to 
apply them.  Example would be the bottom panel background image, which doesn't 
appear to be referenced in any of the xmls.  Is there a UI map or list of 
appropriate commands to apply the images?  I have made many changes but none 
seem to take effect.

Thank you
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

[opensource-dev] User Story: Inventory Sorting

[Zha Ewry]

As a user I want to be able to sort my inventory with tools which
embody familiar metaphors from Windows,  Mac and Linux file browsers.  I
expect a folder system which exposes attributes in a familiar fashion and
permits sorting of those attributes in a consistent fashion. I expect
folders to be sorted by date as well as their contents. I expect to be able
to leverage my experience as a computer user and find common metaphors such
as  sorting columns  implemented in the inventory sorter. I expect to be
able to create deeply nested folder structures and easily find things based
on most recently added, most recently modified, I expect a consistent
approach to displaying nested material throughout the viewer. I expect to be
able to select which details are exposed in an inventory view, and I expect
column sorting implemented in a familiar fashion.

~ Zha Ewry
___
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] A comment on work in progress with 2.1.2

[Zha Ewry]

The ability to tear off tabs into windows in the newest drops is a major bit
of progress. The lack of a simple "x" to close open floaters is huge
problem. Forcing people to close things by dock, minimize, means adding a
very disruptive click, move mouse, click again work flow to the
simple task of making something go away. The inverse is also true. It really
ought to be possible to get a floater up without having to take it off
the sidebar again and again. Roughly speaking, if you're doing a system with
window floaters, you ought to match the last 20 years of learned practice.
People expect familiar user interface elements to behave in familiar ways.
When you give them odd variants on expected patterns which don't stem from a
very clear and obviously better user workflow, you create a dissonant
experience. Lastly, any user workflow which requires mouse clocks and mouse
motions, prevents accessibility and requires people to switch input modes.
Again, 20 years of user interface evolution should be paid some heed.

~ Zha
___
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] User Story: Inventory Sorting

[miss c]

Zha,

I might be able to accomplish some of these requests within the skin UI.  The 
UI 
for 2.xx is so amazing, I am so thrilled to be digging into it after working in 
the 1.XX UI, bleh.  It would be a lot more helpful to us all if you had a list 
of specific suggestions, rather than burying requests in vague expectations.  I 
understand your frustration, going from Microsoft based terminology to Adobe 
terminology a few years ago was quite a task for me.  At this point though, the 
viewer terminology seems quite self explanitory to me with my current 
knowledge, 
can you please point out specific terminology which may be confusing to the 
average user?

TY

Miss





From: Zha Ewry 
To: opensource-dev@lists.secondlife.com
Sent: Tue, September 21, 2010 10:48:38 AM
Subject: [opensource-dev] User Story: Inventory Sorting

As a user I want to be able to sort my inventory with tools which 
embody familiar metaphors from Windows,  Mac and Linux file browsers.  I expect 
a folder system which exposes attributes in a familiar fashion and permits 
sorting of those attributes in a consistent fashion. I expect folders to be 
sorted by date as well as their contents. I expect to be able to leverage my 
experience as a computer user and find common metaphors such as  sorting 
columns 
 implemented in the inventory sorter. I expect to be able to create deeply 
nested folder structures and easily find things based on most recently added, 
most recently modified, I expect a consistent approach to displaying nested 
material throughout the viewer. I expect to be able to select which details are 
exposed in an inventory view, and I expect column sorting implemented in a 
familiar fashion. 

~ Zha Ewry



  ___
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] A comment on work in progress with 2.1.2

[Brandon Husbands]

The issue is that the floaters never close it is a.design flaw with the
sidebar

On Sep 21, 2010 11:11 AM, "Zha Ewry"  wrote:

The ability to tear off tabs into windows in the newest drops is a major bit
of progress. The lack of a simple "x" to close open floaters is huge
problem. Forcing people to close things by dock, minimize, means adding a
very disruptive click, move mouse, click again work flow to the
simple task of making something go away. The inverse is also true. It really
ought to be possible to get a floater up without having to take it off
the sidebar again and again. Roughly speaking, if you're doing a system with
window floaters, you ought to match the last 20 years of learned practice.
People expect familiar user interface elements to behave in familiar ways.
When you give them odd variants on expected patterns which don't stem from a
very clear and obviously better user workflow, you create a dissonant
experience. Lastly, any user workflow which requires mouse clocks and mouse
motions, prevents accessibility and requires people to switch input modes.
Again, 20 years of user interface evolution should be paid some heed.

~ Zha


___
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] UI Map

[Sarah (Esbee) Hutchinson]

Good catch, Miss C! I'm seeing this in both the release and development
Viewers.

I talked to Q and he doesn't see any reason we can't make that
page publicly accessible so I'll create a version of it on the public wiki
and we'll change the reference on that floater as well.

You can track the ticket here: https://jira.secondlife.com/browse/STORM-201

Best,
Esbee


On Tue, Sep 21, 2010 at 10:56 AM, miss c  wrote:

> I noticed that when I go into the debug menu on the login page to access
> the UI tools, under the widget option there is a link to view widget lists,
> but it takes me to wiki.lindenlab.com which is password protected.  Would
> be so nice to have access to those lists.
>
> TY
>
> Miss
>
> --
> *From:* miss c 
> *To:* opensource-dev@lists.secondlife.com
> *Sent:* Mon, September 20, 2010 11:56:44 PM
> *Subject:* [opensource-dev] UI Map
>
> Hello,
>
> I am working on a new skin for Viewer 2.XX.  I noticed that some of the
> textures aren't even used and I am having difficulty finding the referencing
> commands to apply them.  Example would be the bottom panel background image,
> which doesn't appear to be referenced in any of the xmls.  Is there a UI map
> or list of appropriate commands to apply the images?  I have made many
> changes but none seem to take effect.
>
> Thank you
> 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
>
___
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] Possibility to revert UI changes on snowstorm?

[Gigs]

On 09/20/2010 09:30 PM, Yoz Grahame wrote:
> If you're asking about reverting the entire viewer UI to 1.x: in short,
> no. In less short, we'd need an objective, well-reasoned argument
> against each and every one of the several hundred UI changes between 1.x
> and 2.x. See above.


Why would the burden be that way?   Linden Lab changed the status quo, 
they should be the ones justifying their new design, not the other way 
around.
___
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] Externally controllable viewers?

[Daniel Smith]

On Tue, Sep 21, 2010 at 5:11 AM, Dana Moore  wrote:

> ditto an interest here.
> Specifically what we are interested in doing is capturing a human user's
> motion via a cam and turning a set of those into avatar controls (e.g., move
> left/right/forward, fly, sit). Any useful inputs or comments would help get
> us on track.
> thanks
> ElectricSheep Expedition
>

Am not sure if you could do this in realtime with one camera (without some
sort of wearable tags)

Here is my tweet from yesterday about a Siggraph paper on animation based on
video keyframes/points:

3d #animation  from 2d clips.
http://bit.ly/9l5VPP - Their
#Siggraphpaper:
http://bit.ly 

Mapping this back to SL, this would open a lot of possibilties up for
animators.

Oh... and an iPhone 4 or new iPod touch might be a good input device!!  I
just remembered that they now have a built in gyroscrope.  There is
certainly the API in iOS to send out a realtime stream of user movements...
That would get you something you can intrepret as walking, running, turning,
sitting, flying...




>
> On Sat, Sep 18, 2010 at 7:17 PM, Vex Streeter wrote:
>
>>  Who's currently working on doing external control of viewer functions,
>> especially avatar control?  I know of a few people doing AR sorts of
>> things that would qualify and some of the viewer-plugin and modularity
>> work would certainly help.  I'm going to be doing some viewer hacking to
>> allow some additional input devices and would like to be as general as
>> possible (and not reinvent the wheel).
>>
>> Many thanks
>> Vex
>> ___
>> 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
>>
>
>
>
> --
> Dana
> "Criticize by creating." — Michelangelo
>
> ___
> 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
>



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

Re: [opensource-dev] Possibility to revert UI changes on snowstorm?

[Celierra Darling]

>From the "see above", I'd gather that the reason is that LL dislikes parts
of the 1.x UI about as much as they now dislike parts the 2.x one.  Both UIs
have well-publicized strikes against them now; I think an attempt to make
changes *away* from that 1.x status quo has been well-justified for a long
time (even if that might not seem as true for all the changes *to* where
2.0.0 ended up at).  Thus I'd agree with Yoz's request to look for ideas
that are improvements on both 1.x and 2.x, instead of just going back to 1.x
blindly.

Celi

On Tue, Sep 21, 2010 at 1:39 PM, Gigs  wrote:

> On 09/20/2010 09:30 PM, Yoz Grahame wrote:
> > If you're asking about reverting the entire viewer UI to 1.x: in short,
> > no. In less short, we'd need an objective, well-reasoned argument
> > against each and every one of the several hundred UI changes between 1.x
> > and 2.x. See above.
>
>
> Why would the burden be that way?   Linden Lab changed the status quo,
> they should be the ones justifying their new design, not the other way
> around.
> ___
> 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] Possibility to revert UI changes on snowstorm?

[Mike Monkowski]

Yoz Grahame wrote:
> When people are asked to explain why they don't 
> like it, they focus on a small but high-profile set of these changes, 

That is quite disingenuous.  People usually start by saying the complete 
2.x UI is terrible and they prefer the 1.x UI.  Then Lindens ask about 
specifics, and the litany starts, of course, with "a small but 
high-profile set of these changes."  There are some really horrible UI 
decisions that almost everyone picks first, but that is not to say there 
there is actually anything good among the rest of the the UI changes.

Small changes cannot fix the 2.x UI.  You really have only two 
reasonable choices:  revert the look and feel back to 1.x or make the UI 
completely customizable.  Anything else is just delusion and wasted effort.

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

[opensource-dev] Openjpeg/KDU the cold hard metrics

[Robin Cornelius]

Hi everyone

I have been doing some direct comparison between KDU and Openjpeg and
have some metrics to share with the rest of you (in case you have not
seen them already flying around on #opensl/ or AWG chat)

https://spreadsheets.google.com/ccc?key=0AiSrUP47_VxIdFY4Mi1VUkdnaXJsSVpldGRPZXoxc3c&hl=en#gid=0

The tests were done in a test harness using the LLImage class from the
viewer. 296 Typical SL textures which were complete were used, Each
texture was decoded to discard level 0 (fully) and the timing was only
done for the call to decode(). This was repeated 10 times to average
out some CPU load jitter and the results entered on to the
spreadsheet.  I did some variations on openjpeg 1.3 with builds on
VC2005 and 2008 and some different SSE and optimisation settings, I
also did a test with the Openjpeg V2 code from SVN, although I had to
remove 5 textures from the test to prevent this from crashing.

The SSE results are interesting, my CPU is an AMD Athlon II X4 64 bit
quad core but with 2005 and 2008 SSE2 slows down the decode
process,and 2008 also does a better optimisation job than 2005. I'm
still not 100% sure why the build of openjpeg supplied by imprudence
is better than my builds on 2005. I've also not done any tests on
linux, but the basic pattern of KDU being way faster than openjpeg 1.X
and 2.X being faster than 1.X i do not expect to change much, the only
thing that might change is ups and downs for various optimisations and
extra CPU instructions such as SSE behaving differently under gcc.

Openjpeg 2 is really looking like its made a massive improvement in
its speed, but currently its very unstable, as I said it crashes with
5 of my test textures (which appear to be perfectly normal RGBA
textures of common dimensions). Its also crashing with encode for
bakes and as far as i know it has issues/is not complete to handle
truncated streams either, all of which make usage in SL right this
moment not possible.

I think openjpeg 2 is where opensource effort should be directed as
its not _that_ far behind KDU for raw decode speed (compared to OJP
1.X) currently and yes I know the new KDU can use multiple cores, but
so what, we can run multiple decode threads, its nots if we are
decoding a GB image so that extra boost is probably not that
significant for the type of SL usage. So this brings us to the state
of Openjpeg 2.0, Now i know Dzontaz and Callum have done quite a bit
with Openjpeg of various versions in the past, if either of them are
watching do they have any insites to the current state of OJP 2.0 for
SL usage (or does anyone else), as very little has happened in
Openjpeg svn for a long while now I fear if we want this to work we
may have to fix it and supply the patches upstream ourselves. I
believe at one point Dzontas was using OJP 2 for download but OJP 1
for upload when testing it.

Regards

Robin
___
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] Openjpeg/KDU the cold hard metrics

[Aidan Thornton]

On 9/21/10, Robin Cornelius  wrote:
> I'm still not 100% sure why the build of openjpeg supplied by imprudence
> is better than my builds on 2005.

Imprudence is using the openjpeg SVN trunk version from a few months
ago, which is essentially a pre-release version of openjpeg 1.4 and is
slightly more optimised than 1.3.

You might want to try openjpeg from SVN yourself (the trunk version,
not the 2.0 branch). Make sure to try it with SSE enabled too - it has
some SSE-specific optimisations.
___
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] Openjpeg/KDU the cold hard metrics

[Robin Cornelius]

On Tue, Sep 21, 2010 at 7:44 PM, Aidan Thornton  wrote:
> On 9/21/10, Robin Cornelius  wrote:
>> I'm still not 100% sure why the build of openjpeg supplied by imprudence
>> is better than my builds on 2005.
>
> Imprudence is using the openjpeg SVN trunk version from a few months
> ago, which is essentially a pre-release version of openjpeg 1.4 and is
> slightly more optimised than 1.3.

I built off revision 635 from trunk and tried with no SSE/SSE1 and
SSE2 as per my results, SSE1 on 2008 gives the best effect, SSE2 is a
disaster all around on my setup.

Robin
___
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] Possibility to revert UI changes on snowstorm?

[Daniel Smith]

On Tue, Sep 21, 2010 at 11:25 AM, Mike Monkowski
wrote:

>
> Small changes cannot fix the 2.x UI.  You really have only two
> reasonable choices:  revert the look and feel back to 1.x or make the UI
> completely customizable.
>

+1 for customization.

Yoz has shown a more levelheaded approach to the UI problem than Oz Linden.
Both are under LL corporate constraints, to be sure.

I see 5 streams of development, going forward:

* 1.x TPVs that cherry pick the best bits of V2 features
* 2.x TPVs that cherry pick the best bits of V2 features, and in some cases,
offer patches to go back into the official 2.x stream
* 2.x LL viewer, where developers decide they can work with the process and
constraints of LL
* exploratory work at developing a viewer with Unity as a foundation
* everything else (Ajax, iPhone, Android, etc)

I dont think 5 streams are sustainable, but that is where we seem to be at
the moment.

A customizable UI would do much to circle the 1.x and 2.x development effort
wagons.


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

Re: [opensource-dev] Possibility to revert UI changes on snowstorm?

[Ponzu]

Just a gentle reminder.  This is NOT a forum for debating the merits of this
or that Viewer.

This is the forum for discussing Viewer 2 development.
___
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] A comment on work in progress with 2.1.2

[Anya Kanevsky]

Currently I use the re-dock as a close.  The downside being, of course, that
you cannot then reopen the floater in the same position.  Hold tight - this
is just one step on the way to customization heaven :)

2010/9/21 Brandon Husbands 

> The issue is that the floaters never close it is a.design flaw with the
> sidebar
>
> On Sep 21, 2010 11:11 AM, "Zha Ewry"  wrote:
>
> The ability to tear off tabs into windows in the newest drops is a major
> bit of progress. The lack of a simple "x" to close open floaters is huge
> problem. Forcing people to close things by dock, minimize, means adding a
> very disruptive click, move mouse, click again work flow to the
> simple task of making something go away. The inverse is also true. It
> really ought to be possible to get a floater up without having to take it
> off
> the sidebar again and again. Roughly speaking, if you're doing a system
> with window floaters, you ought to match the last 20 years of learned
> practice. People expect familiar user interface elements to behave in
> familiar ways. When you give them odd variants on expected patterns which
> don't stem from a very clear and obviously better user workflow, you create
> a dissonant experience. Lastly, any user workflow which requires mouse
> clocks and mouse motions, prevents accessibility and requires people to
> switch input modes. Again, 20 years of user interface evolution should be
> paid some heed.
>
> ~ Zha
>
>
> ___
> 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
>
___
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] Possibility to revert UI changes on snowstorm?

[Ponzu]

On Tue, Sep 21, 2010 at 2:51 PM, Daniel Smith  wrote:

>
>
>
> +1 for customization.
>
> An effort to merge the 1.x and 2.x UI into a viewer with a highly
customizable interface might be fun.  At some point, I could even see the
Lindens being officially tasked with that effort.  For right now, it is
unlikely to be the Lindens who lead that way.

Could you break the Viewer into two parts, the innards and then UI.  Sort of
a model-view-controller approach?  Make the View a separate process perhaps,
that talks to the controller-model?  That might be useful to people who want
SL on their iPhone 8-)

Sounds really hard to me, plus the extra layer of abstraction will
contribute to lag.  (Imagine a graphics engine that creates a movie file,
and then streams that to your phone).
___
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] Possibility to revert UI changes on snowstorm?

[Mike Monkowski]

Ponzu wrote:
> Just a gentle reminder.  This is NOT a forum for debating the merits of 
> this or that Viewer. 
>  
> This is the forum for discussing Viewer 2 development.

But it IS a forum for debating the merits of this or that feature of any 
viewer (SL based or otherwise) or any possible feature.

Did I miss the announcement when this forum became limited to simply 
agreeing with Linden pronouncements?

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] Possibility to revert UI changes on snowstorm?

[Mike Monkowski]

I don't know what a model-view-controller approach is, but if you say it 
adds an extra layer of abstraction, then it doesn't matter anyway.

The UI is defined in XML and so is called XUI.  Admiral Admiral and I 
wrote some patches that, among other things, let you instantiate a 
floater from XML on the fly so that you could edit XML and reload 
immediately to see the effect of your changes.  See VWR-10924. 
Unfortunately the 2.x changes stomped all over the code affected by the 
patches and made it incompatible.

1.x was starting to implement callback functions that could be 
referenced by name rather than hardcoded as part of the floater 
initialization routine.  That was a good step toward being customizable. 
  I think there were some people in Linden Lab that may have been headed 
in that direction.

It's not "really hard."  It's just a matter of priorities.

Mike


Ponzu wrote:
> 
> 
> On Tue, Sep 21, 2010 at 2:51 PM, Daniel Smith  > wrote:
> 
>  
> 
> 
> +1 for customization.
> 
> An effort to merge the 1.x and 2.x UI into a viewer with a highly 
> customizable interface might be fun.  At some point, I could even see 
> the Lindens being officially tasked with that effort.  For right now, it 
> is unlikely to be the Lindens who lead that way.
>  
> Could you break the Viewer into two parts, the innards and then UI.  
> Sort of a model-view-controller approach?  Make the View a separate 
> process perhaps, that talks to the controller-model?  That might be 
> useful to people who want SL on their iPhone 8-)
>  
> Sounds really hard to me, plus the extra layer of abstraction will 
> contribute to lag.  (Imagine a graphics engine that creates a movie 
> file, and then streams that to your phone).
>  

___
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] Possibility to revert UI changes on snowstorm?

[miss c]

The point is people do not like change.  I love the new UI and to assist people 
with making that change I have been working today on making the UI look similar 
to the old one.  Such a coincidence this was brought up.  Its going to be the 
same color scheme with a few shiny upgrades to make it look more state of the 
art.  See link...  
http://farm5.static.flickr.com/4113/5012955294_3f0d0de19b_b.jpg

Miss







From: Mike Monkowski 
To: Ponzu 
Cc: opensource-dev@lists.secondlife.com
Sent: Tue, September 21, 2010 2:40:47 PM
Subject: Re: [opensource-dev] Possibility to revert UI changes on snowstorm?

I don't know what a model-view-controller approach is, but if you say it 
adds an extra layer of abstraction, then it doesn't matter anyway.

The UI is defined in XML and so is called XUI.  Admiral Admiral and I 
wrote some patches that, among other things, let you instantiate a 
floater from XML on the fly so that you could edit XML and reload 
immediately to see the effect of your changes.  See VWR-10924. 
Unfortunately the 2.x changes stomped all over the code affected by the 
patches and made it incompatible.

1.x was starting to implement callback functions that could be 
referenced by name rather than hardcoded as part of the floater 
initialization routine.  That was a good step toward being customizable. 
  I think there were some people in Linden Lab that may have been headed 
in that direction.

It's not "really hard."  It's just a matter of priorities.

Mike


Ponzu wrote:
> 
> 
> On Tue, Sep 21, 2010 at 2:51 PM, Daniel Smith  > wrote:
> 
>  
> 
> 
> +1 for customization.
> 
> An effort to merge the 1.x and 2.x UI into a viewer with a highly 
> customizable interface might be fun.  At some point, I could even see 
> the Lindens being officially tasked with that effort.  For right now, it 
> is unlikely to be the Lindens who lead that way.
>  
> Could you break the Viewer into two parts, the innards and then UI.  
> Sort of a model-view-controller approach?  Make the View a separate 
> process perhaps, that talks to the controller-model?  That might be 
> useful to people who want SL on their iPhone 8-)
>  
> Sounds really hard to me, plus the extra layer of abstraction will 
> contribute to lag.  (Imagine a graphics engine that creates a movie 
> file, and then streams that to your phone).
>  

___
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] Possibility to revert UI changes on snowstorm?

[Kuraiko Yoshikawa]

i guess the skin is the slightest 2.x ui problem... rather it is the 
only good thing about it


Am 21.09.2010 23:05, schrieb miss c:
The point is people do not like change.  I love the new UI and to 
assist people with making that change I have been working today on 
making the UI look similar to the old one.  Such a coincidence this 
was brought up.  Its going to be the same color scheme with a few 
shiny upgrades to make it look more state of the art.  See link... 
http://farm5.static.flickr.com/4113/5012955294_3f0d0de19b_b.jpg


Miss




*From:* Mike Monkowski 
*To:* Ponzu 
*Cc:* opensource-dev@lists.secondlife.com
*Sent:* Tue, September 21, 2010 2:40:47 PM
*Subject:* Re: [opensource-dev] Possibility to revert UI changes on 
snowstorm?


I don't know what a model-view-controller approach is, but if you say it
adds an extra layer of abstraction, then it doesn't matter anyway.

The UI is defined in XML and so is called XUI.  Admiral Admiral and I
wrote some patches that, among other things, let you instantiate a
floater from XML on the fly so that you could edit XML and reload
immediately to see the effect of your changes.  See VWR-10924.
Unfortunately the 2.x changes stomped all over the code affected by the
patches and made it incompatible.

1.x was starting to implement callback functions that could be
referenced by name rather than hardcoded as part of the floater
initialization routine.  That was a good step toward being customizable.
  I think there were some people in Linden Lab that may have been headed
in that direction.

It's not "really hard."  It's just a matter of priorities.

Mike


Ponzu wrote:
>
>
> On Tue, Sep 21, 2010 at 2:51 PM, Daniel Smith 

> >> wrote:
>
>
>
>
>+1 for customization.
>
> An effort to merge the 1.x and 2.x UI into a viewer with a highly
> customizable interface might be fun.  At some point, I could even see
> the Lindens being officially tasked with that effort.  For right 
now, it

> is unlikely to be the Lindens who lead that way.
>
> Could you break the Viewer into two parts, the innards and then UI.
> Sort of a model-view-controller approach?  Make the View a separate
> process perhaps, that talks to the controller-model?  That might be
> useful to people who want SL on their iPhone 8-)
>
> Sounds really hard to me, plus the extra layer of abstraction will
> contribute to lag.  (Imagine a graphics engine that creates a movie
> file, and then streams that to your phone).
>

___
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


___
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] Openjpeg/KDU the cold hard metrics

[Lillian Yiyuan]

Could you publish the test harness, I would like to try this on the
mac with a mactools build of v2

On Tue, Sep 21, 2010 at 2:49 PM, Robin Cornelius
 wrote:
> On Tue, Sep 21, 2010 at 7:44 PM, Aidan Thornton  wrote:
>> On 9/21/10, Robin Cornelius  wrote:
>>> I'm still not 100% sure why the build of openjpeg supplied by imprudence
>>> is better than my builds on 2005.
>>
>> Imprudence is using the openjpeg SVN trunk version from a few months
>> ago, which is essentially a pre-release version of openjpeg 1.4 and is
>> slightly more optimised than 1.3.
>
> I built off revision 635 from trunk and tried with no SSE/SSE1 and
> SSE2 as per my results, SSE1 on 2008 gives the best effect, SSE2 is a
> disaster all around on my setup.
>
> Robin
> ___
> 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] Possibility to revert UI changes on snowstorm?

[aklo]

Miss C,

as someone who's complained bitterly about the Viewer 2 UI, i wanna say
that i *like* change.  It just has to mean something.  It has to make
things better, not just different.  My opinion has been that the Viewer 2
UI seems to be trying to fix a lot of stuff that wasn't broken.  i think
what i'm criticizing is called "gratuitous change."

The added & improved functionality in Viewer 2 is awesome!  Everybody who
worked on that should feel real happy with themselves!  It's the using of
the functionality that's the problem.

It's not even stuff that skins are for.  Maybe people like shiny buttons,
or 3D ones, or whatever kinda color schemes.  Maybe even rearranged
toolbars & whatever.  The problem is pointless changes in the way a user
has to do the same things, things that were easy that are now more
complicated (or impossible!) without any perceivable reason for them being
that way, and drastic presentation changes that alter the way a person
feels about using the interface.

The UI isn't like looking in the closet in the morning to decide what to
wear, and matching earring & necklace selection to mood.  It's more like
where everything is in the kitchen, whether you can cook yourself an egg
sandwich for breakfast or have to eat some of McD's cardboard - or go
hungry until dinner, and whether you ride the bus or your bike to work. 
(Especially if it's raining!)

My biggest complaint has been that Viewer 2 UI's biggest change is making
SL less "real."  For me, that's the way wrong direction!  Instead of
browserfication of the controls and experience, i'd like to see things
moving more in the direction of controls and displays like enhanced
reality.  i think browserfication is going backwards.  i think others
agree?

Sorry if this msg was too long and sorta off-topic.  i'll go back to
lurking now.  Thx!

- AK

The point is people do not like change.  I love the new UI and to assist
people with making that change I have been working today on making the UI
look similar to the old one.  Such a coincidence this was brought up.  Its
going to be the same color scheme with a few shiny upgrades to make it
look more state of the art.  See link... 
http://farm5.static.flickr.com/4113/5012955294_3f0d0de19b_b.jpg

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] Possibility to revert UI changes on snowstorm?

[miss c]

AK,

I totally agree with you, the new functionality is awesome!  The problem is the 
UI, with 2.xx you can change just about anything in the UI compared to the old 
viewer where it was hard coded into the viewer.  I know that my husband was 
able 
to remove the sidebar completely and resize it, although I am not sure where he 
did that.   I know that Hitomi was able to move some of the buttons around on 
the interface with just skin commands.  I am just starting to get my feet wet 
in 
this new UI and figure out where everything is.   Sadly I am not a coder, but I 
want to do my part to help, and this is something I can do! ...  which is make 
the UI more user friendly, and more familiar.  


:)

Miss





From: "a...@skyhighway.com" 
To: miss_c...@yahoo.com
Cc: opensource-dev@lists.secondlife.com
Sent: Tue, September 21, 2010 4:59:36 PM
Subject: Re: [opensource-dev] Possibility to revert UI changes on snowstorm?

Miss C,

as someone who's complained bitterly about the Viewer 2 UI, i wanna say
that i *like* change.  It just has to mean something.  It has to make
things better, not just different.  My opinion has been that the Viewer 2
UI seems to be trying to fix a lot of stuff that wasn't broken.  i think
what i'm criticizing is called "gratuitous change."

The added & improved functionality in Viewer 2 is awesome!  Everybody who
worked on that should feel real happy with themselves!  It's the using of
the functionality that's the problem.

It's not even stuff that skins are for.  Maybe people like shiny buttons,
or 3D ones, or whatever kinda color schemes.  Maybe even rearranged
toolbars & whatever.  The problem is pointless changes in the way a user
has to do the same things, things that were easy that are now more
complicated (or impossible!) without any perceivable reason for them being
that way, and drastic presentation changes that alter the way a person
feels about using the interface.

The UI isn't like looking in the closet in the morning to decide what to
wear, and matching earring & necklace selection to mood.  It's more like
where everything is in the kitchen, whether you can cook yourself an egg
sandwich for breakfast or have to eat some of McD's cardboard - or go
hungry until dinner, and whether you ride the bus or your bike to work. 
(Especially if it's raining!)

My biggest complaint has been that Viewer 2 UI's biggest change is making
SL less "real."  For me, that's the way wrong direction!  Instead of
browserfication of the controls and experience, i'd like to see things
moving more in the direction of controls and displays like enhanced
reality.  i think browserfication is going backwards.  i think others
agree?

Sorry if this msg was too long and sorta off-topic.  i'll go back to
lurking now.  Thx!

- AK

The point is people do not like change.  I love the new UI and to assist
people with making that change I have been working today on making the UI
look similar to the old one.  Such a coincidence this was brought up.  Its
going to be the same color scheme with a few shiny upgrades to make it
look more state of the art.  See link... 
http://farm5.static.flickr.com/4113/5012955294_3f0d0de19b_b.jpg

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

[opensource-dev] Larger UI Question - Skinning Progress

[Nexeus Fatale]

So, I'm kinda getting sick of hearing about why the Viewer 2 UI is bad or
good, etc, etc, etc... it's kinda a pointless argument that should be left
for forums and forum threads where people can flame each other about what's
good or bad with the UI. I'm one of the view who likes many aspects of the
Viewer 2 UI - but that's neither here nor there...

The question I have, relates more to a topic that has been talked about and
displayed in the past, but I would love if there was an update or some
progress of the nature of the project. I want to know if the  Skinning (or
Project Dazzle - http://wiki.secondlife.com/wiki/Skinning) application to
the viewer (third party or other) is currently an active project? If so, at
what phase is it? Is the entire UI Skinnable and adaptable? or are only the
colors and feel changeable? Better question is are there any efforts among
the many third-party viewer developers to have created a skinning
template/process that isn't just adding/changing colors of the viewer?

As well, How far along the UI Roadmap is LL? (
http://wiki.secondlife.com/wiki/User_Interface_Roadmap)

I know this is a LOT of questions all at once, but I would love to hear more
about the current work towards the larger UI question, instead of this
snipping about the Viewer 2 UI not being good.
___
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] Larger UI Question - Skinning Progress

[malachi]

i didnt mean to spur arguments over the ui being good or bad mate. meant  
more or less is there a way to bring back the feel of 1.x clients. i like  
having everything in a pop up floater. not crammed into a bar that forces  
me to keep it there in one spot. i am not downing any of the ui changes. i  
think that the ui changes were done to make it easier for beginning users.  
but after using SL for over 4 years now i dont think i am a beginner. I  
just want my old detached floaters all over my screen in a very messy very  
ugly manner. lol. i suppose it is just time to start working on it and  
stop asking. LL and the others here have already told me that it may be  
possible but is not going to end up in the main viewer. thats fine with  
me. i dont need it to be in the main viewer. i dont use the main viewer. i  
dont trust 3rd party devs and i sure dont trust LL devs. not with a  
prebuilt binary. there is too much risk. so ill compile the latest branch  
myself and work on making my floaters the way i know them from before.  
thanks all.


On Tue, 21 Sep 2010 19:45:01 -0400, Nexeus Fatale  
 wrote:

> So, I'm kinda getting sick of hearing about why the Viewer 2 UI is bad or
> good, etc, etc, etc... it's kinda a pointless argument that should be  
> left
> for forums and forum threads where people can flame each other about  
> what's
> good or bad with the UI. I'm one of the view who likes many aspects of  
> the
> Viewer 2 UI - but that's neither here nor there...
>
> The question I have, relates more to a topic that has been talked about  
> and
> displayed in the past, but I would love if there was an update or some
> progress of the nature of the project. I want to know if the  Skinning  
> (or
> Project Dazzle - http://wiki.secondlife.com/wiki/Skinning) application to
> the viewer (third party or other) is currently an active project? If so,  
> at
> what phase is it? Is the entire UI Skinnable and adaptable? or are only  
> the
> colors and feel changeable? Better question is are there any efforts  
> among
> the many third-party viewer developers to have created a skinning
> template/process that isn't just adding/changing colors of the viewer?
>
> As well, How far along the UI Roadmap is LL? (
> http://wiki.secondlife.com/wiki/User_Interface_Roadmap)
>
> I know this is a LOT of questions all at once, but I would love to hear  
> more
> about the current work towards the larger UI question, instead of this
> snipping about the Viewer 2 UI not being good.


-- 
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] Larger UI Question - Skinning Progress

[Ponzu]

My unofficial answers:

On Tue, Sep 21, 2010 at 7:45 PM, Nexeus Fatale wrote:

> snip I want to know if the  Skinning (or Project Dazzle -
> http://wiki.secondlife.com/wiki/Skinning) application to the viewer (third
> party or other) is currently an active project?
>

Not to my knowledge.


> snip... Is the entire UI Skinnable and adaptable? or are only the colors
> and feel changeable?
>

More than just the colors, but less than "the entire".   IMHO, the UI
includes how you *use* the Viewer as well as how it looks.


>
>
> As well, How far along the UI Roadmap is LL? (
> http://wiki.secondlife.com/wiki/User_Interface_Roadmap)
>
>
> I don't know enough about this to answer, so I won't...
___
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] Larger UI Question - Skinning Progress

[miss c]

Well, I changed the whole bottom panel and upper bars with images so far so 
instead of just the colored chrome it does have a sleek image now.  Dimentox is 
working on an installer for skins for me, that everyone can use for those that 
screw up replacing certain files or just don't feel comfortable with it.  The 
external installer will also replace the UI to the default if wanted.  


http://www.flickr.com/photos/toxiancity/5012858747/lightbox/

Here is a picture of the bottom panel with the image, I was going for subtle.

Miss







From: Nexeus Fatale 
To: opensource-dev@lists.secondlife.com
Sent: Tue, September 21, 2010 6:45:01 PM
Subject: [opensource-dev] Larger UI Question - Skinning Progress

So, I'm kinda getting sick of hearing about why the Viewer 2 UI is bad or good, 
etc, etc, etc... it's kinda a pointless argument that should be left for forums 
and forum threads where people can flame each other about what's good or bad 
with the UI. I'm one of the view who likes many aspects of the Viewer 2 UI - 
but 
that's neither here nor there...

The question I have, relates more to a topic that has been talked about and 
displayed in the past, but I would love if there was an update or some progress 
of the nature of the project. I want to know if the  Skinning (or Project 
Dazzle 
- http://wiki.secondlife.com/wiki/Skinning) application to the viewer (third 
party or other) is currently an active project? If so, at what phase is it? Is 
the entire UI Skinnable and adaptable? or are only the colors and feel 
changeable? Better question is are there any efforts among the many third-party 
viewer developers to have created a skinning template/process that isn't just 
adding/changing colors of the viewer?

As well, How far along the UI Roadmap is LL? 
(http://wiki.secondlife.com/wiki/User_Interface_Roadmap)

I know this is a LOT of questions all at once, but I would love to hear more 
about the current work towards the larger UI question, instead of this snipping 
about the Viewer 2 UI not being good.


  ___
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] Larger UI Question - Skinning Progress

[miss c]

More...

The buttons are hand made in photoshop, not a color overlay.  As far as I can 
tell everything is "skinnable"  but I am still experimenting and digging around.

Miss





From: miss c 
To: opensource-dev@lists.secondlife.com
Sent: Tue, September 21, 2010 7:45:53 PM
Subject: Re: [opensource-dev] Larger UI Question - Skinning Progress


Well, I changed the whole bottom panel and upper bars with images so far so 
instead of just the colored chrome it does have a sleek image now.  Dimentox is 
working on an installer for skins for me, that everyone can use for those that 
screw up replacing certain files or just don't feel comfortable with it.  The 
external installer will also replace the UI to the default if wanted.  


http://www.flickr.com/photos/toxiancity/5012858747/lightbox/

Here is a picture of the bottom panel with the image, I was going for subtle.

Miss







From: Nexeus Fatale 
To: opensource-dev@lists.secondlife.com
Sent: Tue, September 21, 2010 6:45:01 PM
Subject: [opensource-dev] Larger UI Question - Skinning Progress

So, I'm kinda getting sick of hearing about why the Viewer 2 UI is bad or good, 
etc, etc, etc... it's kinda a pointless argument that should be left for forums 
and forum threads where people can flame each other about what's good or bad 
with the UI. I'm one of the view who likes many aspects of the Viewer 2 UI - 
but 
that's neither here nor there...

The question I have, relates more to a topic that has been talked about and 
displayed in the past, but I would love if there was an update or some progress 
of the nature of the project. I want to know if the  Skinning (or Project 
Dazzle 
- http://wiki.secondlife.com/wiki/Skinning) application to the viewer (third 
party or other) is currently an active project? If so, at what phase is it? Is 
the entire UI Skinnable and adaptable? or are only the colors and feel 
changeable? Better question is are there any efforts among the many third-party 
viewer developers to have created a skinning template/process that isn't just 
adding/changing colors of the viewer?

As well, How far along the UI Roadmap is LL? 
(http://wiki.secondlife.com/wiki/User_Interface_Roadmap)

I know this is a LOT of questions all at once, but I would love to hear more 
about the current work towards the larger UI question, instead of this snipping 
about the Viewer 2 UI not being good.



  ___
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] Question about error message

[Ponzu]

I get 12 of these messages when I build the latest ...

/Users/elee/Documents/hg/viewer-development/indra/llplugin/slplugin/slplugin.cpp:331:0
/Users/elee/Documents/hg/viewer-development/indra/llplugin/slplugin/slplugin.cpp:331:
warning: 'FrontWindow' is deprecated (declared at
/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/MacWindows.h:11398)

I don't think I am using the SLPlugin, so I am not concerned at the moment,
but if someone knows the quick fix, please let me know.


regards

lee
___
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] Question about error message

[Brandon Husbands]

IIRC
This is a heads-up message about the use of the FrontWindow API and
compatibility with the next major release of Mac OS X.

In the current version of Mac OS X, the menubar is drawn into a window that
does not have a corresponding WindowRef. The window is actually created with
CoreGraphics window server calls and not by the Carbon Window Manager. The
FrontWindow API never returns a WindowRef for the menubar.

In the next major release of Mac OS X, the Menu Manager will be creating the
menubar window using the Window Manager. The menubar will have a WindowRef.
Since the menubar is almost always the topmost visible window, this means
that the FrontWindow API will almost always return the menubar window, as
will the GetFrontWindowOfClass API when passed the kAllWindowClasses
constant.

FrontWindow has been a deprecated API for most usages since Mac OS 8.5, when
the FrontNonFloatingWindow API and built-in support for floating windows
were introduced. However, a lot of apps are still using it, and get away
with this in most cases because the app doesn't use floating windows itself.
This is no longer going to work.

It's very important to review your source code for uses of the FrontWindow
and GetFrontWindowOfClass APIs. It's perfectly OK to use these APIs if you
really do want the topmost visible window, of whatever kind, perhaps because
you're interating over the window list to examine each window. But if your
code is calling FrontWindow or GetFrontWindowOfClass(kAllWindowClasses) with
the assumption that this will return the active document or dialog window,
then you will have a compatibility problem on the next major release of X.
You will get back the menubar instead. You should replace such usages with
calls to FrontNonFloatingWindow or (preferred) ActiveNonFloatingWindow.



On Tue, Sep 21, 2010 at 8:00 PM, Ponzu  wrote:

> I get 12 of these messages when I build the latest ...
>
> /Users/elee/Documents/hg/viewer-development/indra/llplugin/slplugin/slplugin.cpp:331:0
> /Users/elee/Documents/hg/viewer-development/indra/llplugin/slplugin/slplugin.cpp:331:
> warning: 'FrontWindow' is deprecated (declared at
> /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/MacWindows.h:11398)
>
> I don't think I am using the SLPlugin, so I am not concerned at the moment,
> but if someone knows the quick fix, please let me know.
>
>
> regards
>
> lee
>
> ___
> 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] Question about error message

[Katharine Berry]

That message is both inaccurate and very old (the decision was reversed); 
however, the function is still deprecated.

Simply replacing all instances of FrontWindow with FrontNonFloatingWindow 
worked for me but I don't know if this is actually correct. Something like 
this: 
http://github.com/Katharine/kittyviewer/commit/64bf6f58f8d0dd4fab49c19571790e4247214c9a#diff-6

– Katharine Berry

On Sep 21, 2010, at 9:27 PM, Brandon Husbands wrote:

> IIRC 
> This is a heads-up message about the use of the FrontWindow API and 
> compatibility with the next major release of Mac OS X.
> 
> In the current version of Mac OS X, the menubar is drawn into a window that 
> does not have a corresponding WindowRef. The window is actually created with 
> CoreGraphics window server calls and not by the Carbon Window Manager. The 
> FrontWindow API never returns a WindowRef for the menubar.
> 
> In the next major release of Mac OS X, the Menu Manager will be creating the 
> menubar window using the Window Manager. The menubar will have a WindowRef. 
> Since the menubar is almost always the topmost visible window, this means 
> that the FrontWindow API will almost always return the menubar window, as 
> will the GetFrontWindowOfClass API when passed the kAllWindowClasses constant.
> 
> FrontWindow has been a deprecated API for most usages since Mac OS 8.5, when 
> the FrontNonFloatingWindow API and built-in support for floating windows were 
> introduced. However, a lot of apps are still using it, and get away with this 
> in most cases because the app doesn't use floating windows itself. This is no 
> longer going to work.
> 
> It's very important to review your source code for uses of the FrontWindow 
> and GetFrontWindowOfClass APIs. It's perfectly OK to use these APIs if you 
> really do want the topmost visible window, of whatever kind, perhaps because 
> you're interating over the window list to examine each window. But if your 
> code is calling FrontWindow or GetFrontWindowOfClass(kAllWindowClasses) with 
> the assumption that this will return the active document or dialog window, 
> then you will have a compatibility problem on the next major release of X. 
> You will get back the menubar instead. You should replace such usages with 
> calls to FrontNonFloatingWindow or (preferred) ActiveNonFloatingWindow.
> 
> 
> 
> On Tue, Sep 21, 2010 at 8:00 PM, Ponzu  wrote:
> I get 12 of these messages when I build the latest ...
> 
> /Users/elee/Documents/hg/viewer-development/indra/llplugin/slplugin/slplugin.cpp:331:0
>  
> /Users/elee/Documents/hg/viewer-development/indra/llplugin/slplugin/slplugin.cpp:331:
>  warning: 'FrontWindow' is deprecated (declared at 
> /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/MacWindows.h:11398)
> 
> I don't think I am using the SLPlugin, so I am not concerned at the moment, 
> but if someone knows the quick fix, please let me know.
> 
> 
> 
> regards
> 
> lee
> 
> 
> ___
> 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] Question about error message

[Brandon Husbands]

Should probably be committed to the hg. Maybe a jira on it with your patch?

On Tue, Sep 21, 2010 at 8:33 PM, Katharine Berry <
kathar...@katharineberry.co.uk> wrote:

> That message is both inaccurate and very old (the decision was reversed);
> however, the function is still deprecated.
>
> Simply replacing all instances of FrontWindow with FrontNonFloatingWindow
> worked for me but I don't know if this is actually correct. Something like
> this:
> http://github.com/Katharine/kittyviewer/commit/64bf6f58f8d0dd4fab49c19571790e4247214c9a#diff-6
>
> – Katharine Berry
>
>
> On Sep 21, 2010, at 9:27 PM, Brandon Husbands wrote:
>
> IIRC
> This is a heads-up message about the use of the FrontWindow API and
> compatibility with the next major release of Mac OS X.
>
> In the current version of Mac OS X, the menubar is drawn into a window that
> does not have a corresponding WindowRef. The window is actually created with
> CoreGraphics window server calls and not by the Carbon Window Manager. The
> FrontWindow API never returns a WindowRef for the menubar.
>
> In the next major release of Mac OS X, the Menu Manager will be creating
> the menubar window using the Window Manager. The menubar will have a
> WindowRef. Since the menubar is almost always the topmost visible window,
> this means that the FrontWindow API will almost always return the menubar
> window, as will the GetFrontWindowOfClass API when passed the
> kAllWindowClasses constant.
>
> FrontWindow has been a deprecated API for most usages since Mac OS 8.5,
> when the FrontNonFloatingWindow API and built-in support for floating
> windows were introduced. However, a lot of apps are still using it, and get
> away with this in most cases because the app doesn't use floating windows
> itself. This is no longer going to work.
>
> It's very important to review your source code for uses of the FrontWindow
> and GetFrontWindowOfClass APIs. It's perfectly OK to use these APIs if you
> really do want the topmost visible window, of whatever kind, perhaps because
> you're interating over the window list to examine each window. But if your
> code is calling FrontWindow or GetFrontWindowOfClass(kAllWindowClasses) with
> the assumption that this will return the active document or dialog window,
> then you will have a compatibility problem on the next major release of X.
> You will get back the menubar instead. You should replace such usages with
> calls to FrontNonFloatingWindow or (preferred) ActiveNonFloatingWindow.
>
>
>
> On Tue, Sep 21, 2010 at 8:00 PM, Ponzu  wrote:
>
>> I get 12 of these messages when I build the latest ...
>>
>> /Users/elee/Documents/hg/viewer-development/indra/llplugin/slplugin/slplugin.cpp:331:0
>> /Users/elee/Documents/hg/viewer-development/indra/llplugin/slplugin/slplugin.cpp:331:
>> warning: 'FrontWindow' is deprecated (declared at
>> /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/MacWindows.h:11398)
>>
>> I don't think I am using the SLPlugin, so I am not concerned at the
>> moment, but if someone knows the quick fix, please let me know.
>>
>>
>> regards
>>
>> lee
>>
>> ___
>> 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

Re: [opensource-dev] Larger UI Question - Skinning Progress - FURRY

[miss c]

Smiles

I just threw this one together.  The very first FURRY skin.

http://www.flickr.com/photos/toxiancity/5013092711/lightbox/






From: miss c 
To: opensource-dev@lists.secondlife.com
Sent: Tue, September 21, 2010 7:54:34 PM
Subject: Re: [opensource-dev] Larger UI Question - Skinning Progress


More...

The buttons are hand made in photoshop, not a color overlay.  As far as I can 
tell everything is "skinnable"  but I am still experimenting and digging around.

Miss





From: miss c 
To: opensource-dev@lists.secondlife.com
Sent: Tue, September 21, 2010 7:45:53 PM
Subject: Re: [opensource-dev] Larger UI Question - Skinning  Progress


Well, I changed the whole bottom panel and upper bars with images so far so 
instead of just the colored chrome it does have a sleek image now.  Dimentox is 
working on an installer for skins for me, that everyone can use for those that 
screw up replacing certain files or just don't feel comfortable with it.  The 
external installer will also replace the UI to the default if wanted.  


http://www.flickr.com/photos/toxiancity/5012858747/lightbox/

Here is a picture of the bottom panel with the image, I was going for subtle.

Miss







From: Nexeus Fatale 
To: opensource-dev@lists.secondlife.com
Sent: Tue, September 21, 2010 6:45:01 PM
Subject: [opensource-dev] Larger UI Question - Skinning Progress

So, I'm kinda getting sick of hearing about why the Viewer 2 UI is bad or good, 
etc, etc, etc... it's kinda a pointless argument that should be left for forums 
and forum threads where people can flame each other about what's good or bad 
with the UI. I'm one of the view who likes many aspects of the Viewer 2 UI - 
but 
that's neither here nor there...

The question I have, relates more to a topic that has been talked about and 
displayed in the past, but I would love if there was an update or some progress 
of the nature of the project. I want to know if the  Skinning (or Project 
Dazzle 
- http://wiki.secondlife.com/wiki/Skinning) application to the viewer (third 
party or other) is currently an active project? If so, at what phase is it? Is 
the entire UI Skinnable and adaptable? or are only the colors and feel 
changeable? Better question is are there any efforts among the many third-party 
viewer developers to have created a skinning template/process that isn't just 
adding/changing colors of the viewer?

As well, How far along the UI Roadmap is LL? 
(http://wiki.secondlife.com/wiki/User_Interface_Roadmap)

I know this is a LOT of questions all at once, but I would love to hear more 
about the current work towards the larger UI question, instead of this snipping 
about the Viewer 2 UI not being good.


  ___
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] Openjpeg/KDU the cold hard metrics

[Sheet Spotter]

I would love to see Robin's test harness. I would also love to see the
images that failed with v2.

I started diving into the v2 branch of OpenJPEG a few days ago, after
research JPEG 2000 for a week. Tackling the bugs from the failed images
might be a good way to become more familiar with the source code.

I posted a very minor patch correcting some simple build problems with the
DLL version of OpenJPEG V2.
http://code.google.com/p/openjpeg/issues/detail?id=40

Does anyone have a sense of how actively the OpenJPEG source code is
maintained?

Thank you for publishing your results, Robin. They are encouraging me to
continue looking at OpenJPEG v2.


Sheet Spotter

-Original Message-
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Lillian
Yiyuan
Sent: September 21, 2010 4:24 PM
Cc: opensource-dev
Subject: Re: [opensource-dev] Openjpeg/KDU the cold hard metrics

Could you publish the test harness, I would like to try this on the
mac with a mactools build of v2

On Tue, Sep 21, 2010 at 2:49 PM, Robin Cornelius
 wrote:
> On Tue, Sep 21, 2010 at 7:44 PM, Aidan Thornton 
wrote:
>> On 9/21/10, Robin Cornelius  wrote:
>>> I'm still not 100% sure why the build of openjpeg supplied by imprudence
>>> is better than my builds on 2005.
>>
>> Imprudence is using the openjpeg SVN trunk version from a few months
>> ago, which is essentially a pre-release version of openjpeg 1.4 and is
>> slightly more optimised than 1.3.
>
> I built off revision 635 from trunk and tried with no SSE/SSE1 and
> SSE2 as per my results, SSE1 on 2008 gives the best effect, SSE2 is a
> disaster all around on my setup.
>
> Robin
> ___
> 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

___
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] Request For Input: Menu Shortcut keys overriding Floaters handlekeyhere events. STORM-203

[Brandon Husbands]

While taking peek at STORM-203
https://jira.secondlife.com/browse/STORM-203?

It seems that shortcuts in the viewer menu are not allowing the floaters to
get input like ctrl F

My thoughts are to do one of the following

1. Add to the floater/focusmanager base class the ability to set priority
keys so floaters can set a handle first.
2. Add exceptions before the faulty code for the script editor. / modify the
faulty code to exclude ctrl f
3. Lock the script editors? (would that not make them modal? Yuck!)
4. Remove the priority code / faulty code. (possible adverse affects?)
5. *LAST DITCH* Change the shortcut to the search panel.

What do you think?

CODE causing the issue.

llViewerwindow.cpp

lines 2137 - 2146

// give menus a chance to handle modified (Ctrl, Alt) shortcut keys
before current focus
// as long as focus isn't locked
if (mask & (MASK_CONTROL | MASK_ALT) && !gFocusMgr.focusLocked())
{
if ((gMenuBarView && gMenuBarView->handleAcceleratorKey(key, mask))
||(gLoginMenuBarView &&
gLoginMenuBarView->handleAcceleratorKey(key, mask)))
{
return TRUE;
}
}

It appears that this is making shortcut keys grab the input before any
floaters are.
-- 
---
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] Openjpeg/KDU the cold hard metrics

[Yoz Grahame]

On 21 September 2010 20:01, Sheet Spotter  wrote:
>
>
> Does anyone have a sense of how actively the OpenJPEG source code is
> maintained?
>

Looking at
http://code.google.com/p/openjpeg/updates/list
(which has had a number of VS-related changes in the past month - see also
http://groups.google.com/group/openjpeg/browse_thread/thread/cbb01b2c14b43415)
and
http://groups.google.com/group/openjpeg
... I'd call it very active.

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