[Feature Request] Two Checkpoint dropdowns...

[vbmark]

One for non-inpainting and one for inpainting so that when going back and forth the one needed for the tab is already populated.

[Verszy]

Seconded. Many of our model lists are probably a huge mess at this point, full of base models, merges, intermediate merges that we're still checking on or just haven't got around to cleaning up (occasional personal failing,) inpainting models, and now even pix2pix models.

That in mind, this sort of request may wind up being a recurring thing as we find more ways to classify models into different niches. Perhaps instead of a one-off fix, we could have a change to quicksettings strings, allowing for sd_model_checkpoint[string], where [string] can be anything in a filename, including sd_model_checkpoint[inpainting] or sd_model_checkpoint[pix2pix]. This would allow us to not only cover the above cases, but also allow for personal categorization limited only by how many dropdowns we ultimately want crowding the top of the GUI.

[lendrick]

One for the highres fix would be nice as well.

[Gerschel]

You know everytime you change model, it loads the new one into gpu memory, so there is no have one for this and the other for that at the same time.
They do have a "hijack", which will switch the model out just before running.

Go ahead and look at your commandline console that your'e running the webui through, notice that it loads everytime you change models.

So, there is no such thing as two "already populated", you are loading gigs into memory, for every model. Load two at once, that's at least 8 gigs of your vram.
It's trivial to make it change model everytime you switch tabs, but everytime you switch tabs, it's going to take at least seconds per click. So the time you will save by not having to change it yourself, will be lost every click you do that changes a tab.

Now organizing, that's a different thing, that's not an issue. It's easy to display categories and filters. The question becomes, how do you want it filtered, how do you want it shown to you?
Do you want it available across all tabs (quicksettings area), or lives in a tab with filters specified for that tab.

By definition, everything in your ui across all tabs are present all at once, the other "tabs" is just some trickery by setting their display to none to make it appear that you are changing tabs, but it's just a button that says "hide all, now make these visible". (I realized this when I made the ui drag and drop sortable and it could drop on things hidden or drag from hidden to the visible).

[Gerschel]

I understand.

[Gerschel]

So. Which layout do you think makes sense.

A single dropdown that changed it's list with a filter, filter being dependent on tab. Or a setting that says produce another dropdown, but with this filter.

[vbmark]

If it's a single dropdown that changes based on the context, there really should be two dropdowns where the content gets loaded into each list once on load. This way it's not reloading each time you switch context.

When you do switch context, one dropdown is hidden and the other unhidden. Then the recently unhiddend dropdown with the unloaded model needs to be grayed out to indicate that it is in an inactive state and you must click the load button. But even though it is grayed out, you can still change to a different model but it's still not loaded until you want it to be.

You could even make it so that if the model is not yet loaded for the tab you are on and you hit Generate, then the model loads automatically. How nice would that be?

[Gerschel]

@vbmark @Verszy
Paste this demo concept in to your browser devtools javascript console.
Currently it's a dirty implementation. It does not actally change the list, but filters the display of it. Treat the input like a search that does not need you to hit enter.
It might not work if you type fast or paste in, it's just a demo, I slapped it together in a couple of minutes.

It creates a text input just after the refresh button, jacks the classes from the prompt, not a good idea, but was a quick way to get some closely matching style.
Creates an event listener, that calls to hide or unhide options in the dropdown on every key stroke.
The elements still exist in the dropdown, that way the index of the front-end and back-end still match up to the model name.
Should work with wildcard *, so ss*A would match "classicAnim", not caseSensitive.

let myInput = document.createElement("input");
let modelDropdown = gradioApp().getElementById("setting_sd_model_checkpoint");

myInput.classList = gradioApp().getElementById("txt2img_prompt").querySelector("textarea").classList;
modelDropdown.nextElementSibling.insertAdjacentElement("afterend", myInput);
let selectOptions = modelDropdown.querySelectorAll("select option");

myInput.addEventListener('input', function() {
  let inputValue = this.value.toLowerCase().replace(/\*/g, '.*');
  let regex = new RegExp(inputValue);

  selectOptions.forEach(option => {
    if (option.innerText.toLowerCase().match(regex)) {
      option.style.display = 'block';
    } else {
      option.style.display = 'none';
    }
  });
});

[vbmark]

The textbox was created but the event listener isn't working; typing (slowly) does nothing. But I don't want to type anyway; I want to see the list.

Maybe just do the two dropdowns side by side and prepopulated. That will work.