2022-03-10 08:21:57 +03:00
|
|
|
// === Non-Standard Linter Configuration ===
|
2022-03-10 07:57:59 +03:00
|
|
|
#![deny(non_ascii_idents)]
|
|
|
|
#![warn(unsafe_code)]
|
|
|
|
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
use enso_gui::integration_test::prelude::*;
|
2022-02-22 19:43:37 +03:00
|
|
|
|
|
|
|
use approx::assert_abs_diff_eq;
|
2022-03-31 17:16:28 +03:00
|
|
|
use enso_frp::future::FutureEvent;
|
|
|
|
use enso_frp::io::mouse::PrimaryButton;
|
2023-03-29 14:16:31 +03:00
|
|
|
use enso_frp::stream::ValueProvider;
|
2022-03-31 17:16:28 +03:00
|
|
|
use enso_gui::view::graph_editor::component::node as node_view;
|
2022-03-30 15:49:07 +03:00
|
|
|
use enso_gui::view::graph_editor::component::node::test_utils::NodeModelExt;
|
2022-03-16 21:02:47 +03:00
|
|
|
use enso_gui::view::graph_editor::GraphEditor;
|
2022-03-21 18:08:17 +03:00
|
|
|
use enso_gui::view::graph_editor::Node;
|
2022-03-16 21:02:47 +03:00
|
|
|
use enso_gui::view::graph_editor::NodeId;
|
|
|
|
use enso_gui::view::graph_editor::NodeSource;
|
2022-02-22 19:43:37 +03:00
|
|
|
use enso_web::sleep;
|
|
|
|
use ensogl::display::navigation::navigator::ZoomEvent;
|
2022-03-31 17:16:28 +03:00
|
|
|
use ensogl::display::scene::test_utils::MouseExt;
|
|
|
|
use ensogl::display::Scene;
|
2022-02-22 19:43:37 +03:00
|
|
|
use std::time::Duration;
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
use wasm_bindgen_test::wasm_bindgen_test;
|
2022-02-11 15:19:02 +03:00
|
|
|
|
|
|
|
|
2022-03-10 07:32:33 +03:00
|
|
|
|
2022-02-11 15:19:02 +03:00
|
|
|
wasm_bindgen_test::wasm_bindgen_test_configure!(run_in_browser);
|
|
|
|
|
|
|
|
#[wasm_bindgen_test]
|
|
|
|
async fn create_new_project_and_add_nodes() {
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
let test = Fixture::setup_new_project().await;
|
2022-02-22 19:43:37 +03:00
|
|
|
let graph_editor = test.graph_editor();
|
2022-02-11 15:19:02 +03:00
|
|
|
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
assert_eq!(graph_editor.model.nodes.len(), 2);
|
2022-02-11 15:19:02 +03:00
|
|
|
let expect_node_added = graph_editor.node_added.next_event();
|
|
|
|
graph_editor.add_node();
|
2022-03-16 21:02:47 +03:00
|
|
|
let (added_node_id, source_node, _) = expect_node_added.expect();
|
|
|
|
assert_eq!(source_node, None);
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
assert_eq!(graph_editor.model.nodes.len(), 3);
|
2022-02-11 15:19:02 +03:00
|
|
|
|
|
|
|
let added_node =
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
graph_editor.model.nodes.get_cloned_ref(&added_node_id).expect("Added node is not added");
|
2023-03-29 14:16:31 +03:00
|
|
|
assert_eq!(added_node.view.set_expression.value().code, "");
|
2022-02-11 15:19:02 +03:00
|
|
|
}
|
2022-02-22 19:43:37 +03:00
|
|
|
|
|
|
|
#[wasm_bindgen_test]
|
|
|
|
async fn debug_mode() {
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
let test = Fixture::setup_new_project().await;
|
2022-02-22 19:43:37 +03:00
|
|
|
let project = test.project_view();
|
|
|
|
let graph_editor = test.graph_editor();
|
|
|
|
|
|
|
|
assert!(!graph_editor.debug_mode.value());
|
|
|
|
|
|
|
|
// Turning On
|
|
|
|
let expect_mode = project.debug_mode.next_event();
|
2023-05-08 13:12:26 +03:00
|
|
|
let expect_popup_message = project.debug_mode_popup().content_frp_node().next_event();
|
2022-02-22 19:43:37 +03:00
|
|
|
project.enable_debug_mode();
|
|
|
|
assert!(expect_mode.expect());
|
|
|
|
let message = expect_popup_message.expect();
|
|
|
|
assert!(
|
|
|
|
message.contains("Debug Mode enabled"),
|
2023-02-03 02:05:25 +03:00
|
|
|
"Message \"{message}\" does not mention enabling Debug mode"
|
2022-02-22 19:43:37 +03:00
|
|
|
);
|
|
|
|
assert!(
|
|
|
|
message.contains(enso_gui::view::debug_mode_popup::DEBUG_MODE_SHORTCUT),
|
2023-02-03 02:05:25 +03:00
|
|
|
"Message \"{message}\" does not inform about shortcut to turn mode off"
|
2022-02-22 19:43:37 +03:00
|
|
|
);
|
|
|
|
assert!(graph_editor.debug_mode.value());
|
|
|
|
|
|
|
|
// Turning Off
|
|
|
|
let expect_mode = project.debug_mode.next_event();
|
2023-05-08 13:12:26 +03:00
|
|
|
let expect_popup_message = project.debug_mode_popup().content_frp_node().next_event();
|
2022-02-22 19:43:37 +03:00
|
|
|
project.disable_debug_mode();
|
|
|
|
assert!(!expect_mode.expect());
|
|
|
|
let message = expect_popup_message.expect();
|
|
|
|
assert!(
|
|
|
|
message.contains("Debug Mode disabled"),
|
2023-02-03 02:05:25 +03:00
|
|
|
"Message \"{message}\" does not mention disabling of debug mode"
|
2022-02-22 19:43:37 +03:00
|
|
|
);
|
|
|
|
assert!(!graph_editor.debug_mode.value());
|
|
|
|
}
|
|
|
|
|
|
|
|
#[wasm_bindgen_test]
|
|
|
|
async fn zooming() {
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
let test = Fixture::setup_new_project().await;
|
2022-02-22 19:43:37 +03:00
|
|
|
let project = test.project_view();
|
|
|
|
let graph_editor = test.graph_editor();
|
2022-03-04 17:13:23 +03:00
|
|
|
let camera = test.ide.ensogl_app.display.default_scene.layers.main.camera();
|
2022-02-22 19:43:37 +03:00
|
|
|
let navigator = &graph_editor.model.navigator;
|
|
|
|
|
|
|
|
let zoom_on_center = |amount: f32| ZoomEvent { focus: Vector2(0.0, 0.0), amount };
|
|
|
|
let zoom_duration_ms = Duration::from_millis(1000);
|
|
|
|
|
|
|
|
// Without debug mode
|
|
|
|
navigator.emit_zoom_event(zoom_on_center(-1.0));
|
|
|
|
sleep(zoom_duration_ms).await;
|
|
|
|
assert_abs_diff_eq!(camera.zoom(), 1.0, epsilon = 0.001);
|
|
|
|
navigator.emit_zoom_event(zoom_on_center(1.0));
|
|
|
|
sleep(zoom_duration_ms).await;
|
|
|
|
assert!(camera.zoom() < 1.0, "Camera zoom {} must be less than 1.0", camera.zoom());
|
|
|
|
navigator.emit_zoom_event(zoom_on_center(-2.0));
|
|
|
|
sleep(zoom_duration_ms).await;
|
|
|
|
assert_abs_diff_eq!(camera.zoom(), 1.0, epsilon = 0.001);
|
|
|
|
|
|
|
|
// With debug mode
|
|
|
|
project.enable_debug_mode();
|
|
|
|
navigator.emit_zoom_event(zoom_on_center(-1.0));
|
|
|
|
sleep(zoom_duration_ms).await;
|
|
|
|
assert!(camera.zoom() > 1.0, "Camera zoom {} must be greater than 1.0", camera.zoom());
|
|
|
|
navigator.emit_zoom_event(zoom_on_center(5.0));
|
|
|
|
sleep(zoom_duration_ms).await;
|
|
|
|
assert!(camera.zoom() < 1.0, "Camera zoom {} must be less than 1.0", camera.zoom());
|
|
|
|
navigator.emit_zoom_event(zoom_on_center(-5.0));
|
|
|
|
sleep(zoom_duration_ms).await;
|
|
|
|
assert!(camera.zoom() > 1.0, "Camera zoom {} must be greater than 1.0", camera.zoom());
|
|
|
|
}
|
2022-03-16 21:02:47 +03:00
|
|
|
|
|
|
|
#[wasm_bindgen_test]
|
|
|
|
async fn adding_node_with_add_node_button() {
|
|
|
|
const INITIAL_NODE_COUNT: usize = 2;
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
let test = Fixture::setup_new_project().await;
|
2022-03-16 21:02:47 +03:00
|
|
|
let graph_editor = test.graph_editor();
|
|
|
|
let scene = &test.ide.ensogl_app.display.default_scene;
|
|
|
|
|
2022-03-31 23:17:04 +03:00
|
|
|
let InitialNodes { below: (_, bottom_node), .. } =
|
|
|
|
InitialNodes::obtain_from_graph_editor(&graph_editor);
|
|
|
|
let bottom_node_pos = bottom_node.position();
|
2022-03-16 21:02:47 +03:00
|
|
|
|
|
|
|
// Node is created below the bottom-most one.
|
2022-03-31 23:17:04 +03:00
|
|
|
let (first_node_id, node_source, first_node) =
|
|
|
|
add_node_with_add_node_button(&graph_editor, "1 + 1").await;
|
2022-03-16 21:02:47 +03:00
|
|
|
assert!(node_source.is_none());
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
assert_eq!(graph_editor.model.nodes.len(), INITIAL_NODE_COUNT + 1);
|
2022-03-31 23:17:04 +03:00
|
|
|
let node_position = first_node.position();
|
2022-03-16 21:02:47 +03:00
|
|
|
assert!(
|
2022-03-31 23:17:04 +03:00
|
|
|
first_node.position().y < bottom_node_pos.y,
|
|
|
|
"Expected that {node_position}.y < {bottom_node_pos}.y"
|
2022-03-16 21:02:47 +03:00
|
|
|
);
|
|
|
|
|
|
|
|
// Selected node is used as a `source` node.
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
graph_editor.model.nodes.deselect_all();
|
|
|
|
graph_editor.model.nodes.select(first_node_id);
|
2022-03-31 23:17:04 +03:00
|
|
|
let (_, node_source, _) = add_node_with_add_node_button(&graph_editor, "+ 1").await;
|
2022-03-16 21:02:47 +03:00
|
|
|
assert_eq!(node_source, Some(NodeSource { node: first_node_id }));
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
assert_eq!(graph_editor.model.nodes.len(), INITIAL_NODE_COUNT + 2);
|
2022-03-16 21:02:47 +03:00
|
|
|
|
|
|
|
// If there is a free space, the new node is created in the center of screen.
|
|
|
|
let camera = scene.layers.main.camera();
|
2022-12-19 04:16:54 +03:00
|
|
|
camera.update_xy(|pos| pos + Vector2(1000.0, 1000.0));
|
2022-03-31 23:17:04 +03:00
|
|
|
wait_a_frame().await;
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
graph_editor.model.nodes.deselect_all();
|
2022-03-31 23:17:04 +03:00
|
|
|
let (node_id, node_source, _) = add_node_with_add_node_button(&graph_editor, "1").await;
|
2022-03-16 21:02:47 +03:00
|
|
|
assert!(node_source.is_none());
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
assert_eq!(graph_editor.model.nodes.len(), INITIAL_NODE_COUNT + 3);
|
2022-03-31 17:16:28 +03:00
|
|
|
let node_position = graph_editor.model.get_node_position(node_id).expect(
|
|
|
|
"Node was not
|
|
|
|
added",
|
|
|
|
);
|
2022-03-16 21:02:47 +03:00
|
|
|
let center_of_screen = scene.screen_to_scene_coordinates(Vector3::zeros());
|
|
|
|
assert_abs_diff_eq!(node_position.x, center_of_screen.x, epsilon = 10.0);
|
|
|
|
assert_abs_diff_eq!(node_position.y, center_of_screen.y, epsilon = 10.0);
|
|
|
|
}
|
|
|
|
|
2022-03-21 18:08:17 +03:00
|
|
|
#[wasm_bindgen_test]
|
|
|
|
async fn adding_node_by_clicking_on_the_output_port() {
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
let test = Fixture::setup_new_project().await;
|
2022-03-21 18:08:17 +03:00
|
|
|
let graph_editor = test.graph_editor();
|
2022-03-31 23:17:04 +03:00
|
|
|
let (node_1_id, _, node_1) = add_node_with_internal_api(&graph_editor, "1 + 1").await;
|
2022-03-21 18:08:17 +03:00
|
|
|
|
|
|
|
let method = |editor: &GraphEditor| {
|
2023-07-27 16:00:47 +03:00
|
|
|
let port = node_1.model().output_port_hover_shape().expect("No output port");
|
2023-03-28 05:41:25 +03:00
|
|
|
port.events_deprecated.mouse_over.emit(());
|
2022-03-21 18:08:17 +03:00
|
|
|
editor.start_node_creation_from_port();
|
|
|
|
};
|
2022-03-31 23:17:04 +03:00
|
|
|
let (_, source, node_2) = add_node(&graph_editor, "+ 1", method).await;
|
2022-03-21 18:08:17 +03:00
|
|
|
|
|
|
|
assert_eq!(source.unwrap(), NodeSource { node: node_1_id });
|
|
|
|
assert!(node_2.position().y < node_1.position().y);
|
|
|
|
}
|
|
|
|
|
2022-03-31 23:17:04 +03:00
|
|
|
#[wasm_bindgen_test]
|
|
|
|
async fn new_nodes_placement_with_nodes_selected() {
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
let test = Fixture::setup_new_project().await;
|
2022-03-31 23:17:04 +03:00
|
|
|
let graph_editor = test.graph_editor();
|
|
|
|
let InitialNodes { above: (node_1_id, node_1), below: (node_2_id, node_2) } =
|
|
|
|
InitialNodes::obtain_from_graph_editor(&graph_editor);
|
|
|
|
|
|
|
|
// Scenario 1. Creating a new node with one node selected.
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
graph_editor.model.nodes.select(node_2_id);
|
2022-03-31 23:17:04 +03:00
|
|
|
let (node_3_id, _, node_3) = add_node_with_add_node_button(&graph_editor, "+ 1").await;
|
|
|
|
assert_eq!(
|
|
|
|
node_3.position().x,
|
|
|
|
node_2.position().x,
|
|
|
|
"New node is not left-aligned to the selected one."
|
|
|
|
);
|
|
|
|
assert!(node_3.position().y < node_2.position().y, "New node is not below the selected one.");
|
|
|
|
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
graph_editor.model.nodes.deselect_all();
|
|
|
|
graph_editor.model.nodes.select(node_2_id);
|
2022-03-31 23:17:04 +03:00
|
|
|
let (node_4_id, _, node_4) = add_node_with_shortcut(&graph_editor, "+ 1").await;
|
|
|
|
assert_eq!(
|
|
|
|
node_4.position().y,
|
|
|
|
node_3.position().y,
|
|
|
|
"New node is not vertically aligned to the previous one."
|
|
|
|
);
|
|
|
|
assert!(
|
|
|
|
node_4.position().x < node_3.position().x,
|
|
|
|
"New node is not to the left of the previous one."
|
|
|
|
);
|
|
|
|
|
|
|
|
graph_editor.remove_node(node_3_id);
|
|
|
|
graph_editor.remove_node(node_4_id);
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
graph_editor.model.nodes.deselect_all();
|
2022-03-31 23:17:04 +03:00
|
|
|
|
|
|
|
// Scenario 2. Creating a new node with multiple nodes selected.
|
|
|
|
node_1.set_position(Vector3(-100.0, 0.0, 0.0));
|
|
|
|
wait_a_frame().await;
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
graph_editor.model.nodes.select(node_1_id);
|
|
|
|
graph_editor.model.nodes.select(node_2_id);
|
2022-03-31 23:17:04 +03:00
|
|
|
|
|
|
|
let (.., node_5) = add_node_with_shortcut(&graph_editor, "+ 1").await;
|
|
|
|
assert_eq!(
|
|
|
|
node_5.position().x,
|
|
|
|
node_1.position().x,
|
|
|
|
"New node is not left-aligned to the first selected one."
|
|
|
|
);
|
|
|
|
assert!(node_5.position().y < node_2.position().y, "New node is not below the bottom node.");
|
|
|
|
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
graph_editor.model.nodes.deselect_all();
|
|
|
|
graph_editor.model.nodes.select(node_1_id);
|
|
|
|
graph_editor.model.nodes.select(node_2_id);
|
2022-03-31 23:17:04 +03:00
|
|
|
|
|
|
|
let (node_6_id, _, node_6) = add_node_with_shortcut(&graph_editor, "+ 1").await;
|
|
|
|
assert_eq!(
|
|
|
|
node_6.position().y,
|
|
|
|
node_5.position().y,
|
|
|
|
"New node is not vertically aligned to the previous one."
|
|
|
|
);
|
|
|
|
assert!(
|
|
|
|
node_6.position().x < node_5.position().x,
|
|
|
|
"New node is not to the left of the previous one."
|
|
|
|
);
|
|
|
|
|
|
|
|
// Scenario 3. Creating a new node with enabled visualization.
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
graph_editor.model.nodes.deselect_all();
|
|
|
|
graph_editor.model.nodes.select(node_6_id);
|
2022-03-31 23:17:04 +03:00
|
|
|
let (node_7_id, _, node_7) = add_node_with_shortcut(&graph_editor, "+ 1").await;
|
|
|
|
let pos_without_visualization = node_7.position().y;
|
|
|
|
graph_editor.remove_node(node_7_id);
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
graph_editor.model.nodes.deselect_all();
|
|
|
|
graph_editor.model.nodes.select(node_6_id);
|
2022-03-31 23:17:04 +03:00
|
|
|
node_6.enable_visualization();
|
|
|
|
wait_a_frame().await;
|
|
|
|
let (.., node_7) = add_node_with_shortcut(&graph_editor, "+ 1").await;
|
|
|
|
assert!(
|
|
|
|
node_7.position().y < pos_without_visualization,
|
|
|
|
"New node is not below the visualization."
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2022-03-31 17:16:28 +03:00
|
|
|
#[wasm_bindgen_test]
|
|
|
|
async fn mouse_oriented_node_placement() {
|
|
|
|
struct Case {
|
|
|
|
scene: Scene,
|
|
|
|
graph_editor: GraphEditor,
|
|
|
|
source_node: Node,
|
|
|
|
mouse_position: Vector2,
|
|
|
|
expected_position: Vector2,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Case {
|
|
|
|
fn run(&self) {
|
|
|
|
self.check_tab_key();
|
|
|
|
self.check_edge_drop();
|
|
|
|
}
|
|
|
|
|
|
|
|
fn check_searcher_opening_place(
|
|
|
|
&self,
|
|
|
|
added_node: FutureEvent<(NodeId, Option<NodeSource>, bool)>,
|
|
|
|
) {
|
|
|
|
let (new_node_id, _, _) = added_node.expect();
|
|
|
|
let new_node_pos =
|
|
|
|
self.graph_editor.model.get_node_position(new_node_id).map(|v| v.xy());
|
|
|
|
assert_eq!(new_node_pos, Some(self.expected_position));
|
|
|
|
self.graph_editor.stop_editing();
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
assert_eq!(self.graph_editor.model.nodes.len(), 2);
|
2022-03-31 17:16:28 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
fn check_tab_key(&self) {
|
2023-03-28 05:41:25 +03:00
|
|
|
self.scene.mouse.frp_deprecated.position.emit(self.mouse_position);
|
2022-03-31 17:16:28 +03:00
|
|
|
let added_node = self.graph_editor.node_added.next_event();
|
|
|
|
self.graph_editor.start_node_creation();
|
|
|
|
self.check_searcher_opening_place(added_node);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn check_edge_drop(&self) {
|
2023-07-27 16:00:47 +03:00
|
|
|
let port = self.source_node.view.model().output_port_hover_shape().unwrap();
|
2023-03-28 05:41:25 +03:00
|
|
|
port.events_deprecated.emit_mouse_down(PrimaryButton);
|
|
|
|
port.events_deprecated.emit_mouse_up(PrimaryButton);
|
|
|
|
self.scene.mouse.frp_deprecated.position.emit(self.mouse_position);
|
2022-03-31 17:16:28 +03:00
|
|
|
assert!(
|
|
|
|
self.graph_editor.has_detached_edge.value(),
|
|
|
|
"No detached edge after clicking port"
|
|
|
|
);
|
|
|
|
let added_node = self.graph_editor.node_added.next_event();
|
Do not immediately modify code when disconnecting the edge at target side. (#7041)
Fixes #6772
When detaching an existing edge by grabbing by a source port, the node's code is no longer immediately modified. It is only changed once the edge has been either connected or destroyed. When grabbing on the source side, the existing behavior is preserved. That way, we always have guaranteed place to keep the edge connected to.
https://github.com/enso-org/enso/assets/919491/49e560cb-0a29-4c6a-97ec-4370185b8c89
In general, the detached edges are now more stable, resilient to all kinds of expression modifications during the drag.
https://github.com/enso-org/enso/assets/919491/e62450ff-46b2-466f-ac33-f4f19e66ee1d
In case there is a situation where the currently dragged edge's port is destroyed (e.g. by Undo/Redo), instead of showing glitched port position it is simply dropped.
https://github.com/enso-org/enso/assets/919491/8fb089aa-a4a5-4a8c-92eb-23aeff9867b8
# Important Notes
The whole edge connection and view handling at the graph-editor view level has been completely rewritten. The edge endpoints are now identified using new `PortId` structure, that is not dependant on the span-tree. This prepares us for eventual removal of the span-tree in favour of manipulating AST directly. Right now those `PortId`s are still stored within the span-tree nodes, but it will be easy to eventually generate them on the fly from the AST itself. The widget tree has also already been switched to that representation where appropriate.
Additionally, I have started splitting the graph editor FRP network into smaller methods. Due to its absolutely enormous size and complexity of it, I haven't finished the split completely, and mostly edge-related part is refactored. I don't want to block this PR on this any longer though, as the merge conflicts are getting a bit unwieldy to deal with.
2023-06-21 00:27:39 +03:00
|
|
|
self.scene.mouse.click_on_background(Vector2::zero());
|
2022-04-04 18:55:55 +03:00
|
|
|
enso_web::simulate_sleep((enso_shortcuts::DOUBLE_EVENT_TIME_MS + 10.0) as f64);
|
2022-03-31 17:16:28 +03:00
|
|
|
self.check_searcher_opening_place(added_node);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
let test = Fixture::setup_new_project().await;
|
2022-03-31 17:16:28 +03:00
|
|
|
let scene = &test.ide.ensogl_app.display.default_scene;
|
|
|
|
let graph_editor = test.graph_editor();
|
|
|
|
let gap_x = graph_editor.default_x_gap_between_nodes.value();
|
|
|
|
let gap_y = graph_editor.default_y_gap_between_nodes.value();
|
|
|
|
let min_spacing = graph_editor.min_x_spacing_for_new_nodes.value();
|
|
|
|
|
2022-03-31 23:17:04 +03:00
|
|
|
let InitialNodes { above: (_, above), below: (_, below) } =
|
|
|
|
InitialNodes::obtain_from_graph_editor(&graph_editor);
|
2022-03-31 17:16:28 +03:00
|
|
|
|
|
|
|
let create_case =
|
|
|
|
|source_node: &Node, mouse_position: Vector2, expected_position: Vector2| Case {
|
|
|
|
scene: scene.clone_ref(),
|
|
|
|
graph_editor: graph_editor.clone_ref(),
|
|
|
|
source_node: source_node.clone_ref(),
|
|
|
|
mouse_position,
|
|
|
|
expected_position,
|
|
|
|
};
|
|
|
|
|
|
|
|
let far_away = below.position().xy() + Vector2(500.0, 500.0);
|
|
|
|
let far_away_expect = far_away;
|
|
|
|
create_case(&below, far_away, far_away_expect).run();
|
|
|
|
|
2022-04-04 18:55:55 +03:00
|
|
|
let under_below = below.position().xy() + Vector2(30.0, -25.0);
|
2022-03-31 17:16:28 +03:00
|
|
|
let under_below_expect = below.position().xy() + Vector2(0.0, -gap_y - node_view::HEIGHT);
|
|
|
|
create_case(&below, under_below, under_below_expect).run();
|
|
|
|
|
2022-04-04 18:55:55 +03:00
|
|
|
let under_above = above.position().xy() + Vector2(30.0, -25.0);
|
2022-03-31 17:16:28 +03:00
|
|
|
let under_above_expect = Vector2(
|
|
|
|
below.position().x - gap_x - min_spacing,
|
|
|
|
above.position().y - gap_y - node_view::HEIGHT,
|
|
|
|
);
|
|
|
|
create_case(&above, under_above, under_above_expect).run();
|
|
|
|
}
|