Improve Quick Open dialog design

[stijn-h]

Describe the project you are working on

A personal project, but it concerns every user.

Describe the problem or limitation you are having in your project

The current Quick Open dialog works, but doesn't provide much more benefit over regular search in the file explorer. This is because the way results are presented is too hard on the brain. The dialog is, in other words, not as quick as it should be. In my view, the purpose of QO should be to open a single file as fast as possible, with as little distractions in the way. Compared to other editors (e.g. VS, VS Code, Sublime Text) it is really hard to use. As the solution to this problem requires some changes to functionality and design is a matter of opinion I am opening a proposal.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

A new Quick Open dialog that makes it easier to understand search results quickly than the current implementation.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I have implemented a WIP version by rewriting the QO class to show what a different design can accomplish with most of the functionality present.

(current version, draft 1, draft 2)

Click for video comparison

Current version (3.4.2) https://user-images.githubusercontent.com/25907608/149032064-205dfc3c-f543-48b6-b19b-008dcbfb21b9.mp4 New design (draft) https://user-images.githubusercontent.com/25907608/149031940-810a8171-bb92-4d24-b2e0-57fe9b3189d5.mp4

The primary identifier of a file is the filename, and in the new design it is the main focus. Because I focused on eliminating distractions, I have also removed some elements such as the unnecessary search and result labels and the "Ok" and "Cancel" buttons. These buttons are cumbersome to use if you can open a file with Enter or a single click instead. I hope the examples are already an improvement, but people are free to pick either one, or suggest changes.

The first design is able to display roughly the same amount of items as the current version. The second one can display less, but could help with long file paths, and because there are less results they are even easier to discern.

The performance of the current implementation is good. It didn't take any kind of changes to node types to make it work, it's just using regular H/Vboxes, labels and texturerects at the moment.

Ideally, we would get text highlights. I got it to work with RichTextLabels, but it was hard to keep the nodes in place. Maybe it's possible, but I don't like relying on that node.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Can't comment on the usage statistics, but no, this can't be worked around easily.

Is there a reason why this should be core and not an add-on in the asset library?

It could be an add-on, however it would functionally compete with the editor instead of complementing it. In my eyes, the current design is flawed and can be replaced with a better solution that is only a little bit more complicated.

[hilfazer]

I like your first draft better although i'd prefer directories to be left aligned.

Additionally the dialog could be larger than it currently is, it's not like the rest of the editor can be interacted with while it's open. Its size could be dependant on size of editor's top level window rather than fixed like it's now.

[fire-forge]

I like the first design. The items in the second design are too tall, but if you added the file preview images to the right side that wouldn't be a problem.

One small design issue: the text gets cut off close to the bottom. This could be fixed by either reintroducing the darker background or by extending the scroll container all the way to the bottom of the window

Also agree with @hilfazer that the window size should be larger, in both the current design and your draft the window is too small to see very many items.

[stijn-h]

It's coming together quite nicely. Feel like I'm mostly getting stuck with some sizing issues with the scroll container and accept dialog.

Page up and now moves to the first and last visible result. Results are now always fully visble. One click opening works as well. Code around opening file is also cleaned up a lot.

https://user-images.githubusercontent.com/25907608/149423372-62a78f30-60ac-4ecf-9922-ca834fba4470.mp4

[Zylann]

From a developer perspective this makes sense. There is another thing that bothers me a lot though: when I am looking for assets, not having thumbnails makes it longer to find the right one. Usually I start typing a few letters and finish by selecting in the few filtered items that remain in the list, this is the moment I have to "parse" the list. Looking for a specific texture or mesh in this way takes longer by reading names than looking at images. I wonder if we could include that to the search somehow.

For example in Unity there is a similar window when assigning an asset (it works in the "Quick Open" way by default), and there is a control to adjust wether the results are shown as a vertical list of names or as a grid of thumbnails (also with names).

Sometimes also, I dont even type anything, I do Quick Open from the inspector and search for an asset right away. I do that typically when the project is super small, but also in larger projects after importing assets, hoping recently imported/used ones show up on top.

[mrbbbaixue]

As @Zylann says, I prefer a thumbnail for each items so that I can get the file I want easier.

This is what I imagine:

But showing thumbnails in list may cause the amount of items included in the first page of this list. Maybe a toggle or edtior settings or something...

And... maybe a icon change of "Quick Load" to help tell from the "Load"?

[Zylann]

But showing thumbnails in list may cause the amount of items included in the first page of this list

Show them in a grid, not in a list. That's what Unity and file explorers do. Text mode shows a list, thumbnail mode shows a grid. The option is on the corner of the window, doesnt need to appear in the context menu. The dialog could also default to one or the other depending on the type of asset, or just remember the last mode it was in.

[stijn-h]

I did like the idea of including thumbnails in the results, but didn't know if it was doable. It turned out to be not that difficult, although I didn't get it to work completely yet:

It works fine for many things, but it does have some problems with scenes especially. If the thumbnail was not cached it isn't automatically created. Also broken files don't work either. We could default to the icon in those cases.

