We are excited to announce our first technical preview of editor scripting API for creating interactive UI elements in the editor! 
To learn more, check out the new manual that explains how to create interactive dialogs using editor scripts. Also, now that the editor API has grown quite a bit, we added the editor API reference.
Try it out and tell us what you think!
Aaa! Can’t wait to put my hands on it this weekend! 
This is glorious! Definitely will immensely help to build our workflows!
Congratulations with release!
This is really nice! Perfect timing considering the bad weather for the weekend 
Wow this is awesome!
It is way more capable than what I imagine when submitting a request for it. This will be super useful! Already added a dialog to my editor-script-atlas and it’s such a QoL improvement not to have to change the name after wards.
Is there a way to run do an action (change focus/do default button) when Enter is pressed within a editor.ui.string_field? Currently the behavior is that it’s grayed out when typing, when press enter the default button lights up, but as the string field has focus enter doesn’t trigger the button. I have to give focus to the dialog window first for the default button to fire on Enter.
My dialog is a copy of the example in the manual. Windows computer.
Do you even want the rest of the string_field behavior? E.g. if there was some initial text, and if you, after some typing, press Escape, do you want the text in the string_field to reset to the initial one? To me, it seems like what you want is a generic text field that reports changes on typing and does not consume the Enter and Escape at all, because if the text input does not consume the Enter, it will be handled by the dialog and trigger the default dialog button. I’m asking because we implemented this component (text_field) but commented it out before the initial release because we were unsure if there would be a demand for it. We also felt we were creating too many similarly-looking components…
I think expected behaviors for windows and dialogs are being mixed here.
A window I wouldn’t be able to dismiss with Escape but would expect it the reset the field and lose focus. Enter wouldn’t close anything but would submit the value only.
In a dialog Escape would instantly close it and Enter would submit and fire of the default = true event.
Now it comes down to what we use the editor script UI for, some might be building something that they would like to behave like a Window, and others like a dialog.
The safest is definitely to try to support both expected styles.
The only thing missing to be able to support both is that if a button has a default = true then Enter is only consumed if the field could receive and render and a newline character. If newline are not possible it should submit the value and fire of the default event.
Can this be used on the ‘project selection and creation screen’? It would be nice to be able to change this screen. For example the home tab lists recent projects. It would be good to be able to Extend this, such as to all projects in specific directories. Probably not, this is a nice to have thing, so no big deal really.
This is so great! 
I’m working with them extensively now!
Sliders would be cool to add (especially for capped values, like Gain, Pan, Speed, etc) 
The features mentioned by @Jerakin are also much needed 
icon — an icon; currently, it can only be used for presenting a small set of predefined icons, but we intend to allow more icons in the future.
Where can we find how to use and what icons are available?
How do we add shortcuts for those commands?
You can find the options when using documentation pop-up in the editor, or in the reference: API reference (editor)
Ah, but that’s a dialog_button, not an ordinary button. As their docs state, dialog buttons don’t have icons, while ordinary buttons do.
Ah, right! 
Do strings and checkbox values save their values when changed from default values? If not, is there a simple way to do this?
They don’t. But @vlaaad is working on a solution for stored editor preferences that can also be used from editor scripts.
Ah, ok. I thought the answer to your problem would be to use state, because you store here whatever you want and pass context from function to function (e.g. on_pressed callbacks)
-- default value
local enabled, set_enabled = editor.ui.use_state(true)
-- initializer function + args
local id, set_id = editor.ui.use_state(string.lower, props.name)Oh, I thought @Steven_McDade was asking about storing values from one session to another, like the bundle dialogs do.
Yes, I was hoping to store values from one session to another and it’s great that it’s being worked on.
How should I go with an idea of creating a table (using grid component) that has dynamic number of rows and columns in a popup?