Changes to edit mode mesh overlays, use hue shift instead of color
fading/darkening for selection mode visual differentiation, and some
theme changes to improve the display of mesh edges and faces with good
selection visibility.
- Removed "edge" toggle from edit mode overlays panel.
- No longer halves the edge and face alpha depending on selection mode.
Half the face alpha in wire-frame mode. For better visibility on most
themes.
Ref !111431
This new member gives access to the current active panel category (i.e.
tab) if supported, and allows to set its value to another defined
category.
While typically add-ons should not force a tab to be the active one,
there are cases where this is a valid and necessary behavior, e.g. in
'Blender App' where an app can add some new tab to the UI and require
them to be active.
Note that there is a ctach here: typically at start time these panel
categories are unknown (enum is empty), since they are validated by
drawing code. So setting them usually needs to be done after initial
startup and drawing of the UI...
Pull Request: https://projects.blender.org/blender/blender/pulls/114070
Regression from 7ec7dac860 (I assume). While the block active state is
relevant during drawing to avoid glitches, it should be ignored during
handling. Explained further in comment.
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
The changes in #112906 (Vulkan: Use Point Shaders When Drawing Points)
broke point sizes for the nodes editor grid on Metal. That PR switched the grid
point drawing code to a shader that sets its own point size, but (at least on Metal)
setting the point size in the shader has no effect unless `GPU_program_point_size(true)`
has been called to allow shader-specified point sizes.
This PR adds the necessary call to `GPU_program_point_size(true)` to fix that problem,
as well as a corresponding "cleanup" call to set it to `false` again.
Pull Request: https://projects.blender.org/blender/blender/pulls/114218
Calling this state "active" has been confusing for a long time for a number of reasons:
- It's not clear that this is essentially a mouse hover state.
- Easy to confuse with "select" state (`UI_SELECT`), both terms are vague.
- Buttons can be "inactive" (`UI_BUT_INACTIVE`) which is totally related to this "active" state.
- Button handling can consider a button as active that doesn't have this flag set (e.g. during text input).
- Active and selected are well established terms in Blender, but they mean a different thing there.
See #112160.
Pull Request: https://projects.blender.org/blender/blender/pulls/114113
The way we handled activation of view item buttons (which are placed
underneath other buttons) would leave that button in an active state,
giving it priority on the next event handler run. Instead we want to
cleanly exit the button after activation, so that the overlapped chevron
icon can be recognized as hovered again.
Also limit this to mouse press events, since otherwise the tree view
item would toggle the collapsed state on both the press and the release
event.
Choosing "Mark as Asset" from the context menu of the ID selector (ID
template) would always use the selected objects instead of the ID set in
the ID selector. This is because since f22e2bab72, multiple selected IDs
have priority over a single active ID (to give batch editing priority),
and the 3D view context exposes both.
Adds variants of the mark and clear asset operators that only work on a
single ID ("id" context member). Context menus for buttons representing
an ID use this instead. Using an operator property resulted in too
complicated code. Plus the poll function would succeed in cases where
the operator wouldn't be able to succeed. Separate operators keep things
simple and more reliable.
Currently, we always prioritize the words in the last section of a search item
(the words that are highlighted). This generally works well, but the situation
is a bit different for link-drag-search, because there the last part is the socket
name, which is usually less descriptive than the node name.
This patch allows us to use different heuristics to select the prioritized section
per search.
Unfortunately, the link-drag-search is not fully consistent with itself. Sometimes
the last group is a socket name, but sometimes it's also the mode of a node
(`Math > Add`). Therefore, the patch currently simply prioritizes all words in the
same instead of prioritizing only the first part. This seems to work much better
than before even if not perfect in all cases yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/113648
Implement the same logic as we do for the active layer, by calling the
corresponding RNA function.
This makes sure all the notifiers and DEG update calls are properly
called. This is needed at least for !113908.
Also adds an undo push step which was missing in main.
Co-authored and reviewed (in real life) by: Julian Eisel <julian@blender.org>
Since the operator can also act on e.g theme colors [and changes to these shouldnt send undo pushes], dont do a general `OPTYPE_UNDO`, but instead be a bit more specific and only do an undo push for buttons with `UI_BUT_UNDO`.
Probably good for LTS.
Pull Request: https://projects.blender.org/blender/blender/pulls/113887
For historic reasons buttons don't use the full button size as draggable
area by default, only a small part of it that is assumed to contain the
icon (e.g. of a label button). This isn't what we want for the big
preview buttons used here, their entire surface should be draggable.
We already have a workaround in place for this historic behavior, so we
can just enable that.
Tested with IBUS on GNOME 45.
Added a capabilities flag to GHOST since support for IME works on
Wayland but not on X11, so runtime detection is needed.
When clicking or dragging a Panel's drag handle, a PANEL_STATE_DRAG
state transition is followed immediately by a PANEL_STATE_ANIMATE
transition. Both transitions start a timer.
Unfortunately, a subtle change introduced in
f3ab698951 meant the first timer would no
longer be destroyed before starting the second one.
The fix is to just reuse the timer if it's already present so that a
second one is not created in the first place.
Pull Request: https://projects.blender.org/blender/blender/pulls/113711
With #113707 text cursor position is set using the character's visible
bounds, so special care is needed for those without bounds like space.
Forgot this also applies to 4.0.