Seeing this convinces me that having both a grid and list mode is probably the best option, especially if we can automatically start on the grid based on the type of file we are looking for. It does complicate the code, but not even that much. Highlighting and arrow keys still worked. Polishing the sizing is going to be painful though.

And... maybe a icon change of "Quick Load" to help tell from the "Load"?

I think this dialog could replace loading with the file explorer. If you want to click through folders, dragging the file from the file system should be enough.

[Zylann]

Could the grid be more like a grid, giving items the same size and have less blank space? I'm thinking of this: Names are cropped but in this view, visuals are more important.

As another ref, here is how it looks in list mode:

[YuriSizov]

Could the grid be more like a grid, giving items the same size and have less blank space?

We need the new FlowContainer for this, GridContainer doesn't allow that kind of flow, unless you recalculate how many columns there are every time you resize the outer control.

[Zylann]

Yeah I was thinking it might be problematic, although indeed could be worked around by reconfiguring the container on resizing. Could also be entirely custom-drawn but despite potential performance gain with large amount of items it could be too complex for now. The new FlowContainer would be nice, although I'm not sure it would take advantage of the fact this is a grid (thinking of cases with lots of items there, variable-sizes often doesn't scale well).

I had in mind to work on this at some point. but glad to see someone is giving a it a try :)

[stijn-h]

The FlowContainer looks very nice. Thanks for the suggestions btw, it keeps looking better.

[LunaticInAHat]

I actually think that moving to the grid is a downgrade. For resource types where the preview image isn't all that meaningful (scripts, saved ParticleMaterials, various types of UI theme overrides, etc.) I think it was much more beneficial to be able to see the entire filename. Also, perhaps I'm just weird in how I organize and name things, but I tend to have similarly/same-named files that are contextualized by which directory they're in (slot_icon.png in ui/newtoon_editor/ is an entirely different thing from slot_icon.png in ui/rotation_editor/)

If the grid was applied to my current project, I think I'd stop using Quick Open for most tasks, because it would be harder to find what I want than just using Open -- I'd be looking at a soup of names that aren't necessarily distinct in the first 8-10 characters, unable to find what I want. I want ProjectileMissile.gd, but how do I quickly distinguish it from ProjectileKinetic.gd or ProjectileRailgun.gd?

I do think that the preview images are a good idea, but I would have preferred to see what @MrBBBaiXue proposed. No name/path information is lost or hidden, and the preview image is present for the resource types where it's actually helpful.

[Zylann]

I actually think that moving to the grid is a downgrade.

Please note this would be an option (not shown in screenshot, I guess not implemented yet?). Just like it is in the file explorer. Not everyone likes this presentation, and it indeed depends on the type of asset you are looking for. So you can leave it in list mode if you prefer. There could be thumbnails in both modes though, the grid mode can just fit more on screen.

[LunaticInAHat]

Please note this would be an option (not shown in screenshot, I guess not implemented yet?).

Indeed; I had skimmed past reading that that bit :) Sorry.

[stijn-h]

I have definitely not thrown away the list view! You can now switch between list and grid view with a click on a button. Definitely took a while, but it's possible without allocating any new nodes after editor startup 😃

And current grid view:

[LunaticInAHat]

I'm glad to see that List mode has been retained, and even more pleased by having the mode-switch in the Quick Open dialog, rather than as a project setting :) However I do want to point out that losing all the path information from List mode will still degrade the usefulness of Quick Open, for people who structure their projects the way I do.

[lentsius-bark]

I just found out about this. Multiple times in the past had I thought of this as well, I'm just so happy you went ahead and implemented such a fantastic quick open dialogue. My main inspiration for how it could be improved was also unity's version and viola, imagine my surprise seeing you had taken inspiration from there as well. Overall I believe this will greatly improve the editor UX when quickly looking for files. You're awesome @hinlopen

lastly, the fact that you've put both views is a cherry on top as either would have already been an improvement.

[seppoday]

Maybe adding filters would be nice too. For example. If u have alot of images and sound files. But right now you are only interested in scenes and scripts. You just use filters and they remember your settings. Everytime you use Quick Open shortcut filters are ON and they remember your settings. I can imagine that there are days where you don't even touch sound/sfx or font files.

Just a suggestion. Probably clear filters icon would be nice too.

or dropdown?

[YuriSizov]

Maybe adding filters would be nice too. For example. If u have alot of images and sound files. But right now you are only interested in scenes and scripts.

The purpose of the "Quick Open" dialog to use typing to do the majority of work. As such this looks like a good idea on surface, but in practice it's an unnecessary complication. Besides, we have a lot of resource types, there is just not enough space there to cover all the needs, someone will be left out, and the usefulness would be limited.

We discussed a similar problem for code completion grouping here: https://github.com/godotengine/godot/pull/38449 You can notice that I support it, but advanced features like that can deter from the core functionality of quickly finding something you need by typing.

If you want something with filters and advanced searching capabilities, I think it's better we have some asset dock to the editor. I've made a plugin for one here: https://github.com/pycbouh/godot-editor-assets-dock, but I also think it would be great to have something akin built-in.

