8bc3ebd70a
Implements #6792 Fixes #6715 Fixes #6052 Fixes #5689 The dynamic dropdown widgets entries now can specify additional widget configuration as a list of `parameters` of the inner method call. That allows for creating smarter widgets within nested constructors, taking the outer widget's context into account. <img width="772" alt="image" src="https://github.com/enso-org/enso/assets/919491/97c70654-9170-4cf0-ae4d-2c25c74caa96"> With the changes to the serialization logic, I have also adressed issues related to automatic label generation for both static and dynamic dropdown entries. For access chains (e.g. `Foo.Bar.Baz_Qux`), the label will now always contain only the last segment, and all underscores will be removed (e.g. `Baz Qux`). This also applies to dynamic entries where the label is not explicitly specified in method annotation. <img width="265" alt="image" src="https://github.com/enso-org/enso/assets/919491/1abe6c77-010b-4622-b252-97cd1543cb48"> Additionaly, now the dynamic entries containing constructors will also be resolved within suggestion database, allowing us to automatically insert relevant import, shorten the actually used expression and wrap it with parentheses if required. That was required for nested widgets to show up, as we depend on properly resolved argument names to show them. The widget definitions in annotations no longer need to wrap the expressions manually. Instead, the constructors used in dropdown entries should be specified using fully qualified names, similarly to how we do it in tag values. CC @jdunkerley - The dropdown entries containing just a constructor will no longer need added parentheses around them. Instead, the constructors should be specified using fully qualified names, similarly to how we do it in tag values. <img width="389" alt="image" src="https://github.com/enso-org/enso/assets/919491/19944b5b-d0c7-43ac-bf17-ca1556e0b3f0"> Note that currently the import resolution is attempted even if the used constructor is is not specified using a fully qualified name. To accomplish that, the IDE is performing a more expensive search through whole suggestion database for matching type and module (e.g. in example above, we are searching for a match for `Aggregate_Column.First`). If there are multiple potential matches due to a name collision, it is undefined which one would be preferred. Effectively one will be picked at random. To avoid that, the libraries should over time transition to using fully qualified names wherever possible. # Important Notes I have removed the `payload` field from the span tree, and with it the generic argument on its nodes. This was already partially done on the branch with new design, on which I also had a few changes that turned out to be useful for this PR. So I pulled it in as well. It is a nice simplification that will ease our further work on removing the span-tree altogether. The biggest impact it had was on the node output port, where I had to store the port data outside of the span tree. This is the approach we would be taking when transitioning to AST anyway. |
||
|---|---|---|
| .. | ||
| analytics | ||
| config | ||
| controller | ||
| docs | ||
| enso-profiler-enso-data | ||
| language | ||
| src | ||
| suggestion-database | ||
| tests | ||
| view | ||
| Cargo.toml | ||
| config.yaml | ||
| LICENSE | ||
| README.md | ||
This is the subtree for Enso's graphical interface component. If you're looking for the repository root, you may find it at at 👉 github.com/enso-org/enso 👈
Enso IDE
Overview
Enso is an award-winning interactive programming language with dual visual and textual representations. It is a tool that spans the entire stack, going from high-level visualisation and communication to the nitty-gritty of backend services, all in a single language. Watch the following introduction video to learn what Enso is, and how it helps companies build data workflows in minutes instead of weeks.
This repository contains the source code of Enso interface only. If you are interested in how the interface is build or you want to develop it with us, you are in the right place. See the development and contributing guidelines to learn more about the code structure and the development process.
Getting Started
Enso is distributed both in form of pre-build packages for MacOS, Windows, or Linux, as well as the source code. See the demo scenes, and read the documentation to learn more.
Building
The project builds on macOS, Linux, and Windows. Build functionality is provided
by our build script, that are accessible through run (Linux and macOS) or
run.cmd (Windows) wrappers.
To build the project, simply run ./run ide build (on Linux or macOS) or
.\run.cmd ide build (Windows) to build IDE. To learn more about other
available commands use --help argument. Read the detailed
development guide to learn more.
License
The Enso Language Compiler is released under the terms of the Apache v2 License. The Enso Graphical Interface and it's rendering engine are released under the terms of the AGPL v3 License. This license set was choosen to both provide you with a complete freedom to use Enso, create libraries, and release them under any license of your choice, while also allowing us to release commercial products on top of the platform, including Enso Cloud and Enso Enterprise on-premise server managers.
Contributing
Enso is a community-driven open source project which is and will always be open and free to use. We are committed to a fully transparent development process and highly appreciate every contribution. If you love the vision behind Enso and you want to redefine the data processing world, join us and help us track down bugs, implement new features, improve the documentation or spread the word! Join our community on a Discord chat and read the development and contributing guidelines.
