D1233, Adds a way to quickly open/close multiple panels by holding LMB and dragging over the desired panels,
Suggested by @maxon
The decision if the panels are opened or closed is made based on the first Panel the user drags over.
If it is closed, all panels he drags over are opened
(including the first one) if it's opened, they get closed (matching existing drag-toggle logic).
Tooltips for buttons in the Outliner could overlap the Outliner's RMB
menu in some cases (and there's no way to get rid of the tooltip again).
This disables the button's tooltip before creating the menu (as we do it
for the normal RMB menu)
In addition to the unlink icon to clear a value,
When cleared, show an eyedropper to select objects or object-data
(was already available via the EKey).
Normal dragging now uses a precision of 0.01 instead of 0.1, shift+dragging now uses 0.001. (0.1 steps can still be done using ctrl)
Requested by @venomgfx
Using ctrl+LMB to collapse all panels except of the clicked one resulted
in an empty area if done from a view that is scrolled down to some
degree. Resetting the view makes this much better, although it still
doesn't work that well if the area is really small, but I don't think
it's worth over-complicating things here.
"Feature-Request" by @maxon ;)
Our current keymap doesn't give us enough room to make such changes in
the event system. To fix small issues caused by this, we would need to do
drastic changes in Blender's keymaps and internal handling. It was worth
a try, but it didn't work.
I can write down a more descriptive statement in a few days, but for now
I need a break of this stuff.
* Revert 776bfa64a5 and c3dad7953a (some X11 systems are doing
stupid things forcing me to do an extra check that completely breaks the
click type handling on other systems using the slightly changed
implementation from those commits - see T44278)
* Fix sample lines in Compositor+VSE
(And yes, this time I tested on both of my systems to make sure
everything is fine)
Official Documentation:
http://www.blender.org/manual/render/workflows/multiview.html
Implemented Features
====================
Builtin Stereo Camera
* Convergence Mode
* Interocular Distance
* Convergence Distance
* Pivot Mode
Viewport
* Cameras
* Plane
* Volume
Compositor
* View Switch Node
* Image Node Multi-View OpenEXR support
Sequencer
* Image/Movie Strips 'Use Multiview'
UV/Image Editor
* Option to see Multi-View images in Stereo-3D or its individual images
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
I/O
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
Scene Render Views
* Ability to have an arbitrary number of views in the scene
Missing Bits
============
First rule of Multi-View bug report: If something is not working as it should *when Views is off* this is a severe bug, do mention this in the report.
Second rule is, if something works *when Views is off* but doesn't (or crashes) when *Views is on*, this is a important bug. Do mention this in the report.
Everything else is likely small todos, and may wait until we are sure none of the above is happening.
Apart from that there are those known issues:
* Compositor Image Node poorly working for Multi-View OpenEXR
(this was working prefectly before the 'Use Multi-View' functionality)
* Selecting camera from Multi-View when looking from camera is problematic
* Animation Playback (ctrl+F11) doesn't support stereo formats
* Wrong filepath when trying to play back animated scene
* Viewport Rendering doesn't support Multi-View
* Overscan Rendering
* Fullscreen display modes need to warn the user
* Object copy should be aware of views suffix
Acknowledgments
===============
* Francesco Siddi for the help with the original feature specs and design
* Brecht Van Lommel for the original review of the code and design early on
* Blender Foundation for the Development Fund to support the project wrap up
Final patch reviewers:
* Antony Riakiotakis (psy-fi)
* Campbell Barton (ideasman42)
* Julian Eisel (Severin)
* Sergey Sharybin (nazgul)
* Thomas Dinged (dingto)
Code contributors of the original branch in github:
* Alexey Akishin
* Gabriel Caraballo
Design task: T42339
Differential Revision: D840
Initial implementation proposal: T41867
Short description:
With this we can distinguish between holding and tabbing a key. Useful
is this if we want to assign to operators to a single shortcut. If two
operators are assigned to one shortcut, we call this a sticky key.
More info is accessible through the design task and the diff.
A few people that were involved with this:
* Sean Olson for stressing me with this burden ;) - It is his enthusiasm
that pushed me forward to get this done
* Campbell and Antony for the code and design review
* Ton for the design review
* All the other people that gave feedback on the patch and helped to
make this possible
A big "Thank You" for you all!
We now have a specific flag for that, use it! Note that for all 'search menu' buttons,
there is already a similar behavior, so there is no need to force apply butt in this case
anyway, which means in practice this change only has effect in the single place
it is needed currently - file browser dir/file fields.
In this case (dir field), applying button even on partial matches leads code
to ask to create a new dir, which breaks completely the expected behavior of
completion. And we do not need immediate apply at all here.
Note this is the only 'autocomplete' button not using search menu, so this change
does not affect anything else in UI.
Added translation there, also fixed a stupid bug which was leading most internal
operators to have 'dual' i18n_context (default NULL one and default 'Operator' one).
For me, weird characters are drawn if IME is enabled but translation
is not set to a supported language.
Could become an utility function if needed later.
Internal change only,
use UI_BTYPE_SEARCH_MENU with an unlink flag instead.
They are really the same button type, one just happens to have the option to unlink.
This adds back rgb_to_grayscale,
not all color is managed or depends on the current loaded blend file's CM options.
Noted in comments that this is only to be used outside the CM pipeline.
Show World will now influence if world is rendered in opengl rendering.
This is a little undefined according to blender history, since sky used
to always be drawn when offscreen rendering, as if "Only Render" was
ticked. Since if we don't draw sky in that case there's no valid color
really (and using theme colors is not so nice) we just draw transparent
background.