[seppoday]

Maybe adding filters would be nice too. For example. If u have alot of images and sound files. But right now you are only interested in scenes and scripts.

The purpose of the "Quick Open" dialog to use typing to do the majority of work. As such this looks like a good idea on surface, but in practice it's an unnecessary complication. Besides, we have a lot of resource types, there is just not enough space there to cover all the needs, someone will be left out, and the usefulness would be limited.

If you want something with filters and advanced searching capabilities, I think it's better we have some asset dock to the editor. I've made a plugin for one here: https://github.com/pycbouh/godot-editor-assets-dock, but I also think it would be great to have something akin built-in.

Oh damn. That'a a nice addon. You are probably right. Better to keep quick open simple, and add all those cool features to asset dock/filesystem dock etc.

[hilfazer]

Maybe adding filters would be nice too. For example. If u have alot of images and sound files. But right now you are only interested in scenes and scripts. You just use filters and they remember your settings. Everytime you use Quick Open shortcut filters are ON and they remember your settings. I can imagine that there are days where you don't even touch sound/sfx or font files.

There are seperate Quick Open dialogs for scenes and scripts: Quick Open Script and Quick Open Scene.

[joao-pedro-braz]

Sorry to necromance this, but seeing as this is still open and the related PR is not yet merged (needs to be rebased), I think I might have something to contribute.

Some time ago I created a GDScript plugin (with some GDNative in Rust for the file searching) for Godot 3.5 which implemented a "Finder Window" inspired by CLion's (and basically all JetBrains IDEs) own "Find In" Window. If there's enough interest, I would like to port it to Godot 4.0 as a replacement for the current "Quick Open".

This is what it looks like:

One of the nice QoL features this has is being able to list script members (properties, signals and methods) and allowing them to be selected, which, when done, takes you directly to where they're defined, like so (the scroll is part of the plugin):

https://user-images.githubusercontent.com/37230465/230748631-4dbd3ad0-25b1-4491-8ae7-66fdb23a2170.mp4

Video Demo

Something that could be added for parity with the related PR, is the support for a grid-like listing, which shouldn't be that hard to do, but I currently don't have implemented.

I'm not sure about the UI though. I do think it looks nice, but I can see how someone would prefer the current one, given that it "fits" better with the rest of the Editor. At the end of the day, that's up for the community to choose.

Thoughts?

In case anyone's interested in the plugin's code: https://gitlab.com/joao-pedro-braz/godot-finder and https://gitlab.com/joao-pedro-braz/godot-finder-native

[thygrrr]

Draft 1 please unless we can see a preview icon.

[simonschreibt-code]

I would like to add to this, that I would love to see a more flexible search pattern with wild cards. So that I can type npc lion and it would list files like main_npc_shop_lion.tscn as well as npcLion_01.tscn and all other variants.

Because right now, I have to type exactly how the file is named and no wild cards like ` or*are allowed. A great inspiration is the quick search in Unreal Engine where it "just" works as described in the first paragraph ( ` is considered a wild card).

Another neat detail could be a small pin-button which, when activated, makes the dialog stay open after pressing enter.

[stijn-h]

@simonschreibt-code Are you on 4.x? Space is already a wild card there for a while. And it also works in this rework:

Pin button is interesting. I think ctrl-clicking would be more intuitive, but it could help with getting multiselect working again.

[simonschreibt-code]

@stijn-h Thank you for your answer! Yes, I'm on 4.2.2 but for me it does not work like in your screenshot :,( I open these dialogs via ctrl+p / ctrl+shift+o

[Toemsel]

Similar to VSC oder VS I would propose to search shaders and scripts to. A small code-preview as well. Could be something like this (sorry for my paint skills)

[aXu-AP]

I think searching inside scripts would cause too much wrong results (imagine searching for "forest.png" and getting all the scripts due to "for" keyword). Also it would likely slow down the search, which currently is very snappy. We do have "Find in files" functionality in script editor (altough it could be more interactive as well).

I think draft 2 from op with slightly more compact layout and icons would be my preference out of all the mockups and screenshots here.

[Toemsel]

@aXu-AP I strongly disagree on that. Other IDEs already have this feature built in and it doesn't pollute your search results with thousands of files. You require to introduce a rank by weight; the bigger the matching distance (e.g. Levenshtein) the higher the rank. Moreover, matches within filenames or signature definitions outweigh any match within a function block.

With your provided example for all scripts with that keyword would rank far worse than any file with the filename %for%. Regarding the speed: Parallelization, lazy-loading, populate over time,... there are many strategies to tackle this issue. One could even index everything before you hit the search bar.

[aXu-AP]

Hmm, it could work. But I think it's better to open a separate proposal for that, this being about the design of the dialog (additional functionality can be added later).

[stijn-h]

@Toemsel I think that could be a nice addition, but it will not be in the first version (which is more or less finished). I hope that once it is merged, the new dialog will be used more, and people will improve it and its integration within the editor.