While missing the break before a default that only breaks isn't
an error, it means adding new cases needs to remember to add the
break for an existing case, changing the default case will also
result in an unintended fall-through.
Also avoid `default:;` and add an explicit break.
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.
Many menus get their labels exported to the .po file, but then are not actually translated in the UI.
Before:
{F13283752}
After:
{F13283750}
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15417
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.
See previous commit for an explanation of what went wrong. Similar to
the fix there, we also have to update the dragged data (e.g. the
data-block) referenced by the button.
Committing separately since this could cause further issues.
In Blender buttons are recreated over redraws, except of the active
button which is kept alive, and replaces the new version of itself in
the new redraw. In order to do that, the button needs to be recognized.
This process of recognizing and matching buttons from different redraws
isn't always bullet-proof. That's okay-ish, but we have to make sure
that the relevant data of the old active button is updated with the
newest data.
Here the matching would go wrong, and the new active button was
recognized as the old active button, which was in fact removed when the
asset was cleared. This patch makes sure the image buffer attached to
the buttons is updated when buttons were recognized as matching.
Note that the dragging will still use the wrong data-block, this will be
fixed in the following commit.
Issue is that the operator acts on the active button, and also uses that in the
poll. So the actually active button would affect the poll of a different
button. For the superimposed icons we need to be able to execute these polls
properly for non-active buttons.
This enables temporarily overriding the active button for lookups via context.
While a bit of a hack it makes sense conceptually.
Reviewed By: Campbell Barton
Maniphest Tasks: T97518
Differential Revision: https://developer.blender.org/D14880
Issue is that the operator acts on the active button, and also uses that in the
poll. So the actually active button would affect the poll of a different
button. For the superimposed icons we need to be able to execute these polls
properly for non-active buttons.
This enables temporarily overriding the active button for lookups via context.
While a bit of a hack it makes sense conceptually.
Reviewed By: Campbell Barton
Maniphest Tasks: T97518
Differential Revision: https://developer.blender.org/D14880
`uiBut` contained a variable that was only used for these hot-key
buttons. This may also help getting rid of the `UI_BUT_IMMEDIATE` flag,
which is also only used for this button type. We are running out of
available bits for flags, so this would be useful.
Continuing the work from 49f088e2d0. Part of T74432.
This reverts the commits 8d9d5da137,
59cd616534 and
98a04ed452.
The commits are causing issues with MSVC, see D14926. I'm working on a
different solution, but that will need some work.
The code to compare buttons from the previous to the current frame, to
see if they match (an thus should keep the same state) was quite
generic, and didn't allow much flexibility/customization. For some
cases this isn't enough, and a more specific comparison is needed. Say
if some buttons don't actually store comparable data themselves, only
via the button context. This was the case in D14653.
It was possible to set context pointers for buttons via the layout, but
not for buttons in places where the layout system wasn't used (where
buttons are placed manually). This is needed for buttons in the
Outliner, see D14653.
