I've added a toggle to the window that allows the user to switch between the old and new behavior for the dialog box.

Thanks for testing! I'll look into fixing the navigation and preview updating.

As for the default setting, I don't remember providing an initial setting for it - will get that done as well! I think it might be best to have it off by default so it matches the existing behavior. But that may also risk it going unnoticed and unused by people.

Notes for myself: When clicking an item in Quick Open's grid view, the item becomes selected. However, to allow the arrow keys to change the selection, I first have to tap the right arrow key as many times as the current selected item is items from the right. For example, if there are 3 columns, then I have to tap the right key 3 times. Then the search bar highlights, and after that, if I press the right key again, the selection starts moving again.

You can now navigate with the keyboard after clicking on an item, and the Instant Preview setting now officially defaults to false. (Again, totally open to make it default to enabled if others would prefer it.)

I think this would be a better fit for a later PR, but it appears the way that the focused Quick Open item is selected is... nonstandard. It seems to be some sort of hack around the search bar's inputs, rather than using Godot's built-in UI focus system. When the keyboard controls didn't work for selecting items after clicking one, that was because the item itself had become selected according to Godot - but in order for items to appear selected in Quick Open, the search bar has to actually be selected so it can pass the inputs through to display one of the items as selected... again, rather strange, and probably worth looking into replacing with Godot's normal focus system.

Hm, so I thought I reproduced the issue you were experiencing with my test project, and fixed that. However, just to confirm I just downloaded your test project and I can see the material isn't updating when Instant Preview is enabled. Will have to look more at this tomorrow 😅

3 June 2025, 10:34 PM:

So, the good news is, I think I've found the underlying issue causing this bug. The bad news is, it seems to have to do with how the editor handles property/resource pickers, which is definitely gnarlier than just the Quick Load menu.

Basically, it appears that whenever a new texture is selected for the Material, the entire Material EditorResourcePicker is removed from the tree, and a new(?) one is added back in its place. Because the old one provided the _file_selected callback, when this removal and replacement is done the Callable that the Quick Load menu has becomes invalid, and thus selecting a new texture is selected nothing is passed to the Material to actually update it (i.e., _file_selected is never called).

I'm not totally sure yet how to address this, but I'll see what I can think of. If anyone has suggestions (or recognizes any inaccuracies in my current diagnosis), they would be very helpful! 😄

After a short break, I think I've made some headway on this, but it still seems it's going to be much more involved than I'd previously hoped.

Currently the Quick Load window is passed the object and property path it is setting. When the user selects a new resource, it simply calls Object::set() with the selected resource, and the editor updates with it instantly.

However, undo/redo is currently not supported, and the editor does not recognize that modifications have been made to the scene/project that trigger the "unsaved" status for the window.

I think you could do similar to ColorPicker - change things instantly, but allow canceling them. If you press Enter, the resource gets accepted and makes undo/redo action. If you press Escape, the resource goes back to the initial value, so no undo action is needed.

Done! I think I'd avoided doing that before because I misunderstood how the undo/redo actions worked, and thought it would be much harder to do than it actually was (assuming it worked, of course 😅 )

Instant preview should be disabled for global quick open dialogs, like the one for opening scenes:

Maybe hide the button if the dialog is not open for a property?

Now with 4.6 in development, I've returned to try and see this PR through.

For now, I've rolled back the attempt at copying the _edit_set() code, and instead just have the "confirm selection" code path work the same way that it did before this PR, by calling a callback method from EditorResourcePicker.

Bugs I'm aware of currently:

• When Instant Preview is enabled and the Quick Open window is used to modify a property of a single object, the "undone" state seems to keep the same property value as the "done" state.
  • My guess here is that the temporarily-switched resource is being remembered as what was there before the operation, so the "undo" and "redo" operations save the same resource? If this is the case, I think it should be fixable by saving the current resource to a variable when the Quick Open window is opened, then just before the resource change is confirmed, set it back to that initial one.
• When Instant Preview is enabled and the Quick Open window is used to modify a property on multiple objects at once, selecting a new resource in the window without confirming it still adds it to the undo/redo stack.
  • It looks to me like the undo/redo functionality is at least baked into the setting function for MultiNodeEdit. So I may need to add some kind of parameter to MultiNodeEdit, such that I can tell it I want to set the property without adding an undo/redo item.

(These notes are mostly just for myself to keep track of things, but if anyone can read them and has useful insights, I would really appreciate them!)

Having MultiNodeEdit support Instant Preview would be very nice, but if it seems like it's going to be a major hurdle to overcome due to deep structural stuff, I think it might be wise to have Instant Preview simply not activate for MultiNodeEdit, and then perhaps focus on that in a future PR.

I've done a bit of testing, and so far editing both single nodes and groups of nodes at a time has seemed to work correctly!

To handle MultiNodeEdit, I've made the EditorQuickOpenDialog class a friend of it, so it can access the _set_impl() method; furthermore, I've added an optional argument to _set_impl() that prevents it from pushing to the history stack. This way, we reuse more code instead of duplicating it.

MultiNode no longer crashes, but it creates wrong undo action when you cancel the dialog.

That should be fixed now, I think! Sorry for all the runaround with the bugs, but thank you very much for testing it! 😅

I've also made it so that the first selection in each Quick Open dialog (i.e., the one that happens automatically when the window opens) does not trigger the "preview" behavior, overwriting whatever property value was previously set. The Quick Open window itself still displays the first item in its list as being selected; in the future, it could be nice to have the currently resource for the property be highlighted instead, but IMO the behavior now should be good enough.

Thanks!

A little bit sad that there is no any love for audio files. There is no way to preview audio in Quick Open dialog and with Instant preview only thing you can preview is waveform but you can't hear actual audio. It would be great to have at least basic audio preview controls. in this case Instant preview option can be = autoplay on select, or autoplay can be separate checkbox near other playback controls.
btw preview audio in File system is available but also far from convenient: you have to double click file and then hit play in separate window and more of that this window is different for wav and mp3. I have created a little dock-addon to overcome this, but it can't be used in Quick Open dialog (and can't be truly integrated in File system panel):

I definitely agree, being able to click through audio files and quickly hear them would be great! Due to how the implementation of Instant Preview works alongside most resource types and how Godot nodes act when they are assigned a new audio resource, Instant Preview doesn't really do anything in their case.

We'd specifically have to code the Quick Open dialog to recognize when it's looking for audio resources, and when that is true, start playing the audio resource from a player somewhere. This is something that could be possible for 4.7 or beyond.

I've submitted a PR that adds a (very simple) implementation of AudioStream previewing for Instant Preview 🙂
#115746