Enhanced `gr.Dropdown` for 1000s of entries

[space-nuko]

• [x] I have searched to see if a similar issue already exists.

Is your feature request related to a problem? Please describe. I'm getting to the point where I have 100s of models to choose from in a gr.Dropdown just from the past few days, and I think navigating through it is going to become so much harder in the coming weeks if I don't prune anything. gr.Dropdown is very unwieldy to use with a lot of elements but it currently seems like one of the few browsable components for what I need to do - pick from many different options in a togglable scrolling window

Describe the solution you'd like
A massively souped-up version of gr.Dropdown specifically designed for efficiently scrolling and filtering a lot of entries with an optional preview image. It would take up a lot more screen space than gr.Dropdown. A good example of what I want is the stable-diffusion-conceptualizer, but more compact and in a drop-down format.

I think it should be switchable between list and grid views, and have nestable subsection headers (like folder name) that can be folded/unfolded to save scrolling space and improve performance, similar to #2951. It should definitely have a textbox for filtering like #1094. Maybe even a tooltip on hovering each element too, to show things like model metadata

When the component is constructed, e.g. from the results of a directory scan, you should be able to do things like scan for a preview/"cover art" image in a folder of several different models from the backend and apply them to all the entries in that folder, or read an embedded image in each model and use that instead. It should be flexible enough to support many different ways of constructing the nested list structure

Also, and I don't know if this is feasible, but making sure the performance stays acceptable by not rendering hidden/search excluded entries

[freddyaboulton]

Thanks for the detailed ticket @space-nuko ! Seems very related to #2951 - Thoughts closing #2951 in favor of this issue?

I agree that Dropdown can be enhanced to support many possible options. We will be working on a workflow for custom components this year so hopefully this kind of enhancement can be made by the community soon!

[space-nuko]

Proably can yeah, I don't think having Dropdown headers alone can solve the issue of having 1000s of entries to scroll through

[space-nuko]

Also does there happen to be a tracking issue for the custom components feature, I would like to be informed of any updates for that

[aliabid94]

Hmm maybe we should use the Dropdown("multiselect=True") UI version of Dropdown even when multiselect is false, because that version allows typing to filter many choices. @dawoodkhan82

[dawoodkhan82]

@aliabid94 I'm in support of that. Can also look into adding section headers.

[abidlabs]

+1

[abidlabs]

Some related suggestions by @hysts

1) I also think it might be useful if we could type a few characters in a dropdown menu to filter items 2) I was also thinking it would be nice if gr.Dropdown accepted user inputs

I think having the multiselect UI would solve (1). For (2), we could add a parameter that lets people supply their own values. I had initially just suggested this approach:

import gradio as gr

with gr.Blocks() as demo:
    d = gr.Dropdown(["Choice 1", "Choice 2", "Other"])
    t = gr.Textbox(visible=False)
    d.change(lambda x: gr.Dropdown.update(visible=x=="Other"), d, t)

demo.launch()

However, @hysts brought up a good point:

But in that case, we have to pass both d and t to the function that was using d and add a few lines of code inside it to check if d is Other, right? Personally, I would like to keep my function as simple as possible and don't want it to be affected by GUI.

[abidlabs]

Hey! We've now made it possible for Gradio users to create their own custom components -- meaning that you can write some Python and JavaScript (Svelte), and publish it as a Gradio component. You can use it in your own Gradio apps, or share it so that anyone can use it in their Gradio apps. Here are some examples of custom Gradio components:

• A "Rich Textbox" that allows you to write bold/italics/colored text
• A "Folium Map Viewer" component that allows you to use interactive maps

You can see the source code for those components by clicking the "Files" icon and then clicking "src". The complete source code for the backend and frontend is visible. In particular, its very fast if you want to build off an existing component. We've put together a Guide: https://www.gradio.app/guides/five-minute-guide, and we're happy to help. Hopefully this will help address this issue.

[abidlabs]

I'll go ahead and close this issue since we are not planning to include this in the core Gradio library. But happy to help if you are interested in making this a custom Gradio component (feel free to ask questions in this issue).