While entering text into input buttons, show on Status Bar "Cancel",
"Confirm", "Select All", "Copy", "Paste". While dragging your mouse on
an a numeric input or slider show "Cancel", "Snap", "Precision".
Pull Request: https://projects.blender.org/blender/blender/pulls/133790
The "Red Alert" color is currently hard-coded, which causes problems in
themes. It also has an Enum value of 0, which precludes using this
value as "unset". We also use Error, Warning, and Info colors that are
part of the Info Editor. This PR moves these out of the Info Editor
and into the "State" part of the theme. And then makes TH_REDALERT use
the TH_ERROR color.
Pull Request: https://projects.blender.org/blender/blender/pulls/131127
Refactor how tooltips are sized, items placed, margins calculated, etc.
Current code has some mistakes that we use kludges to compensate for,
and it doesn't properly consider the font size in calculating margins.
The result shown to users in normal circumstances (changing resolution
scale only) with this PR applied should look identical to current.
Small changes when the text style size is changed. However, this is
mostly to allow later adjustments to padding, which currently _breaks_
when changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/134205
Another case of C-style allocation of non-trivial objects hidden
with casting. To fix, give explicit member defaults to a few of
the UI interaction structs.
This was probably caused by 3ef2ee7c53.
Now `build_layer_group_buttons` doens't need to
select a specific icon anymore. It's handled by the
RNA property.
f0db870822 added support for tree-views to remember state, but only to
remember their custom height for the start. This change makes the scroll
offset be remembered too.
Not remembering the scroll offset can be very annoying in some cases,
e.g. when working with bone collections and changing the active tab in
the properties editor often. In realistic, non-trivial bone collection
set ups this can lead to a lot of repeated scrolling.
Cherry-picked for the 4.4 release since this solves a real usability
issue with trivial changes. Discussed with Thomas and others.
f0db870822 added support for tree-views to remember state, but only to
remember their custom height for the start. This change makes the scroll
offset be remembered too.
Not remembering the scroll offset can be very annoying in some cases,
e.g. when working with bone collections and changing the active tab in
the properties editor often. In realistic, non-trivial bone collection
set ups this can lead to a lot of repeated scrolling.
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
Currently UI code always has to use char pointers when interacting with
the translation system. This makes benefiting from the use C++ strings
and StringRef more difficult. That means we're leaving some type safety
and performance on the table. This PR adds StringRef overloads to the
translation API functions and removes the few calls to `.c_str()` that
are now unnecessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/133887
Yet another remaining case of non-trivial data created with C-style
allocation.
While 4.4 and previous did not exhibit the crash, the invalid code
responsible for this crash is present here as well, and it would be
dangerous not to fix it.
Also use Vector to store menu search items instead of a linked
list. And extend the change into the autocomplete API slightly.
The main benefit is to avoid measuring the length of strings over
and over, but the code also gets simpler.
Caused by 45f231141d.
The problem was that the now non-trivial PointerRNA type was used inside
of a union. To fix that, replace it with a variant, and generally move
the file towards proper C++ patterns. Also replace the memory arena with
a ResourceScope, of change from dynstr to the fmt::memory_buffer, and
use a destructor instead of manually freeing memory.
Pull Request: https://projects.blender.org/blender/blender/pulls/134144
Most event icons shown on the status bar are made up of an icon with
text inside of it. The icon sizing used 2D zoom aspect value, but the
text does not. I had not noticed any use of these outside of Status Bar
so this wasn't tested. Using aspect requires much more precise
measurement and placement of the text using calculated margin values.
Pull Request: https://projects.blender.org/blender/blender/pulls/134146
The general idea is to store an array of (type, data) pointers of all
PointerRNA ancestors of the current one.
This will help solving cases in our code where the owner (or sometimes
even the owner of the owner) of a random PointerRNA needs to be
accessed. Current solution mainly relies on linear search from the owner
ID, which is sub-optimal at best, and may not even be possible in case a
same data is shared between different owners.
This lead to refactoring quite a bit of existing PointerRNA creation code.
At a high level (i.e. expected usages outside of RNA internals):
* Add `RNA_pointer_create_with_parent` and
`RNA_pointer_create_id_subdata` to create RNA pointers with
ancestors info.
* `RNA_id_pointer_create` and `RNA_main_pointer_create` remain
unchanged, as they should never have ancestors currently.
* Add `RNA_pointer_create_from_ancestor` to re-create a RNA pointer
from the nth ancestor of another PointerRNA.
* Add basic python API to access this new ancestors data.
* Update internal RNA/bpy code to handle ancestors generation in most
common generic cases.
- The most verbose change here is for collection code, as the owner of the
collection property is now passed around, to allow collection items to get
a valid ancestors chain.
Internally:
* `PointerRNA` now has an array of `AncestorPointerRNA` data to store
the ancestors.
* `PointerRNA` now has constructors that take care of setting its data for
most usual cases, including handling of the ancestor array data.
* Pointer type refining has been fully factorized into a small utils,
`rna_pointer_refine`, that is now used from all code doing that operation.
* `rna_pointer_inherit_refine` has been replaced by
`rna_pointer_create_with_ancestors` as the core function taking care of
creating pointers with valid ancestors info.
- Its usage outside of `rna_access` has been essentially reduced to custom
collection lookup callbacks.
Implements #122431.
--------------
Some notes:
* The goal of this commit is _not_ to fully cover all cases creating
PointerRNA that should also store the ancestors' chain info. It only
tackles the most generic code paths (in bpyrna and RNA itself mainly).
The remaining 'missing cases' can be tackle later, as needs be.
* Performances seem to be only marginally affected currently.
* Currently `AncestorPointerRNA` only stores PointerRNA-like data.
This will help `StructPathFunc` callbacks to more efficiently generate
an RNA paths when calling e.g. `RNA_path_from_ID_to_property`, but will
not be enough info to build these paths without these callbacks. And some
cases may still remain fuzzy. We'd have to add thinks like a `PropertyRNA`
pointer, and for RNA collection ones, an index and string identifier, to store
a complete unambiguous 'RNA path' info. This is probably not needed, nor
worth the extra processing and memory footprint, for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/122427
Draw a subtle background to make individual parts of each item feel more
connected. E.g. showing loading icons or labels might make it feel like
a bunch of floating icons/labels.
Suggested in #133880.
Pull Request: https://projects.blender.org/blender/blender/pulls/133980
Show a dimmed loading icon while previews are being loaded in a
background thread. The asset shelf and asset/file browsers do this
similarly already.
This is implemented in drawing code, so the loading icon will always
appear when an in-progress preview is being drawn. I experimented with
doing this in `ui_def_but_icon()`, but this won't update correctly with
popups that don't support full refreshing.
This also makes any normal icon that is drawn as preview use the normal
icon size. These icons are usually made for smaller sizes and look very
outblown when displayed at the size of a preview. Yet it's useful to
sometimes pass a normal icon. E.g. for the asset shelf we would already
draw the data-block type icon in place of the preview if there was no
preview to display, and we'd use the normal, smaller size already.
Larger can still be drawn differently.
I don't know of any current cases this would affect though.
Pull Request: https://projects.blender.org/blender/blender/pulls/133880
- Fixes preview flickering on actions like undo/redo in the asset shelf (#93726), not yet for the
file browser.
- Fixes#130861.
Makes the asset shelf use the asynchronous preview loading system of the UI instead of the file
browser one. The issues above where mostly caused by the file browser caching design.
The asset system and its UIs can now manage previews independently of the file browser back-end.
This is another step towards making the asset system independent of the file browser, see
https://developer.blender.org/docs/features/asset_system/fundamentals/from_file_browser_to_asset_system/.
Code to query asset previews through file browser types is removed.
Quite some work was done to prepare the UI preview system for this, to make it on par with the file
browser preview system. E.g.: 9d83061ed4, 315e7e04a8, 5055adc1c0, 16ab6111f7.
Note that the same change should be done to the asset/file browser, but this requires more work.
Pull Request: https://projects.blender.org/blender/blender/pulls/131871
Store the the HUD now stores the index of the region type so when there
are multiple views of the same type (typically quad view), the correct
region is used.
Ref !133935
When displaying keymaps on the Status Bar we prefer to show Confirm and
then Cancel. We have a few places where these are reversed
accidentally. This just makes these consistent with the rest.
Pull Request: https://projects.blender.org/blender/blender/pulls/133947
Inside `wm_operator_finished`, hud_status is set to `CLEAR` after `reset
to default value` operator. `CLEAR` status further calls
`ED_area_type_hud_clear()` to free the hud region. This happens as
`do_register` is false due to missing `OPTYPE_REGISTER` flag.
Ref: !133761
Also correct argument handling when Python arguments were passed in,
which were attempting to handle the following parameters as arguments
instead of skipping them.
