|
I think what some people want is a like a LSL based code-behind feature
to the UI. Did I say it? Oops, I did. Hold that thought. Actually, I'm eager for GtkBuilder to fully phase-in, then UI builders like the Glade Interface Designer would have lots of fun interactive, custom widgets ready to use in the palette: http://glade.gnome.org/screenshots.html Example vid of using Glade: http://people.redhat.com/overholt/nativeeclipse/ Of course, that was with Eclipse, and the Eclipse UI is written with Gtk. Hmmm - powerful enough for holistic programmers. Here is an older review of Glade: http://loosexaml.wordpress.com/2008/10/14/giving-glade-a-fair-shake/ The Glade Interface Designer is also a library, so it is embeddable (into some viewer app someday maybe): http://glade.gnome.org/docs/index.html Ok, I said too much. Cheers, http://twitter.com/Dzonatas Melinda Green wrote: Nexi, I'm not stating an opinion about the value of Windlight controls one way or the other. I do agree with you that it would be better if the setting names were better chosen in order to organize them into some meaningful hierarchy, but the chance to do that passed a long time ago. Even if someone did the huge job of changing the names throughout the entire source code and XUI content, that patch would never be accepted because of the branches within LL (and externally) that would be affected. The end result is that once you name a setting or control, it's nearly impossible/impractical to change it. We're then left with an underlying flat list of settings for better or worse and I therefore believe this is *not* the place to start! We could of course impose an external organization onto that list though a config UI like you suggest. That sounds like a good idea to me but is completely orthogonal to taking advantage of the existing XUI<-->saved settings bridge.If anyone wants to see good examples of doing the sort of stuff I'm talking about, I recommend looking at the new View->Beacons floater implementation that I created. It was implemented almost entirely in XML, only requiring C++ code to launch the floater and to enforce a couple of the previous quirky interactions between the beacon types. The rest is implemented entirely in XUI making heavy use of the control_name tag. BTW, this is how many of the Windlight controls were implemented too and was where I found the examples I needed when doing the beacons work. This is an incredibly powerful and underused pattern. -Melinda Nexii Malthus wrote:Well, I think we could start by re-working the debug-settings menu a bit. Load up Firefox and go to this page: "about:config" Thats an excellent example of a good debug settings menu. The settings are easily understandable imho. Seperated into their relevant sections, I think it would be great if we had that a similiar naming scheme. That would be at least one step towards opening up the deeper parts of the engine towards users. Not to mention the help it would provide to developers, lindens and non-lindens alike for making it easier to test out experimental features or performance optimizations. Imagine a naming scheme towards the graphical subsystems. render.spatial.maxnodesize for this situation as a loose example. Wouldn't it be easier and efficient to expose only the relevant debug settings to each subsystem too? render.* being available to the render stuff. network.* being for the network stuff. If we want to revamp the whole way preferences work we need to move step-by-step from the bottom up. I do agree that the LL designers feel a bit itchy about the current windlight preferences and I agree, it is messy. But its wrong to hide the tools for the right job when you consider the majority of individuals that are willing to go a step further to make their experience so much better. Just look at the stuff Torley and other talented photographers have made in snapshots by messing about in the windlight settings and shadows. - Nexii Malthus On Fri, Jun 19, 2009 at 9:45 PM, Melinda Green <meli...@superliminal.com <mailto:meli...@superliminal.com>> wrote: That's an interesting suggestion, Nexii. I'm not sure how the LL designers feel about all those Windlight preferences but I wouldn't be surprised if they'd mostly prefer to hide or eliminate most of them. There's always a tension between number of controls and the all-important SL learning curve. One way to break this logjam is to start using the new XUI features to allow external designers to create custom UI without the need for developers to hook them in and compile entire custom viewer binaries and then update them with each viewer version. Skinning is the first step on that road but there is a lot of other useful stuff under the hood that can also be used today. My favorite is the "control_name" XUI tag which lets you associate check box and slider values with particular saved settings. When you load a floater or other XUI element containing a check box or slider with that tag, then it takes it's initial value from the named saved setting and automatically saves back out modified values as the user interacts with those controls. This is extremely powerful and should let you create your custom panel to control any of the boolean or real valued settings that you see in the debug settings floater. The only thing really missing here (other than support for more control types) is the ability to launch a custom floater. Ideally that would come with the badly needed keyboard remapping functionality to allow you to specify a hot key to load a named floater. (Hint: Great Snowglobe feature here!) Since we don't have that yet, you'd probably have to append your controls to some existing floater if you want to add controls without programming, but that shouldn't be too awful. -Melinda Nexii Malthus wrote: I think by spatial groups you could consider how dense an area is. We really should open many more options on the preferences menu. Perhaps it should branch off into a seperate menu due to the relevant complexity, imagine how complex the windlight sliders are, but they are also nicely dispersed into their relevant categories and sections. We should aim to achieve the same, not to mention the explanations that were provided in the WindLight menu were pretty cool and awesome to understand what the settings do. WindLight is a mere single subsystem of the entire graphics system, why can't we have the same attention put into other areas in terms of control via the UI? There are many hidden settings, some that are not even affected by the more generalised "Low, Medium, High, Ultra" that have an impact on FPS and the experience. L$0.02. - Nexii Malthus On Fri, Jun 19, 2009 at 7:50 PM, Harleen Gretzky <gretzky.harl...@gmail.com <mailto:gretzky.harl...@gmail.com> <mailto:gretzky.harl...@gmail.com <mailto:gretzky.harl...@gmail.com>>> wrote: It appears to be more than just jewelry that is effected. VWR-14049 and VWR-14146 are builds that are effected also. When posing this question I was really trying to understand how the rendering limits work. For instance, does the renderMaxNodeSize limit apply to the entire scene, or only to portions of the scene? Does it apply to avatars as well as objects? It seems to have something to do with 'spatial groups' but what are 'spatial groups'? Is renderMaxNodeSize the only rendering limit? If renderMaxNodeSize is the only setting that, I would think the best solution as has been suggested on the JIRAs and here is to move the setting onto the Graphics preference tab. Since it seems to be a little low for those running graphics at High and Ultra it should probably be increased for those users. So maybe something like: Low - 2048 Mid - 4096 High - 8192 Ultra - 8192 Then if a user chooses Custom there should be a slider control to allow it to be set to the value of their choice. Just my two cents. -Harleen _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges ------------------------------------------------------------------------ _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges |
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
