| Age | Commit message (Collapse) | Author |
|---|
|
Adds the possibility of having a little number on top of icons.
At the moment this is used for:
* Outliner
* Node Editor bread-crumb
* Node Group node header
For the outliner there is almost no functional change. It is mostly a refactor
to handle the indicators as part of the icon shader instead of the outliner
draw code. (note that this was already recently changed in a5d3b648e3e2).
The difference is that now we use rounded border rectangle instead of
circles, and we can go up to 999 elements.
So for the outliner this shows the number of collapsed elements of a
certain type (e.g., mesh objects inside a collapsed collection).
For the node editors is being used to show the use count for the data-block.
This is important for the node editor, so users know whether the node-group
they are editing (or are about to edit) is used elsewhere. This is
particularly important when the Node Options are hidden, which is the
default for node groups appended from the asset libraries.
---
Note: This can be easily enabled for ID templates which can then be part
of T84669. It just need to call UI_but_icon_indicator_number_set in the
function template_add_button_search_menu.
---
Special thanks Clément Foucault for the help figuring out the shader,
Julian Eisel for the help navigating the UI code, and Pablo Vazquez for
the collaboration in this design solution.
For images showing the result check the Differential Revision.
Differential Revision: https://developer.blender.org/D16284
|
|
Refactor of `BLF_boundbox_foreach_glyph` and simplification of its
usage by only passing translated glyph bounds to callbacks.
See D15765 for more details.
Differential Revision: https://developer.blender.org/D15765
Reviewed by Campbell Barton
|
|
|
|
|
|
The only real difference between `GPU_SHADER_2D_SMOOTH_COLOR` and
`GPU_SHADER_3D_SMOOTH_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_SMOOTH_COLOR' and '3D_SMOOTH_COLOR'
is 'SMOOTH_COLOR', but the old names still work for backward
compatibility.
|
|
The only real difference between `GPU_SHADER_2D_UNIFORM_COLOR` and
`GPU_SHADER_3D_UNIFORM_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_UNIFORM_COLOR'' and '3D_UNIFORM_COLOR'
is 'UNIFORM_COLOR', but the old names still work for backward
compatibility.
Differential Revision: https://developer.blender.org/D15836
|
|
The offending line was attempting to artificially add width to the
length of the string in order to "avoid ellipsing text that nearly
fits". The line doesn't actually appear to do anything beneficial, and
it causes the nasty text bug.
Old:
{F13029695}
New:
{F13327308}
Reviewed By: campbellbarton
Ref D15585
|
|
No user visible changes expected.
Merges the tree row and grid tile button types, which were mostly doing
the same things. The idea is that there is a button type for
highlighting, as well as supporting general view item features (e.g.
renaming, drag/drop, etc.). So instead there is a view item button type
now. Also ports view item features like renaming, custom context menus,
drag controllers and drop controllers to `ui::AbstractViewItem` (the new
base class for all view items).
This should be quite an improvement because:
- Merges code that was duplicated over view items.
- Mentioned features (renaming, drag & drop, ...) are much easier to
implement in new view types now. Most of it comes "for free".
- Further features will immediately become availalbe to all views (e.g.
selection).
- Simplifies APIs, there don't have to be functions for individual view
item types anymore.
- View item classes are split and thus less overwhelming visually.
- View item buttons now share all code (drawing, handling, etc.)
- We're soon running out of available button types, this commit merges
two into one.
I was hoping I could do this in multiple smaller commits, but things
were quite intertwined so that would've taken quite some effort.
|
|
Part of T98560.
See https://wiki.blender.org/wiki/Source/Interface/Views
Adds all the basic functionality needed for grid views. They display
items in a grid of rows and columns, typically with a preview image and
a label underneath. Think of the main region in the Asset Browser.
Current features:
- Active item
- Notifier listening (also added this to the tree view)
- Performance: Skip adding buttons that are not scrolled into view
(solves performance problems for big asset libraries, for example).
- Custom item size
- Preview items (items that draw a preview with a label underneath)
- Margins between items scale so the entire region width is filled with
column, rather than leaving a big empty block at the right if there's
not enough space for another column (like the File and current Asset
Browser does it).
- "Data-View Item" theme colors. Not shown in the UI yet.
No user visible changes expected since the grid views aren't used for
anything yet.
This was developed as part of a rewrite of the Asset Browser UI
(`asset-browser-grid-view` branch), see T95653. There's no reason to
keep this part in a branch, continuing development in master makes
things easier.
Grid and tree views have a lot of very similar code, so I'm planning to
unify them to a degree. I kept things separate for the start to first
find out how much and what exactly makes sense to override.
|
|
Moves code for managing dragging data from buttons to a separate file.
This way all this closely related code is in one location, making it
easier to see how it all relates, and easier to find.
|
|
Was using the wrong bitfield in flag comparisons for the drawing code.
The input handling wouldn't be affected. Own mistake in 0d7311345295.
|
|
Apparently this was used for progressbar drawing, which doesn't share
the code anymore.
|
|
Previously we would pass button state and draw information to widget
draw callbacks in a rather hacky way. Some specific flags from
`uiBut.flag` were masked out, so their bits could be reused for also
passing `uiBut.drawflag` in the same int. Instead this commit introduces
a state-info struct that can properly hold all the relevant data.
This has the advantage that it's now easier to introduce new state data
that needs to be accessible in the widget callbacks. Since we are
running out of button flags, we plan to reorganize button flags, and
split them up into multiple bitfields. In the widget drawing code, this
would have been a hassle earlier.
Also had to add a new widget callback to draw blocks as widgets (popup
backgrounds), since that would pass block flags where we would usually
pass button flags. This wasn't nice, now it's separated more clearly.
|
|
This flag was used to activate the hotkey input buttons (e.g. for
"Assign Shortcut") when opened in a popup. Since this was added, other
more generalized ways of getting this same behavior were implemented.
Had to tweak the hotkey button event handling a bit, but it seems to
behave exactly as before now.
|
|
This reverts the commits 8d9d5da13706b668b9bd0d631e00c9b00b73f3ea,
59cd616534b46ab85b4324a0886bd9eb8876a48b and
98a04ed4524234b1840dc039c2f356db5ac57f26.
The commits are causing issues with MSVC, see D14926. I'm working on a
different solution, but that will need some work.
|
|
Needed after 98a04ed45242.
|
|
Internally many offsets for BLF were integers but exposed as floats,
since these are used in pixel-space, many callers were converging them
back to integers. Simplify logic by using ints.
|
|
The variable `ofs` in `widget_numslider` was referring to the radius.
`rad` is more clear and consistent with the other widget functions.
|
|
Keep the value slider from clipping through rounded corners for
low values by ensuring the width of the slider rectangle is at least
twice the corner radius.
Reviewed By: Hans Goudey
Differential Revision: https://developer.blender.org/D11474
|
|
backend.
- Metal uniform array compatibility in DRW module.
- Guard OpenGL-specific workarounds and flushes behind GPU_type_matches_ex API guard. Add further render boundaries for render paths called outside of the main loop.
Authored by Apple: Michael Parkin-White
Ref: T96261
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D14438
|
|
All the buttons in the Library Overrides display mode would be shown in cyan,
indicating that they are library overrides. Given that this is solely what this
display mode is about, the indicator is just redundant, confusing (why are the
buttons purple?) and looks weird.
Part of T95802.
Reviewed by: Bastien Montagne
Differential Revision: https://developer.blender.org/D14416
|
|
Previously the labels and values in number fields and value sliders
used different padding for the text. This looks weird when they are
placed underneath each other in a column and, as noted by a comment
in the code of `widget_numslider`, they are actually meant to be
aligned.
This patch fixes that by using the same padding that is used for the
number field for the value slider, as well. This also has the benefit,
that the labels of the value sliders don't shift anymore when adjusting
the corner roundness.
Differential Revision: https://developer.blender.org/D14091
|
|
Also move eDupli_ID_Flags doc-string to it's declaration.
|
|
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
Includes unwanted changes
This reverts commit 46e049d0ce2bce2f53ddc41a0dbbea2969d00a5d.
|
|
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
|
|
Reverted because the commit removes a lot of commits.
This reverts commit a2c1c368af48644fa8995ecbe7138cc0d7900c30.
|
|
This patch implements the vector types (i.e:float2) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others we
currently don't have (uintX, intX). All these variations were asking
for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector functions
should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the BLI_(float|double|mpq)(2|3|4).hh is a bit of a
let down. Most clases are incomplete, out of sync with each others with
different codestyles, and some functions that should be static are not
(i.e: float3::reflect()).
Upsides:
- Still support .x, .y, .z, .w for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types and
can be restricted to certain types. Also template specialization let us
define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance is
the same.
Downsides:
- Might impact debugability. Though I would arge that the bugs are rarelly
caused by the vector class itself (since the operations are quite trivial)
but by the type conversions.
- Might impact compile time. I did not saw a significant impact since the
usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length. For
instance, one can't call len_squared_v3v3 in math::length_squared() and
call it a day.
- Type cast does not work with the template version of the math:: vector
functions. Meaning you need to manually cast float * and (float *)[3] to
float3 for the function calls.
i.e: math::distance_squared(float3(nearest.co), positions[i]);
- Some parts might loose in readability:
float3::dot(v1.normalized(), v2.normalized())
becoming
math::dot(math::normalize(v1), math::normalize(v2))
But I propose, when appropriate, to use
using namespace blender::math; on function local or file scope to
increase readability. dot(normalize(v1), normalize(v2))
Consideration:
- Include back .length() method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement.
It felt like too much for what we need and would be difficult to
extend / modify to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches delaunay_2d.cc and the intersection code. I would like to
know @Howard Trickey (howardt) opinion on the matter.
- The noexcept on the copy constructor of mpq(2|3) is being removed.
But according to @Jacques Lucke (JacquesLucke) it is not a real problem
for now.
I would like to give a huge thanks to @Jacques Lucke (JacquesLucke) who
helped during this and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: http://developer.blender.org/D13791
|
|
Add maximum string length argument to UI_fontstyle_draw to reduce usage
of BLF_DRAW_STR_DUMMY_MAX. Reorders arguments to UI_fontstyle_draw_ex
See D13794 for more details.
Differential Revision: https://developer.blender.org/D13794
Reviewed by Campbell Barton
|
|
Reduction of the number of uses of the define BLF_DRAW_STR_DUMMY_MAX
by using actual sizes of static character arrays.
See D13793 for more details.
Differential Revision: https://developer.blender.org/D13793
Reviewed by Campbell Barton
|
|
Also add groups in some files.
|
|
Ref T92709
|
|
The small circle used to choose the hue/saturation and value in the
color widget was drawn with a fixed screen space size. Now scale the
circle used as cursor in the color widget based on the zoom. This
could have been part of a9642f8d6130 but the implementation is
different.
Based on a fix provided by Erik Abrahamsson
Differential Revision: https://developer.blender.org/D13444
|
|
|
|
|
|
Don't use the side padding for menu item contents when displaying
previews or icons in a row or grid layout. This can cause problems for
the preview drawing and doesn't make sense to draw there anyway.
This not only fixes the mentioned issue, but also too small heighlight
for the collection color tag in the Outliner context menu.
Alternative to and similar to D13125.
|
|
|
|
This commit improves the scaling of some ui widgets when
zooming by making the radius of the rounded corners
dependent on the element's zoom level.
Needed to fix T92278 without padding issues, see D13125.
Reviewed By: Hans Goudey, Julian Eisel
Differential Revision: https://developer.blender.org/D12842
|
|
This patch removes a bunch of specific code for drawing the spreadsheet
data set region, which was an overly specific solution for a generic UI.
Nowadays, the UI tree view API used for asset browser catalogs is a much
better way to implement this behavior.
To make this possible, the tree view API is extended in a few ways.
Collapsibility can now be turned off, and whether an item should
be active is moved to a separate virtual function.
The only visual change is that the items are now drawn in a box,
just like the asset catalog.
Differential Revision: https://developer.blender.org/D13198
|
|
In the tools tab, the tool icon would be offset when it intersected
the bottom of the editor. With some screen resolutions, the icons on
the left side of the editor would also move when intersecting the
bottom of the editor. This happened because of the truncation in
the implicit conversion from float to int. Instead, use explicit
conversion functions.
Differential Revision: https://developer.blender.org/D11097
|
|
Simply removing the check for `UI_STATE_TEXT_INPUT` makes it inherit
the "List Item" User Interface theme settings. This patch changes the
default theme to match the colors of text input fields.
#### Master
{F11680556, size=full}
#### This patch
{F11680557, size=full}
All the included commmunity themes seem to work well (only Deep Grey might
need more contrast but that's a different patch).
Related reports: T92720
Reviewed By: #user_interface, Severin
Maniphest Tasks: T92720
Differential Revision: https://developer.blender.org/D13073
|
|
This patch makes `widget_nodesocket` base the size of the drawn
socket icon on the rectangle that’s passed in to allow it to scale
with the rest of the interface.
Differential Revision: https://developer.blender.org/D11734
|
|
|
|
While c7d94a7827a5be9343eea22a9638bb059f185206 exposed this bug,
this was caused by a discrepancy in padding where labels would
have additional padding when drawing without emboss.
The padding made widget drawing behave as if the text took up more
room causing it to be clipped.
Now labels are considered the same width with/without emboss.
|
|
|
|
This commit removes the constant padding around to the left and
right of the curve widget. The padding worked in screen space and
didn't take UI scale/zoom into account. This makes the curve widget
consistent with the more recently added curve profile widget used
for bevel profiles.
Differential Revision: https://developer.blender.org/D12883
|
|
Menu items ignore the roundness setting since they spread left to right.
This patch makes it so menu items use the theme preference instead of
hardcoded square corners. Providing more flexibility to themes.
All built-in and included themes already have this set so no need to update them. For the default themes (Dark/Light) roundness is 0.4.
{F10950727, size=full}
The motivations behind this change are:
* To be more consistent with other widgets.
* Improve themes flexibility.
* Match padding with other elements that have like the Search field:
{F10950746, size=full}
Reviewed By: #user_interface, Severin
Differential Revision: https://developer.blender.org/D12813
|
|
If the operator poll of a superimposed icon returned `false`, the
superimposed icon would just draw normally and fail silently. Instead it
will now be drawn grayed out, plus the tooltip of the icon can show the
usual "disabled hint" (a hint explaining why the button is disabled).
|
|
|
