Closing that stuff, nobody seems to have time to spend seriously on that, and it’s far too minor issue to keep it open - else we can add undreads of similar stuff about our UI. If someone has a good idea, feel free to submit a patch.
Closing that stuff, nobody seems to have time to spend seriously on that, and it’s far too minor issue to keep it open - else we can add undreads of similar stuff about our UI. If someone has a good idea, feel free to submit a patch.
This is out of the question.
If we cant get the auto-hide unselected channels behavior approved...
Obs.: My PC have only the Intel Graphics.
Ok, i think i've mistaken the problem, my real problem it's exactally this https://developer.blender.org/T35904
if its ok in other software, why does blender specifically have a problem with this design?
Are you urging it because of a personal preference?
Ok, thanks Antony for giving me details about what is going on. Good to know that it won't stay like that forever.
Closed by commit rB9489205c5c0b.
developer note:
For depth of field question - it's a matter of not having an explicit fstop value for blender internal. All other options are now used from the camera. For cycles we can't reuse the fstop/aperture value because cycles is an add-on from blender side. The thing is that those are real time display specific values, so they go to the view panel. When we support a proper GLSL drawing engine, those will be added in GLSL render properties panel as well to control what goes on during rendering.
Okay, closing then. Thx for investigating @julien :) (afaik you should be able to close as invalid by choosing "Change Status" -> "Invalid" -> "Submit" without any special rights. Not sure why it fails for you)
sorry about this. should apply to master now (not sure why git diff was hating that line...)