Drop down values for take on Text should be shortened
#6052
Assignees
Labels
--bug
Type: bug
p-medium
Should be completed in the next few sprints
s-info-needed
Status: more information needed from submitter
Milestone
Comments
|
@Frizi am I correct that it is a bug? If I understand the idea correctly, every access chain should be shortened, so on the screenshot, even the |
farmaazon
added
g-widgets
p-medium
|
@Frizi bump |
2 tasks
mergify bot
pushed a commit
that referenced
this issue
May 30, 2023
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.
github-project-automation
bot
moved this from 🌟 Q/A review
to 🟢 Accepted
in Issues Board
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Discord username
No response
How important is this feature to you?
2 – Somewhat important, but I can live without it
Describe the idea you'd like to see implemented.
We a shortening drop down values for
takeon aVectorbut forTextwe are displaying FQN. It's hard to read (specially because longer names are cut).Is your feature request related to a problem?
No response
Screenshots, screencasts, mockups.
No response
Would you be willing to help us implement this feature?
No
The text was updated successfully, but these errors were encountered: