Settings' Options functions (_js).

[Symbiomatrix]

Hello @vladmandic . We're trying to add refresh without reset to dominik's autocomplete, and I can't quite tell whether this is possible:
Does Options / OptionInfo currently allow mapping events beyond basic onchange / refresh? Or rather, can a js function be mapped through onchange or otherwise (some form of hijacking)? I've only seen js functions being mapped through direct event mapping via _js parameter. Listening on on the js side seems possible but a bit of a hassle.

[vladmandic]

i haven't tried, but this should work...

typical use of optioninfo:

options_templates.update(options_section(('system-paths', "System Paths"), {
    "temp_dir": OptionInfo("", "Directory for temporary images; leave empty for default"),
}

and now with hijaack

my_option = OptionInfo("", "Directory for temporary images; leave empty for default")
my_option.component.change(fn=None, _js="my_js_function", inputs=[], outputs=[])
options_templates.update(options_section(('system-paths', "System Paths"), {
    "temp_dir": my_option,
}

[Symbiomatrix]

@vladmandic I'm not sure I follow. Isn't OptionsInfo just a storage class? It has an __init__ but nothing else. The component is specified, but isn't actually created until someone goes ahead and reads the info. Unless that's done within the OptionInfo itself?
Oh, I see it now; it's in with gr.Tabs(elem_id="settings"): segment. There's a components list which is constructed iteratively from opts.data_labels.items()), but it's not getting stored anywhere nonlocally, so looks like a dead end.

Thanks for your help, as always.

[vladmandic]

if you pass component as arg to consturctor, its just assigned in init, there is no post-process creation - that applies if you dont pass component so it tries to autodecide component type

[DominikDoom]

Thanks for answering those questions. I also think that it's a dead end, but just to shed some light on why we need this in the first place:

Tag autocomplete is almost entirely client side since it heavily requires live DOM manipulation. I need to intercept input events, show a standalone UI component, and insert text back into the prompt field.
For a lot of additional features like completion of embeddings, loras, etc. I need info about local files. But for security reasons Gradio only allows direct fetches and has no way (at least none that I found) to list local files or directories. So I need to know the paths beforehand. My workaround for this was a python helper script that can look for those files locally since it's on the server side, and writes all those paths/names to temporary files. Those temp files have a known path, so I can load them in JS to then fetch the actual files or get their names for completion. Sort of like fake API endpoints for my extension that only show cached data.

If something changes and the user wants to refresh them, the server side needs to run first to update those temp files, and then the javascript part has to re-fetch them. This is the actual issue, we need a way to notify / call that JS function after the refresh is finished, so we can avoid fixed timeouts or complex listeners. But obviously Gradio wasn't intended for this purpose.

[vladmandic]

ok, now i understand what you need - better than trying to do what you want :)
i would solve this completely differently.

note that getting file list (updated or not) does not help you since you have no idea what works or what not. for example, embedding has to be loaded into server to be able to use it in prompt, so dropping a file in embeddings folder means nothing unless server performs a refresh.

and that refresh already exists - button in extra networks ui. you can even trigger it progamatically from js if you want - gradioApp().getElementById('button_id').click()

and then you need actual list of embeddings/loras/whatever in your client - why not do a simple fetch call in js and get it from server api?

btw, any solution that requires creation of temp files like you suggested is probably sub-optimal.

[DominikDoom]

At what time the webui itself refreshes the info is irrelevant to the autocomplete extension, it operates pretty much on its own.
It really is just to provide quick completion, whether it will work in the prompt or not isn't of concern for the most part.
For embeddings, I do get the shape info from the internal dict though, to display info about if they are SD v1.x or 2.x embeddings.

Actually, since the webui updates a lot of stuff like available Lora, embeddings, etc. at prompt validation too, most of the time just dropping in the file without manually refreshing in the extra networks tab works fine from what I've seen. We avoided just using that refresh mainly since refreshing the visual list makes it really slow if you have a lot of embeddings or Lora, especially with high-res preview pics. But which part of the UI triggers the refresh is pretty irrelevant in the first place.

I agree that temp files aren't the prettiest solution, but with the limitations given by gradio and the webui extension system they were the best option at the time.
For some more context, tag autocomplete was a thing way before the webui had an API, even before the extension system existed. And it also needs to work without the --api flag. So just fetching the provided API endpoints won't work (and for a lot of our use cases there just are no API endpoints in the first place, e.g. it also works for special formats added by some third party extensions). I could probably add new API endpoints for everything that I need, but I feel like that creates a lot of technical debt to do essentially the same thing as the temp files are already doing.

But even if I fetch from a proper API endpoint I would still have no way to know when the manual or the extra networks refresh actually is done, so we would still have to wait or use listeners in the js part, right?

[vladmandic]

ok, now wer're talking about silly workarounds - it would be easy to create something that would work cleanly for you, but then you wouldn't be compatible with other forks.

for example:

def refresh_data():
    # fetch filenames from folders and just put everything together as a json and dump it to str
    return text

btn_refresh_data = gr.Button(...)
text_data = gr.Text(..., visible=False)
btn_refresh_data.click(fn=refresh_data, _js="request_data", inputs=[], outputs=[text_data])
btn_send_data = gr.Button(..., visible=False)
btn_send_data.click(fn=None, _js="send_data", inputs=[text_data], outputs=[])

and in js:

const request_data = () => setTimeout(() => gradioApp().getElementById('btn_send_data").click(), 250));
const send_data = (data) => { ...whatever you want here... };

actual data is is passed via hidden gradio textbox and you have separate refresh and send buttons so send to js event can happen after refresh.

[DominikDoom]

Haha yeah that is definitely silly - but not that much more than some of the stuff I already had to do to work around Gradio limitations and version differences. I'll take a look at it and see if it fits my needs, but either way, thanks for taking your time to answer these questions.