forge and gradio4 compatibility

[graemeniedermayer]

Forge uses gradio version 4 which makes a number of breaking changes.

Some of the most noteworthy

• removal of gr.Box() replaced by gr.Group(). The padding and borders do appear differently maybe extra styling is need.
• file type must be binary instead for file loaders
• significantly the depreciation of update on components.

Removes the deprecated .update() method from component classes. Instead, you can now just return an instance of a component from your function. I.e. return gr.Textbox(lines=4) instead of gr.Textbox.update(lines=4)

gradio-app/gradio#6339

This led me to re-instantiating a number of components. Perhaps this can be further simplified.

I split off all the gradio4 files although maybe there's a clever way to fold them back in.

[semjon00]

Hello! Thank you for this effort, it is crucial that the extension will work even after A1111 starts using gradio4. Also, supporting forge is a nice addition. However, can not merge as-is, since this introduces a lot of code duplication. If it ever would be necessary to change GUI for whatever reason, we will need to change it in two different places. This is quite undesirable. There must be a different way.

For different argument(s), something like

if gradio4:
    box_args = {"yay", "extra"}
else:
    box_args = {"yes"}
gr.Box(elements, *box_args)

can be used, or:

if gradio4:
    box_arguments = lambda a: return {"file": a}
else 
    box_arguments = lambda a: return {"source": a}
localfile = ...
gr.Box(elements, **box_arguments(localfile))

For different objects, something like this:

if gradio4:
    import Box as box
else:
    import Group as box

box(...)

This works thanks to very convinient * and ** python operators. I believe this way we don't need to duplicate code.

[graemeniedermayer]

This is fair. I will do a rewrite later in the day.

gradio 4 update

Removes **kwarg from every component, meaning that components cannot accept arbitrary (unused) parameters. Previously, warnings would be thrown.

gradio-app/gradio#6339

But I think the first method will work in most situations.

[graemeniedermayer]

Okay I still think it requires a bit of testing but I did minimise a lot of repeats. (I also fixed a typo that's been annoying me for a while)

I also haven't tested it with all features, but it shouldn't interfere with older gradio3 users (still should test a little more)

[semjon00]

I gave the new code a quick glance and it looks nice. I will look more, test and then merge once I get back to the keyboard.

[semjon00]

I've noticed some issues

1. Batch inference is broken on gradio3, since run_generate expects paths for images, not bytes. Some other things that require files may also be broken. It is important to verify that the behavior under gradio3 and gradio4 would match as closely as possible. It is possible that we'll need to rethink how the output files would be named.
2. def update_default_net_size(model_type): -> if is_gradio4: uses value step, does it indeed modify the value? If I understand the documentation correctly, step modifies the granularity of the slider.
3. def update_visible_if_not(v): -> if is_gradio4: uses Column. The object modified is not necessarily a Column.

[semjon00]

@graemeniedermayer

[graemeniedermayer]

Thank you!

1. Ah I thought that bytes was just a re-labeling good to know it has different behaviour. Have to think about this more.
2. Very good catch! That should definitely be value.
3. You're right but it does seem to be working correctly (it's not recasting objects to columns). Maybe I'm using more objects types than is necessary.

Look like there's some more work to do.

[graemeniedermayer]

@semjon00 So I added fixes for 1+2. I didn't notice any issues with 3.

If you don't think this is ready to merge into main we should probably do a branch.

[graemeniedermayer]

Found another issue with my fix for 2

[tommcg]

I've been sort of lurking on this. Has there been any luck getting the extension to work with Forge yet? Thanks

[graemeniedermayer]

So in it's current state this pull request should work with Forge, but the last update break backwards compatibility so it now the pull request doesn't work with base auto1111. I'll try to fix it this weekend.

[graemeniedermayer]

@semjon00 could you give this another check. I tested it on auto1111 and forge and it seemed to work without issues.

[tommcg]

For clarity on my part -- I'm looking for a Depth tab across the top, right? I removed the old extension in Forge and then installed using git pull https://github.com/graemeniedermayer/stable-diffusion-webui-normalmap-script, restart, no tab. The old script also didn't show a tab in Forge. But the 'Depth' tab does show in A1111.

What did I overlook?

[graemeniedermayer]

You do need to switch to the specific branch.

Method 1. in the extension directory using a command like
git checkout forge-gradio4
this can get a little tricky depending on the setup.

Method 2. If you are using the extensions tabs install from url. You should be able to specify the branch,