Re: [opensource-dev] Cocoa Project Viewer
Some time ago LL went through a phase of restricting how small the viewer window could be made, which turned out to be something of a mistake. For example, I sometimes need to run my viewer at less than full screen on my 1024x768 scrreen -- I want to expose part of the desktop while monitoring for chat/IMs/etc. I'd suggest not (re)imposing any limit and let the end user determine what works best for them. -jonathan On 2/24/13, Geenz Spad ge...@geenzo.com wrote: The minimum size for the window (as defined in SecondLife.xib) is 1024x768. This is largely to prevent any odd cases where UI elements end up getting clipped by the window inadvertently (though this is largely only a problem with the width of the window, not the height). I'll see about making the minimum size for the height of the window smaller. On Sun, Feb 24, 2013 at 6:44 PM, Argent Stonecutter secret.arg...@gmail.com wrote: Where should I report bugs in the Cocoa Project Viewer? On a MBP running Snow Leopard with an 800 pixel high display, the window is taller than the screen and can't be shrunk, even by editing the NS window size settings in the .plist file. This makes it unusable on that laptop. Other than that, I hope some of the TPVs bring in that code base for their Mac versions, because it's wicked fast. ___ 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] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates
On Feb. 18, 2013, 7:25 a.m., Aleric Inglewood wrote: I don't understand this fix at ALL. It doesn't seem to make any sense :/... What you need is to set the final scale once the distance between destination and current become LESS than the minimum interpolation distance, because then interpolation will never update it anymore. This fix just makes condition true all the time for your test case at your frame rate, but will still fail to reach the final scale when you increase the frame rate (or when the destination scale is simply so close to the start scale that this condition is never true). Hello Aleric, I’m sorry you don’t understand this fix at all. In short: other cases like the one you mentioned still fail to reach the final scale will be treated in other parts of the code and are parts of other if/else conditions. I am aware that the LL version of drawable.cpp differs in several places from the one that Henri (or other TPVs) uses for example, and the change of this fix will not make sense in other viewers. - MartinRJ --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/#review1301 --- On Feb. 17, 2013, 7:02 p.m., MartinRJ Fayray wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/ --- (Updated Feb. 17, 2013, 7:02 p.m.) Review request for Viewer. Description --- At high framerates tiny prims get stuck upon interpolation when they are resized via script. I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), in lldrawable.cpp updateXform to decide whether a scale change requires an immediate rebuild or not. This addresses bug BUG-1709. https://jira.secondlife.com/browse/BUG-1709 Diffs - indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/617/diff/ Testing --- See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 Repository: https://bitbucket.org/MartinRJ/bug-1709 Thanks, MartinRJ Fayray ___ 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] Cocoa Project Viewer
Regarding where to post bugs. Post them under BUG on JIRA. Please include either Project Cocoa or Cocoa Project Viewer somewhere in the report to make it easier for me to track down any but reports specifically with this viewer. You need to allow for fixed screen decorations: Window title bar, screen menu bar, and dock (even if you hide the dock, you still can't reliably hit controls near the bottom of the screen because the dock pops up, so lots of people don't hide the dock). I've went ahead and removed the minimum window size constraint to allow you to make the viewer window as small as you want to rectify this. However, the default window size will still be 1024x768 on the viewer's first startup. Other problems I've noticed (from the discussion thread on SLU): I was having problems getting my avatar to load. Going into appearance and selecting current outfit clears that up. This shouldn't be related to my changes. My changes only focus on getting the viewer up to speed with Apple's Cocoa APIs, and replacing deprecated Carbon APIs in the process (with a few very specific exceptions, such as Gestalt). I also have a problem that the mouse vanishes after using it for a couple of minutes, makes it hard to control anything. The vanishing mouse bug is known, however I haven't had a consistently reproducible case for it. Any other details other than I used it for a few minutes would be greatly appreciated to help narrow it down. It reliably hangs on exit, like, every time, on both Mountain Lion (core i7) and Snow Leopard (32-bit core duo). The hang on exit is interesting. I'll look into the viewer's shut down process (I attempted to replicate how the Carbon based viewer handled this, but there's always the chance I missed a step in the process). And it doesn't ask me if I want to quit when I close the window. Will investigate it. Chances are there's a callback missing somewhere within the window implementation specifically. We already intercept quit signals within the application delegate, but it's possible that NSWindow close needs to be overridden as well. The antialiasing option doesn't seem to work unless you enable lighting and shadows, particularly noticeable on a laptop. I've just fixed this along with a bug where vsync would always be enabled. ___ 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
