I need a tester for a pre-release, preset manager version 2

[Gerschel]

I know I have some kinks with it, like does not work for mobile for dragging (I have a solution already), does not show the proper presets until changing tab at least once, that's an easy fix, but I wanted to hit a certain point first.
I will make the prerelease available either on the 19th, or 22nd. I will try to address some issues before then.

This post is to get some feedback on design, and get a few willing persons to see where it breaks. Right now my focus is getting my filters right, so it can relink and retarget on the poorly designed components. I'm considering doing another rewrite on a large section, if I catch some issues soon, I may be able to include them in the restructuring. I have 100 hours into this project, so I glazed over a couple of things, I'm sorry.

It does not work entirely like my first preset manager, where you could use a preset from txt2img on img2img. The presets are stackable, there is no reset, you'll have to save one in the settings yourself.

But with the cost of a full rewrite, losing the tab to tab feature between txt2img and img2img; it brings us to presets for all components on all tabs for all scripts, barring a few edge cases where someone wrote
a script that did not use element id's and used the same label more than once in the same script.

Here are some features.

It's draggable, it's a floating window:

It fades when not hovered over:

It collapses and expands:

It works on extensions, scripts, quicksettings and main settings:

[ClashSAN]

That looks very useful. You may want to ask @Harvester62 he tests very thoroughly all the extensions.

[Harvester62]

Hi @Gerschel I'm available to test your Preset Manager, let me know what would you like me to do. I should probably download it somewhere, right? I wait for your instructions.

[Nacurutu]

bro.. @Gerschel this is looking great... I would love to help you test it but right now I'm full of job stuff...

If I get rid of this job stuff soon, count on me...!

@Harvester62 test it as if your life depends on it xD

[Gerschel]

Thanks for getting him ready to drill me hard. Hahaha.

Well, I pushed it as a branch, I know for sure it has some issues, because I intentionally skipped touch and pen support, just so I can worry about the meat and potatoes, then I did minimal styling so I can see it better when it went transparent (bad eyes, developing it I still needed to see it), and just shoved everything in.

[Harvester62]

@Gerschel It might be a good thing if you could create a branch of this new version in your GitHub repository, so that I can switch, checkout to to this testing version without messing up with the currently installed one in my local installation of SD Web UI. Let me know.

[Gerschel]

Yeah. There are a couple of kinks that I know will fail, for instance, I used some mouse events instead of pointer events, so it doesn't work on touch devices. It's not a difficult swap, and would be dealt with before I would call it ready.
I am in the middle of seprating quicksettings and the main region in the saves. It means I'll need to change my data structure. Becasue of this disassociation, if it the save doesn't include a thing from both regions, just quicksettings, then it's not available, because it got filtered out, so I'll need to add in a reference.

But I also started another overhaul in another branch, that would dramatically change this structure.

[Gerschel]

Alright, I pushed a branch, version2demo

[Gerschel]

Umm, file names will be different, so it wont affect the your current presets, nor use them. This might mean that you see the python version and the javascript version.

[Gerschel]

This is the crazy part. Currently I use element id's to match up with the components. I also have classes that can handle the different input types. So I filter the gradio-config to get the element id's from the props, or from the instance, grab the type, create my handler for the proper type, and organize it by tab or quicksetting area. This is done by running up the parent tree until I hit the tab, while on the way up, if I pass the script container, I compare with the script list to so can name the script it belongs to.

This way, a script becomes a region too.

For the components that don't have a proper element id, I use their id in the gradio config, make an element id that will work for it and seek it.

But these fake element id's are temporary, so I had to create a way of finding the correct ones again.

When they are saved, they set a flag if it has a proper element id or not, if it does not, during load it uses the script name, tab name, and label to find the best guess.

If someone reuses the same element id in the same region, it wont work correctly. There may be other issues with shared element id's even if not in the same region.
If someone reuses the same label in the same region, it wont find the proper one, that's why I split it up by scripts and tabs.

This is also why I would like to subdivide an extension such as deforum, into regions based on it's children tabs. But I have to be very specific and write some exclusion rules, otherwise I might break presets on img2img's other tabs, since they share some components between them.

