Each space had separate operators, duplicating logic.
Use RNA properties instead so adding the ability to toggle other
region types (floating redo region for eg) doesn't need to have an
extra operator per space type.
It's also nicer to show a check-box for something which can be toggled.
* It can be hidden by dragging it up/down.
* It can be at the top or bottom, independent of the header.
* It uses the color theme from the header.
* It does not change its color, when the area becomes active.
Currently, it is used in the text editor to display the file path.
Differential Revision: https://developer.blender.org/D4601
* When resizing sidebars, don't collapse when the region becomes too big but
instead clamp the region size to the available space.
* Fix clicking the tab to expand sidebars no working if the sidebar is too
wide to fit. Instead make it less wide so it does fit.
* Fix incorrect limit on tool properties region height, for example in the
file browser.
Differential Revision: https://developer.blender.org/D4611
Steps to reproduce were:
* Maximize area (Shift+Spacebar in 2.7, Ctrl+Spacebar in 2.8)
* Open temp file browser (Ctrl+O)
* Cancel file browser (Esc) - should return to previous full-screen
* Press "Return to Previous" button
The previously maximized area would turn into a file-browser.
Note that the issue will still happen when opening old files saved while
in maximized area full-screen.
When the line width was larger than the UI scale, there was not enough
space for thicker widget outlines to draw properly. Now widgets are made
a little larger to accommodate the thicker outlines.
Differential Revision: https://developer.blender.org/D4368
Add getter callback support for 'WM_HANDLER_TYPE_KEYMAP' type handlers
this is needed for key-maps which change based on the active tool.
Replaces 'sneaky_handler' hack which temporarily inserted a handler.
Is available when doing "View -> Show Metadata". Will draw all the
fields which are not part of the stamp at the bottom of the image.
Couple of hand-picked fields are ignored, since those are not very
useful to be seen.
Aimed to ease review of rendered shots.
Reviewers: brecht
Reviewed By: brecht
Subscribers: fsiddi
Differential Revision: https://developer.blender.org/D4316
This is a request by the studio here to make it possible to see how
many samples were used to render a specific shot or a frame. It is a
bit more tricky than simply stamping number of samples from a scene
since rendering is happening in multiple ranges of samples.
This change makes it so Cycles saves configured number of samples for
the specific view layer, and also stores start sample and number of
samples when rendering only a subrange of all samples.
The format used is "cycles.<view_layer_name>.><field>", which allows
to have information about all layers in a multi-layer EXR file.
Ideally we can store simplified "cycles.<field>" if we know that there
is only one render layer in the file, but detecting this is somewhat
tricky since Cycles operates on an evaluated scene which always have
single view layer.
The metadata is shown in the Metadata panels for clip, image and
sequencer spaces.
Example screenshot which shows the metadata:
{F6527727}
Reviewers: brecht
Reviewed By: brecht
Subscribers: fsiddi
Differential Revision: https://developer.blender.org/D4311
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
* Add threshold for minimum amount of mouse movement for dragging to
get activated.
* Limit angles at which dragging is considered an action, do nothing if
mouse does not clearly move up/down/left/right.
* Increase action zone size vertically.
Differential Revision: https://developer.blender.org/D4227
There was no documentation at all, some very bad practices (like using
G.debug_value > 0 as some sort of global debug print switch), and even
an overlapping use of '1' value...
Also, python setter did not check for valid range (since this is a
short, not an int).
(Part 1 was 00963afc14978b)
Does the following changes visible to users:
* Use panels and sub-panels for more structured & logical grouping
* Re-organized options more logically than before (see images in D4148)
* Use flow layout (single column by default).
* New layout uses horizontal margin if there's enough space.
* Change size of Preferences window to suit new layout.
* Move keymap related options from "Input" into own section.
* Own, left-bottom aligned region for Save Preferences button.
* Adjustments of names, tooltips & icons.
* Move buttons from header into the main region (except editor switch).
* Hide Preferences header when opened in temporary window.
* Use full area width for header.
* Don't use slider but regular number widget for UI scale.
* Gray out animation player path option if player isn't "Custom"
Internal changes:
* Rearrange RNA properties to match changed UI structure.
* Introduces new "EXECUTE" region type, see reasoning in D3982.
* Changes to panel layout and AZone code for dynamic panel region.
* Bumps subversion and does versioning for new regions.
RNA changes are documented in the release notes:
https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Python_API/Preferences_API
Design & implementation mostly done by @billreynish and myself.
I recommend checking out the screenshots posted by William:
https://developer.blender.org/D4148#93787
Reviewed By: brecht
Maniphest Tasks: T54115
Differential Revision: https://developer.blender.org/D4148
ARegion.sizex/y should never have DPI factor applied. For regular panel
regions, DPI will be applied in region_rect_recursive already, causing
it to be applied twice when region size is set dynamically (= based on
content dimensions).
The '+' widget to show a hidden region came too close to overlapping
the viewport navigation gizmo and text editor text.
Reduce size and use an arrow icon.
D4110 by @gnastacast
No functional changes, but it makes all the coordinates more consistent
(going from small to larger values). It helps debugging in the future
to be able to rule out vertex order as a culprit.
This will probably be a temporary solution to fill empty space, for until we
have a search button there. Hence, I made this optional using a compile flag.
Moves the Properties editor context switching to a vertical tabs region.
Design Task: T54951
Differential Revison: D3840
The tabs are regular widgets, unlike the 'old' toolshelf tabs. This means they
give mouse hover feedback, have tooltips, support the right-click menu, etc.
Also, when vertical screen space gets tight, the tabs can be scrolled, they
don't shrink like the toolshelf ones.
The tab region is slightly larger than the header. The tabs are scaled up
accordingly. This makes them nicely readable.
The header is quite empty now. As shown in T54951, we wanted to have a search
button there. This should be added next.
Implementation Notes:
* Added a new region type, RGN_TYPE_NAVIGATION.
* Having the tabs in a separate region allows scrolling of the tab-bar, unlike
the toolshelf tabs. We might want to remove the scrollbars though.
* Added a new region flag RGN_FLAG_PREFSIZE_OR_HIDDEN, to ensure the tab region
is either hidden or has a fixed size.
* Added some additional flags to support fine-tuning the layout in panel and
layout code.
* Bumps subversion.
