POC: Updating loras on the fly.

[Symbiomatrix]

Hello dominik, it's been a longstanding peeve of mine that the ui must be restarted to see newly added loras in autocomplete.
Apparently, merely updating the lora.txt file and the global loras variable is all it takes to refresh the list, no restart needed (at least on vlad's fork). So I added a couple crummy ui buttons and copypastad functions, and it seems to be working almost without a hitch (I think the button's js call doesn't wait for the file to update, so possibly need a timer to combine that).
I'm also using a slightly modded version which has direct instead of relative paths and gradio's circumvented to allow said path, but if that's all it takes to enable this feature, then I think it's imperative to find a way to do that.
Penny for your thoughts?

[DominikDoom]

I'm not a fan of having active UI elements for Tag Autocomplete, IMO aside from the settings it should stay purely passive and automatic. The main page scripts section is cluttered enough for most people already. Also, there already is a refresh button for loras in the builtin extra networks tab - preferably there would be a way to use that instead. I'll take a look at it.

In the meantime, if you reload the UI by clicking the buttons at the bottom of the page or in the settings instead of closing the whole terminal window, it only takes a few seconds and also reloads everything else beside Loras that might have changed. So I don't think it's that bad.

As for the paths issue, that is something entirely separate. It's a common pain point, but I can't add features that rely on a modded Gradio for obvious reasons. The (relative) paths I use by default are provided by the webui itself.

[Symbiomatrix]

Thanks for considering it.
I don't think there is a good way of detecting file changes automatically beside needlessly flooding requests periodically. Files can be transferred to the directory in any number of ways.
I added the button to the main ui because I'm an extremely lazy sod and already had the code for buttons in the ready, and I don't fancy changing screens too often - I'm mostly in the txt2img screen so that's where I put it. Another approach would be to add a setting for the same functions (not sure if a button is permitted, but a placeholder checkbox would do the trick just fine too), then to quick settings - even better for me, actually. Lemme see if I can do that.
About the refresh button, I have a great deal of reservation about this:

1. Not sure if gradio grants access to change already allocated components (since the ui doesn't save the reference outside the function scope, last I've checked). Had some bugs with that even when using the standard approach.
2. The refresh button is extremely slow if you have a bunch of loras, presumably because it reads metadata and reconstructs html gui, which I don't need anyway because autocomplete does the job better.
3. That's an extra button to press, to show extra networks (or two since I have to close it again).

I'm on vlad's fork, no such reload buttons at the bottom of the page that I can see. I reload through settings' apply + reload. And in any case, if they still reload the entire page (ie wipe all main settings to default), it's quite an inconvenience.

Sorry, perhaps I was unclear - I wasn't saying the paths issue should be fixed (well, at least it'd take more effort than it's worth to fix it for everyone), but rather that I'm not 100% sure whether my fix works on the vanilla extension.

Also, and I don't mean to sound overbearing, but as my former teacher often said - KISS! If you can add a slightly imperfect QOL feature without too much hassle or clutter, it's better than not having it at all. You may not realise how much of a difference it would make. (And it's not like we're billing for the time, eh.)

[DominikDoom]

Gradio doesn't expose such functionality directly, but Python allows function hijacking. I did a quick and dirty test and something like

def on_app_started(*args):
    try:
        import ui_extra_networks_lora
    except ImportError:
        return

    # Hijack refresh function of the extra networks page to update our temp file alongside
    def hijacked_refresh_lora(*args, **kwargs):
        if LORA_PATH is not None and LORA_PATH.exists():
            lora = get_lora()
            if lora:
                write_to_temp_file('lora.txt', lora)
        hijacked_refresh_lora.original(*args, **kwargs)

    hijacked_refresh_lora.original = ui_extra_networks_lora.ExtraNetworksPageLora.refresh
    ui_extra_networks_lora.ExtraNetworksPageLora.refresh = hijacked_refresh_lora


script_callbacks.on_app_started(on_app_started)

would indeed work to use the builtin refresh button. It injects the new code and then calls the original afterward. So just the js part would have to listen to changes there and reload after it's done.
But I agree that a faux settings button would be better for performance, at least for the first time opening it really is quite slow.

The reload button I was talking about is this one in the default UI footer:

the Apply and restart in settings does pretty much the same, so the same limitations apply like you said.

[Symbiomatrix]

Oh, that's right, you have those event listeners for applysettings and quicksettings, so that'd take care of the js side if the _js attribute can't be hijacked directly.

Yep, I've seen it in an issue before, but no footer for this guy. Either vlad's omitted it or I've broken it, most likely.

[DominikDoom]

I tried around for a bit with the built-in gradio components, I think I found the best way to do it.

shared.opts.add_option("tac_refreshTempFiles", shared.OptionInfo("Refresh TAC temp files", "Refresh internal temp files", gr.HTML, {}, refresh=refresh_temp_files, section=TAC_SECTION))

This will create a non-interactible settings component but give it a refresh button like the webui uses for dropdowns, so it functions as a standalone refresh button with a label. This is more useful than adding a custom button since the webui already has the fixed refresh button style etc. provided, making it more consistent.

It even shows a "something is happening" animation, although I'm not sure if that actually depends on the runtime of the refresh function:

chrome_2023-05-26_15-26-47.mp4

Either way, this both works in the normal settings as well as in the quicksettings. The only downside is that there's no good way to tell when the refresh is done, so for now I just have the javascript side update after a fixed 2 second timer. If the "pending" fading animation is runtime dependent, I might try to listen to HTML changes to see when Gradio removes the class again, but for now I think this is good enough.

I pushed it on the https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/tree/feature-refresh-temp-files branch, please have a look if it fits your needs (and if it works on vlads fork).

[Symbiomatrix]

It may well be the only way currently. I've had a chat with vlad, and though the optioninfo are accessible & alterable, it seems that the settings components are only constructed in ui locally, so we can't add any custom events (like mapping the js function to a button), and even then vlad says the js runs before the python mapped function so it's out of order for us.

Edit: Huh, where's the part that actually reloads the loras etc from the files? The js seems to just be setting them to empty lists? Oh, I see, process queue.

Embeddings not in the refresh list?

[DominikDoom]

I grab the embeddings directly from the webui dictionary, to get info about whether they are a SD 1.x or 2.x based embedding. It's a bit tricky to include in the same function since they aren't available at startup. But model change will already update the temp file, I just haven't included it in the js part yet because of that. I plan to add it in a bit though.

[DominikDoom]

Should work now. But it still depends on the internal dict of the webui, so it will update only after a model change, manual refresh in the extra networks UI, or (I think) when the prompt is parsed & validated before starting a generation. So our button alone is not enough.

Also, I somehow missed that I mistyped the query selector in the initial commit, the changes weren't updated in the javascript at all since the function never got called, lol. I only checked if the files itself were updated earlier.

[Symbiomatrix]

Job well done, sir. Works perfectly as described and certainly much more elegantly written than I could've done. Much obliged.
The embeddings are of a far lesser concern, I think - they've rather fallen out of favour.
Aye, that extra "refresh_" is kinda weird. Isn't in the original id. I guess it's automatically prepended in the corresponding refresh button of the setting.
I'll go ahead and close this one.

Edit: By the way, might want to label that button a bit better for the users. : )