Drop undo/redo #11
Draft
Drop undo/redo #11
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adopted from bevyengine#20507. Bumps crate-ci/typos from 1.34.0 to 1.35.3. --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Objective - Fix bevyengine#19679 ## Solution - fix lints
# Objective
Our `From<Rot2>` implementation for `Mat2` looks like this:
```rust
impl From<Rot2> for Mat2 {
/// Creates a [`Mat2`] rotation matrix from a [`Rot2`].
fn from(rot: Rot2) -> Self {
Mat2::from_cols_array(&[rot.cos, -rot.sin, rot.sin, rot.cos])
}
}
```
The resulting matrix looks like this:
```text
[ cos, sin ]
[ -sin, cos ]
```
Cool! Oh wait -- *checks
[notes](https://en.wikipedia.org/wiki/Rotation_matrix)* -- the correct
matrix is this?
```text
[ cos, -sin ]
[ sin, cos ]
```
Oops!
## Solution
Fix the matrix signs. Now my joint's axes are oriented correctly :)
## Testing
Added a simple regression test. Fails before the change, passes after.
…0519) # Objective Seems like not enough users and devs are aware of this component or what it's for, maybe a more descriptive name will help. ## Solution Rename `ComputedNodeTarget` to `ComputedUiTargetCamera`. New name chosen because the component's value is derived from `UiTargetCamera`.
…ble (bevyengine#20466) # Objective It is currently a little unclear how to use uniform buffers in compute shaders. The other examples of uniform buffers in the Bevy examples and codebase either are built on Materials or use `DynamicUniformBuffer`s created from a `ViewNode`. Neither of these are a great fit for use in a compute shader. ## Solution Update the compute shader example to pass a uniform buffer to the shader that determines the color for alive cells. ## Discussion Topics - Is this the right way to pass this data to the shader? - Should we be encouraging use of uniform buffers in compute shaders at all? Some in the community prefer the ergonomics of storage buffers in most (all?) compute shader cases. Do we want to push users to use storage buffers instead? - I took the idea to use color as the input from IceSentry on Discord, but this did require me to change the texture format to support non-red colors. Does this undermine the goals of the shader example? Is this the wrong texture format? ## Testing - Did you test these changes? If so, how? - The changes were manually validated with a number of different `LinearRgba` values for `alive_color` - Are there any parts that need more testing? - How can other people (reviewers) test your changes? Is there anything specific they need to know? - ` cargo run --example compute_shader_game_of_life` - Color can be set using `alive_color` property on `GameOfLifeUniforms` - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? - Manually validated on Windows and WASM (WebGPU) targets - WASM WebGL2 doesn't appear to support textures in compute shaders --- ## Showcase <img width="1602" height="939" alt="image" src="https://github.com/user-attachments/assets/9a535617-a179-4f20-b686-596899f11d18" /> --------- Co-authored-by: dontgetfoundout <inflatedego@gmail.com>
# Objective bevyengine#20522 counts as a breaklng change, but didn't have a migration guide. ## Solution Add the migration guide :D
…yengine#20506) # Objective This assertion fails when called inside finish or cleanup: ```rs assert_eq!( app.is_plugin_added::<ImagePlugin>(), app.get_added_plugins::<ImagePlugin>().len() > 0 ); ``` ## Solution - Do the hokey pokey one plugin at a time - swap_remove to stay O(1), then push and swap back to preserve plugin order ## Testing - Someone should write unit tests for this and probably document that it hokey pokeys, although i dont think anyone will `get_added_plugins<Self>` because you have a `self` param in finish and cleanup anyways.
# Objective - title ## Solution - use the system set - fix the InheritWeights system set naming convention while we're at it - move transparent image handle uuid to bevy_image - move ImagePlugin to bevy_image to initialize transparent image etc - rename remaining plugin to TexturePlugin - ok technically its a dev-dep still - sorry this could be split up better ## Testing
# Objective Adaptor curves have `PhantomData` fields that are included when serializing. ## Solution Add `serde(skip)` to `PhantomData` fields. ## Testing Everything still compiles, the curves still work, and the `_phantom: ()` fields are no longer emitted.
# Objective The name of this system is really non-specific and it could be doing anything. ## Solution Rename `update_ui_context_system` to `propagate_ui_target_cameras`.
# Objective - Fixes bevyengine#14578 ## Solution - Use `textureSampleLevel` instead of `textureSample` (bevyengine#11893)
…engine#20521) # Objective The docs comments for `UiCameraMap` and `UiCameraMapper` are out of date and incorrectly refer to a default camera and `UiTargetCamera` that aren't present. ## Solution Update the doc comments
# Objective Fixes bevyengine#18993. ## Solution I've done my best to synthesize and carefully word the discussion in the linked issue. That said, this is not my domain, so critique is very welcome.
# Objective - As discussed in bevyengine#20433 (comment), these probably belong in `PostUpdate` to ensure that spawned objects in `Update` have the correct values immediately without the need for ordering. - Finishes and closes bevyengine#20356. ## Solution - Change the schedule from `Update` to `PostUpdate` ## Testing - I'm not sure exactly how to test this effectively: @viridia, can you advise?
…ne#19355) # Objective Fixes a crash when running with CPU rendered lavapipe, which could be fixed by manually setting ```rs app.sub_app_mut(RenderApp).insert_resource(GpuPreprocessingSupport { max_supported_mode: GpuPreprocessingMode::None, }); ``` ```rs wgpu error: Validation Error Caused by: In Device::create_compute_pipeline, label = 'downsample depth first phase pipeline' Internal error: WGSL `textureLoad` from depth textures is not supported in GLSL Encountered a panic in system `bevy_render::render_resource::pipeline_cache::PipelineCache::process_pipeline_queue_system` ``` ## Solution Automatically disable gpu preprocessing when running with the GL backend. ## Testing I ran the breakout example through `libTAS` which (among other things) forces software rendering. Running breakout with just ```rs .add_plugins(DefaultPlugins.set(RenderPlugin { render_creation: bevy_render::settings::RenderCreation::Automatic(WgpuSettings { backends: Some(Backends::GL), ..default() }), ..default() })) ``` fails with `gpu_core::device::global: surface configuration failed: incompatible window kind` so gl isn't fully supported yet, but it's a step in the right direction.
This is the bikeshed of all time, but I needed to bring this up before it became a breaking change. In my opinion, `Allow<Disabled>` sounds better than `Allows<Disabled>`. I don't think there's a 1-to-1 comparison in other query keywords yet, but there's the hypothetical `Expect` in [the discussion on bevyengine#19489](bevyengine#19489 (comment)), as opposed to `Expects`. `Allows` hasn't been in a release yet, so it's free to change until 0.17 comes out.
# Objective Add constructor functions for each variant of `Val` Fixes bevyengine#15937 ## Solution Add constructor functions for each variant of `Val`. # Doc comments feel a bit clumsy, not sure how to rephrase them, maybe doesn't matter. Perhaps it's not necessary to repeat the enum documentation either, not sure.
# Objective Add doc comments for the fields and methods belonging to `ComputedUiTargetCamera`. ## Solution Add the doc comments.
# Objective Simplify UI tests by replacing `camera_system` in the test schedule. Should remove the need for the `bevy_render` dependency in bevyengine#20502. ## Solution New `update_cameras_test_system` system that updates each `Camera`'s render target info directly for UI tests without needing the extra dependencies and resource inits. ## Testing Run the tests.
…`. (bevyengine#20543) # Objective - Make sure future changes like bevyengine#20407 maintains our intended before. ## Solution - Add a test! - If we ever decide to change this policy (e.g., run startup stuff first), it's easy enough to change the test. ## Testing - Add a test
# Objective Many math primitives require const generics and thus are not constructable at runtime and also not meshable. While the use of const generics is theoretically more performant, it makes them very difficult to interact with in a generic way, particularly in relationship to mesh construction. For example, a ui that would allow selecting a primitive in order to create a mesh. ## Solution Make them alloc and meshable. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective - Correct the formula in the documentation of SmoothStep "Fixes bevyengine#20454". ## Solution - Update the documented formula ## Testing - Did you test these changes? If so, how? No - Are there any parts that need more testing? No - How can other people (reviewers) test your changes? Is there anything specific they need to know? No testing necessary - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? No testing necessary
# Objective - make comment less confusing ## Solution - yeet confusing part
# Objective The example in the documentation of `TextSpan` is wrong. It correctly states that `Text` or `Text2d` must be present but won't use either leading to no rendering. It also states that `TextLayout`, `TextFont` and `TextColor` of the first span will all set default values for the children, which is not true. `TextLayout` determines the layout of the block but each node has its own `TextFont` and `TextColor` which are both required components of `TextSpan`. The type description is not clear about `Text` or `Text2d` being mandatory. ## Solution - Fix the documentation
# Objective - If an entity command is sent targeting a despawned entity, that command will error, and then panic by default. - This occurs even if the entity exists at the time the command was sent. - This can cause surprising panics when working with observers that depend on each other, especially when using entity events that cause entities to be despawned. - Closes bevyengine#19623. ## Solution As outlined in bevyengine#19623, this behavior isn't exactly a bug, although it is surprising. When you attempt to trigger an observer for an entity that doesn't exist, Bevy should give you some indication that something has gone wrong! The standard mechanism we have for doing so is to return an error in the command, which is passed to the default error handler. By default, this panics, reproducing the problem reported in bevyengine#19623. Unfortunately, the error reporting was so bad that neither the OP nor the contributors could quickly isolate the problem and tell them what they should be doing differently. The actual solution is both standard to the rest of Bevy and quite simple: just queue the command in a way that makes the error not panic. We should explain that! I've added commentary to that effect on both `EntityCommands::trigger/trigger_targets` and the error message returned. ## Testing I've added a new test demonstrating the fix for this failure mode. Swapping that test to plain `.trigger` fixes the problem. --------- Co-authored-by: JaySpruce <jsprucebruce@gmail.com>
# Objective - Sometimes when I see bug reports, I want to know if it's a specific combination of features that is causing the issue. --------- Co-authored-by: JMS55 <47158642+JMS55@users.noreply.github.com>
# Objective - Fixes bevyengine#20499 ## Solution - Added `EntityCursor` re-insertion in `set_*_colors` functions with corresponding cursor shape depending on whether the widget is disabled or not. ## Testing - Tested the changes in the `feathers` example.
…e#20564) # Objective - Make using SystemState as a ExclusiveSystemParam more discoverable ## Solution - add an example of using it with an exclusive system to the SystemState docs. <img width="1225" height="375" alt="image" src="https://github.com/user-attachments/assets/031d458a-f67c-448e-9ad9-57501f5b2531" />
# Objective
- Since ```Vec<Handle<A>>``` and ```Vec<UntypedHandle>``` implement
```VisitAssetDependencies``` users might expect ```[Handle<A>; N]``` and
```[UntypedHandle; N]``` to also implement ```VisitAssetDependencies```,
but this is currently not the case.
- The ```#[dependency]``` attribute from the ```Asset``` derive macro
should work with an implementation.
## Solution
Implement ```VisitAssetDependencies``` for ```[Handle<A>; N]``` and
```[UntypedHandle; N]```. The implementations are based on the
corresponding ones for Vec.
## Testing
A test for compatibility with the derive macros was added for
```[Handle<A>; N]``` and ```[UntypedHandle; N]```.
---
## Showcase
Before:
```rust
// Can't use the Asset macro with a custom VisitAssetDependencies impl
#[derive(TypePath)]
struct MyAsset {
images: [Handle<Image>; 5],
}
impl VisitAssetDependencies for MyAsset {
fn visit_dependencies(&self, visit: &mut impl FnMut(UntypedAssetId)) {
for image in &self.images {
visit(image.id().untyped());
}
}
}
impl Asset for MyAsset {}
```
After:
```rust
#[derive(Asset, TypePath)]
struct MyAsset {
#[dependency]
images: [Handle<Image>; 5],
}
```
# Objective - We should stop this madness <img width="125" height="100" alt="Screenshot 2025-09-03 at 01 36 56" src="https://github.com/user-attachments/assets/85bc38a8-b062-4692-9f22-a1021cc41ad2" /> ## Solution - Sort
# Objective I want to use `HashSet<Handle<T>>` over `Vec<Handle<T>>` for fast contains checking. Partially adopts bevyengine#14162: I only need the `HashSet` implementation at the moment. ## Solution Implement `VisitAssetDependencies` for `HashSet`. ## Testing Added derive macro compatibility tests for `HashSet`.
# Objective - Improve the Solari example to showcase the feature's strengths better (emissive meshes, dynamic lighting conditions) I used the SEED PicaPica project, which besides being a great fit and compact, is pretty cool as it's also was one of the first demos for realtime raytracing :) ## Showcase <img width="3206" height="1875" alt="image" src="https://github.com/user-attachments/assets/be93211e-d2d0-4c7d-8f1d-1aa960087d9a" />
…#20841) # Objective - Both ```Sprite``` and ```ImageNode``` have a 'canonical' handle, but neither struct currently implements ```AsAssetId```. Hence they do not work with the ```AssetChanged<A>``` filter. This is unfortunate, as the ability to do some logic when the ```Image``` underlying a ```Sprite``` or ```ImageNode``` changes is likely useful. - Address bevyengine#20635 ## Solution - Implement ```AsAssetId``` for ```Sprite``` and ```ImageNode```. ```Asset = Image``` for both. ## Reservations - Both ```Sprite``` and ```ImageNode``` have a ```texture_atlas: Option<TextureAtlas>``` field. ```TextureAtlas``` contains a ```Handle<TextureAtlasLayout>```, and it is feasible to imagine a user wanting to query for changes regarding this asset. Since ```AsAssetId``` only works for a single asset type, the choice must be made as to support either ```Image``` or ```TextureAtlas``` , or possibly avoiding an implementation for now. That said, ```Image``` is the most obvious choice. --- ## Showcase Now users can filter for ```Sprite``` components whose underlying ```Image``` asset has changed. ```rust fn query_sprites_with_changed_images(query: Query<&Sprite, AssetChanged<Sprite>>) { for sprite in &query { println!("some logic with the changed image"); } } ```
It can occasionally be useful to have cameras that *only* render prepasses such as depth. Other game engines such as Unity support this feature by allowing a depth-only render target to be assigned to a camera. Bevy, however, has no easy mechanism for this. (Creating an `ShadowView` in the render app doesn't work, because various places in rendering assume that shadow views are associated with lights.) This patch fixes the problem by introducing a new type of `RenderTarget`, `RenderTarget::None`. Cameras with no render target will skip the main opaque and transparent render passes, but any prepasses on such cameras will still occur. Adding a `DepthPrepass` to such a camera enables depth-only cameras, with maximum efficiency as the fragment shader won't exist and no color buffer will be bound. Note that, when no render target is specified, the physical size of the viewport must be explicitly specified, as Bevy has no other mechanism to determine it. A new example, `render_depth_to_texture`, has been added, containing a rotating cube and a depth-only camera orbiting it. The depth texture that the camera produces is rendered onto a plane using a custom shader. (NB: In such scenarios, the depth texture must be copied from the camera to a custom image due to (a) the `wgpu` limitation that a depth texture can't be both a render target and bindable as a texture and (b) the fact that Bevy depth textures are managed by Bevy itself and exposed only to the render world. The example uses a custom render node to perform the copy.) The depth-only camera can be moved using the WASD keys. <img width="2564" height="1500" alt="Screenshot 2025-09-02 080508" src="https://github.com/user-attachments/assets/415e7f4d-393d-4be3-b569-829c06901078" />
# Objective Shows the call to init_state in the State docs. ## Solution Shows the call to init_state in the State docs. ## Testing Docs change
…20842) # Objective - While trying to update `bevy_flair` to bevy 0.17 I found that new gradient components, `BorderGradient` and `BackgroundGradient` were missing `#[reflect(Default)]` ## Solution - Add missing reflect data types to `BorderGradient` and `BackgroundGradient` . ## Testing - `cargo ci`: OK
# Objective I wrote these tests for fixing bevyengine#20670 but bevyengine#20698 got to it first.
# Objective Naming of this `default_camera_view` variable in the `bevy_ui_render::lib` module is misleading. It's not a default anything, I think it was named this way because iirc `UiCameraView` was called `DefaultCameraView` (or something like that) a few versions ago. ## Solution Rename `default_camera_view` to `ui_camera_view`.
# Objective Fixes bevyengine#20854 ## Solution Query for the next color on span changes before queuing the next glyph. ## Testing Added two more cases to `testbed_ui`'s text example, the three lines of coloured text should all look identical: ```cargo run --example testbed_ui``` <img width="487" height="234" alt="text-color" src="https://github.com/user-attachments/assets/78d10141-9b2f-4a57-9b64-eda62da46db5" />
…amples) (bevyengine#20851) # Objective While `desktop_app` is arguably correct for a UI focused example, in practice, it doesn't work well currently. The intermittent updates lead to "buggy" behavior: partial loads, stutters and so on. We should fix those problems, and make the desktop_app setting more useful! But "last minute before release" is not a good time to do so. And simply leaving these apparent bugs in our showcase of the new UI toolkit will both mislead users about the quality and trick them into doing bad things for their own project. Closes bevyengine#20796. Fixes (kind of) the problem that motivated bevyengine#20849. ## Solution Remove the `desktop_app` setting from this example. This will cause problems for `accesskit` users (at least on Mac) unfortunately, but that problem is *another* bug: bevyengine#20515. Telling visually impaired users that they can only use screen readers on low CPU utilization apps in our game framework is not acceptable either. I've also removed this from the other UI examples for the same reasons. The `low_power` example exists to demonstrate this: we shouldn't clutter the others without good justification. ## Testing I've run the `feathers` example locally: the bad behavior is no longer observed.
# Objective The intention is to make it more obvious how to replace and edit materials from glTF files in a way that is capable of targeting specific materials like a real application would. Partial documentation for bevyengine#12209 ## Solution Use GltfMaterialName so that it is more obvious how to target specific materials. ## Testing ``` cargo run --example edit_material_on_gltf ``` ## Showcase The tinting is now only applied to the leather materials. <img width="2560" height="1496" alt="screenshot-2025-09-03-at-11 21 25@2x" src="https://github.com/user-attachments/assets/c5010397-00e7-41cf-864c-bf4632bd1975" /> ## Notes - It could be useful to have an extended material that uses the base replacing one of the options, or other material modification examples. I tried to use the existing material extension shader example but it really didn't look like it fit (and appeared buggy visually, although I don't believe it was actually buggy). - I used the prelude in the example instead of separating out every item like it had previously - This is a small improvement, but there are multiple concepts in this example. "Scene-specific overrides" and "editing materials". - This example *could* have material caches (`struct LeatherPartsMat(Handle<..>)`) but right now the example has three separate materials that are all used in the scene so it felt like overkill until the problem is actually present.
…gine#20766) # Objective - Support space views for the atmosphere - Add more accurate lighting to the atmosphere with ray marching - Enable future support for sharp volumetric shadows through the atmosphere - Tracking overall progress in bevyengine#20374 ## Solution - Added spherical coordinate system alongside the sky-view lut parameterization - Added ray-marched rendering method to support space views and accurate lighting - This is setting the stage for PBR integration, volumetric shadows - Could maybe re-use the ray-marching function in the aerial view LUT as well, but I didn't bother for this PR (future improvement) ## Testing - Ran the atmosphere example to ensure it still works fine with both rendering methods - Created a freecam version of the atmosphere example and put the camera in space, below ground. --- ## Showcase https://github.com/user-attachments/assets/e9cf0d91-8e34-435c-834e-02602a9496a2 --------- Co-authored-by: atlv <email@atlasdostal.com>
…gine#20847) # Objective See bevyengine#14697. We use `#[doc(fake_variadic)]` for most of our trait impls for tuples, but it's missing for a few, mostly traits that were added after bevyengine#14703: * `BundleEffect` * `NoBundleEffect` * `ReadOnlyQueryData` * `ReleaseStateQueryData` * `SpawnableList` * `SpecializerKey` ## Solution Pass `#[doc(fake_variadic)]` through `all_tuples!` for those trait impls. ## Testing Ran `RUSTFLAGS='--cfg docsrs_dep' RUSTDOCFLAGS='--cfg=docsrs' cargo +nightly doc` <img width="649" height="143" alt="image" src="https://github.com/user-attachments/assets/4ef0c53d-fe22-4f39-b9c7-c6df9a48e791" /> <img width="910" height="218" alt="image" src="https://github.com/user-attachments/assets/2eaf8c0e-48fe-4dfe-8691-a23ca6f2d1f0" /> <img width="696" height="153" alt="image" src="https://github.com/user-attachments/assets/0909a663-7c32-45ce-af12-ef789941ef5b" />
…20858) # Objective - Addresses typo in the error message for `MissingAssetLoader`. ## Solution - Fixed typo so TypeId is in the error message. ## Testing Removed the glb loader and got these errors: ``` ERROR bevy_asset::server: Could not find an asset loader matching: Loader Name: None; Asset Type: Some(TypeId(0x2e8ddd3139ef47afd4012da1e702dc0f)); Extension: None; Path: Some("models/animated/Fox.glb#Animation2"); ERROR bevy_asset::server: Could not find an asset loader matching: Loader Name: None; Asset Type: Some(TypeId(0x5da2185084a1f827ba69a74a987a0946)); Extension: None; Path: Some("models/animated/Fox.glb#Scene0") ```
# Objective Flatten the inner section of `prepare_uinodes` one level by replacing the if-let-else block with let-some-else-continue. ## Testing Should see no changes with: ```cargo run --example testbed_ui```
# Objective I didn't realize that `UnapprovedPathMode` defaults to `Forbid` until I read the source code, and ended up creating the issue bevyengine#20865. It would be better to improve the documentation so that the default value is clear without having to read the source code. ## Solution - Update the documentation for `UnapprovedPathMode`. - Fix typos. ## Testing - `cargo test --doc -p bevy_asset` - Run `cargo doc --open -p bevy_asset` and confirmed that the changes were correctly reflected.
…ine#20450) # Objective - Closes bevyengine#20353 ## Solution - Removed `TextFont::from_font` and `TextFont::from_line_height`. - Updated `examples/testbed/2d.rs` to use the `Form` impl. - Added migration guide.
# Objective - rename to have less suffixing - match future bevy_post_process crate ## Solution - remove ing ## Testing - run anti_aliasing example (not renamed, can rename this too if desired)
# Objective - `StateScoped` was renamed to `DespawnOnExitState`, and we introduced `DespawnOnEnterState` - This is redundant: the type it wraps is already a state - Often, state enums have `State` in their names, leading to stutter: `DespawnOnExitState(GameState::Gameplay)` - This component is *very* common in games. The longer name makes it clunkier to use, so we should be careful when expanding it. I think the added clarity is good, but we can do better. ## Solution - Compromise to `DespawnOnExit` - Do the same for `DespawnOnEnter` ## Testing - CI
# Objective Support anti-aliasing for Custom Projection. ## Solution function is_perspective() is added to Projection, it checks the matrix to determine if the Custom Projection is perspective. ## Testing - Did you test these changes? If so, how? yes, we have an internal project that uses Custom Projection, I tested taa, but not the dlss, but the logic is the same. - Are there any parts that need more testing? N/A - How can other people (reviewers) test your changes? Is there anything specific they need to know? here is the detail: https://metashapes.com/blog/opengl-metal-projection-matrix-problem/ - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? N/A
# Objective Split out post process effects from bevy_core_pipeline because they are not core pipelines. ## Solution @IceSentry proposed something like this, not sure if the split is exactly as he envisioned but this seems reasonable to me. The goal is to move absolutely everything possible out of bevy_core_pipelines to unblock bevy_pbr/bevy_sprite_render compilation. Future PRs may attempt to move more little bits out. ## Testing
…#20879) # Objective - Putting multiple plugin groups inside a plugin group results in a compile error ## Solution - remove spurious comma in doc gen ## Testing - Found when trying to use multiple plugin groups in DefaultPlugins for bevyengine#20778, fixed for that.
# Objective - Followup to bevyengine#20872 (comment) - `clear_events_on_exit_state` is now inconsistent with `DespawnOnExit` - Fixes bevyengine#20880 ## Solution - remove the suffix ## Testing - CI --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Minimal changes to drop Undo/Redo functionality (with the intention to revert after 0.17)