Here are things I don't like about this version.
Since I pulled it out from the tab and placed it in the quicksettings area (yes that's where it really lives), it can remain visible when flipping through tabs. But since it can expand so big and push the screen far, I pulled it out from the flow and made it a floating window.

This means, that no matter where you float it, it always feels in the way.

To compensate, I added the opacity change and tried making it go as small as possible.

It's also a pain when the scroll is so long, so I thought about subdividing the checkbox group into tabs. I don't have a clear decision on how this should be shown.

[Harvester62]

Thank you, I am currently at work, so I will look at your extension this late afternoon. I case of any doubt I will let you know.

[Gerschel]

I forgot to make it reset all to defaults when stackable is not checked.

[Harvester62]

Hi @Gerschel I started looking into your v2 extension, but I don't understand how it should work. (Current hash: SHA-1: bcb9b4cb037589571ea8be44d6064d980db6a29a)

I created a preset "testing1" but I don't see anything listed under Checkbox Group. Could you explain me how it's expected to work? Thank you.

First thing to notice (a good one) is that at SD Web UI startup there is no error message in the console, so it doesn't seem to be in conflict with other extensions/scripts.

FYI, I'm on Windows 10 Pro.

Surely, a floating thing is not ideal, not sure why you choose to implement the extension in this way. What is the advantage to have it as a floating box? Just asking to understand the usage workflow.

[Gerschel]

The checkbox group shouldn't be blank. If it is, then I need to investigate.

It should show the components of the settings you want to save. In these example images, I checked width and height, gave it a save name. It will save only those ones, which then allow you to toggle between 512 and 768, the two saves, without changing other settings.
This is what I call stackable, so a save can be for the prompt and checkpoint, and another the size, etc, for mixing. As you stack, the checkboxes should become checked, to give feedback to see which ones it affected.

In version one, I initally had it near "Sampling Steps", some wanted it under the gallery. With changes to sorting, it made sense to move it there.
If the manager lives in a tab, when a person changes tab, it will hide the manager. But if I put the manager in quicksettings, it stays visible on other tabs. If you look in devtools, you'll notice that's where it lives in the Dom.

I thought 'floating window', so they don't have a long scroll to get to the settings, and then back.
This is the kind of feedback I am looking for.

[Gerschel]

Okay. Something updated in the webui that broke it. I just did a git pull for a1111 webui, and I get this now.

I'm going to investigate. I might not be able to push an update today, I'm headed to work in an hour.

[Harvester62]

Great, thank you for your explanation and for investigating this issue. Yep, yesterday I couldn't do any testing because the UI was broken, but it was caused by the extension sd-auto-fix. After removing it the application worked again.
About the floating box, I think it's a matter of being used to it, and it can be collapsed and placed on top without being too distracting. Let's keep testing before you decide to do it differently.

[Gerschel]

Alright. I found two sources of the issue. I pushed a hackerfoo fix (meaning, it was a dirty way of coding it in, I can clean it up).

First was the quicksettings changed it's shape, I started the tree climb on element instead of parent of element.

Second, the "Styles" dropdown is not a dropdown, but it's instantiated as a dropdown, then modified to be an unordered list.

My component handlers read the gradio configs, and creates the proper handlers that the configs define them as, since "Styles" is non-standard, it was not assigned an appropriate handler. I wrote an exclusion for it, since it technically is the same type of tool as this one, but less advanced.

Honestly, it is inevitable that they will implement a settings tool that will be fully capable, other than experience, knowledge gained about the tools and codebase, this tool may become meaningless. I'm getting tired of just keeping something working, but the updates might settle down to release versions and I'll be able to keep extending it's utility more easily.

[Harvester62]

Hope I can get SDWUI back to work, because with the last git pull now it doesn't. This thing that one day it works and the next it doesn't is a little disturbing, but that's the nature of software development.

P.S.: Back on track, it was hypernetwork-monkey-patch extension's fault; I temporarily removed it from the \extensions folder and now the backend is working, not SDWUI fault, sorry.

Hmmm, I don't know but I still don't understand if I am doing something wrong because I don't see any changes in the floating box after your latest updates. And I continue not to understand how it is supposed to work, sorry.
Should I simply change some settings, add a preset name and save it?
How do I recall and apply a previously saved preset?
How do I delete a previously saved preset?
How do I know/see what a previously saved preset is affecting in the UI?
If "Stackable" is activated, and supposing that it will work, how would the stack of presets be managed?
Where there will be any way to add/remove a preset from the stack?

I am just trying to figure out how would I expect to see your extension to work, from a practical point of view, even if just with my imagination. I know, a lot of questions, but that's my role in this game.

[Gerschel]

Did the checkboxes not show up? Since it lives in a different branch, the webui might not have fetched it. It's working for me at the moment on the latest update sdwui update, could be it broke and unbroke.

The questions are fine.
These raise the idea of structuring it for better intuition.
It does not have a delete feature like version one does, this was an oversight.
If I have to explain how to use it, then I failed at making it make sense, so I will keep this in mind as a todo.

Stackable has an affect only during application of the setting, it makes no difference during the save.

The creation flow is as such:
A person adjusts their settings the way they want, they check the box for the items they want recorded, give it a name and hit save.
This adds the values from just those settings to the json file.

Adjust

Checkbox:

Give name and hit save:

The application flow:
A person makes a selection from the dropdown. Once they select it, those settings are given the value that was saved. The checkbox becomes checked as well. I figured this was a way for them to see that it took place. If stackable is checked and they apply another save, it will keep the previous checkboxes checked and add the new ones, while also updating the values. This allows them to save this combination as a new name if they wished.

If a person saves using a previous name, it will overwrite the previous save entirely, this allows updating a save, in case of elements labels being changed or element id's being added, or if they just decided that save should also affect more or less things.

The feature that is currently not implemented in this version, is when stackable is unchecked. What this is intended to do is, unselect all checkboxes, restore all values to default, then apply the single save by checking it's boxes and setting those values.

I think this defines the stackable and unstackable as, stackable allows overlaying one setting on top of another, to build the outcome you want, while unstackable is a reset everything so I don't have to play with their dials, and start at this point, and this point can be blank, so it serves as a reset, or switching gears. I think fixing the unstackable is my next priority.

I can make the affected settings show a colored border for a short duration, so there is more visual connection.

Having an undo last application, or undo this setting, sounds like a great feature.

Eventually I'd get to having notes for a save, maybe a thumbnail. I want this to become an overarching tool across the entire interface. But I need the base to be feature complete for what you would expect from the name 'Preset Manager'.

[Harvester62]

Thank you for your explanations and process description. Unfortunately, the checkboxes were not visible, but I will give it another try after the latest updates to SDWUI. I first have to checkout to the development version of your extension because I needed to reinstate the current version for translation purposes (to download a consistent language.json file). I will let you know if your v2 extension works as well as if I will have any other questions, suggestions or ideas useful to you.

[Harvester62]

Unfortunately, I haven't good news. As you can see from the attached screenshot, there is no checkboxes and the two saved presets don't have any effect when I select them in the floating box. I created two presets, one after changing the resolution to 704x512, and the second after changing the scheduler to DPM++ 2 Karras). I switched to the version2demo branch before starting the webui-user.bat file. I don't know if any of the active extensions might conflict with your extension, but there are no error messages in the console, as you can see.
Let me know if there is anything you wish me to do to help you.

[Gerschel]

This is crazy, it doesn't make sense. It uses vanilla js with a version supported by all browsers, and the most simplest python script so the webui can load the base components to build on. Nothing in devtools?

[Harvester62]

Sorry for my ignorance, but what do you mean with "devtools"? If you can provide guidance I will be willing to check whatever thing you might need to look at.
Current Commit Hash of my local SDWUI instllation is: c98cb0f

[Gerschel]

In the browser, there are tools to help development. One of the tools in it, is a console for JavaScript.
This console allows editing the website live, and looking at errors.
"F12" is one of the keyboard shortcuts to open the developer tools, it is also a part of the browsers settings dropdown menu.

I'm just realizing, that since you weren't aware of the conjugation, "devtools", this means you are translating. That might be why it works on my computer and not yours.

[Gerschel]

I think I will give up on this project for the meantime, until things settle down with the updates. I imagine there will be a point where it will have release versions. A tool such as this preset manager might not even be needed by then.
Thank you for your time.

[Harvester62]

I do understand the meaning of the term "devtools", but you didn't specified the context. Now I know It was related to the web browser. I do understand if you want to hold on the development of this project.