[Feature Request]: Add option to go back to old non-tree Extra Networks view

[CounterfeitMonk]

Is there an existing issue for this?

• [X] I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

Feature #14588 changes the view for Extra Networks and removes the previous view completely. It does not look very good with how it truncates filenames and reduces entries on browsers not on full-screen (see screenshot). Additionally, it adds "more clicks" to the workflow than the previous view.

Can there be a setting added to let us go back to the pre-Tree view from before v1.8.0?

Proposed workflow

1. Go to Settings > Extra Networks > [ ] Use legacy Extra Networks view
2. Reload UI
3. Extra Networks tabs go back to the pre-v1.8.0 view.

Additional information

No response

[rkfg]

The second button from the right enables/disables the tree:

[MNeMoNiCuZ]

The second button from the right enables/disables the tree:

Yes but then the way to browse the folders which used to be at the top is gone.

I have a similar request, but it's from a performance point of view. I don't know if it's ACTUALLY because of the tree view, or something else that was introduced at the same time, but it's nearly useless when you have 1.000 checkpoints or 10.000 LoRAs. If you have this many models, and you try to type-filter a name, it takes about 1 minute for it to finish filtering. It's near-instant before this update.

Even switching to the "Checkpoints"-tab, now it takes 5-10 seconds before any link becomes clickable on the page, meaning the page is restructuring/refreshing something to the point of being unresponsive meanwhile.

The same happened in Forge which had this update included a while back. Reported here: https://github.com/lllyasviel/stable-diffusion-webui-forge/issues/220

[Dasor92]

Yes please, add the option to let us see buttons for filtering, the tree view is pretty much unusable with 2k loras

[jonk999]

Another vote for having the option of using the old directory buttons. Much more intuitve and easier to use for myself and the way I have my Loras, etc organised.

[Westernnero]

Agree! I'd like to say I prefer the legacy one. Now the 'tree' itself takes up lots of space and I feel harder to locate and filter my Loras. TBH I have don't have so many layers in the tree and the structure of those Lora folders is kinda 'flat'. The buttons are more intuitve I reckon.

[MNeMoNiCuZ]

But remember: It's not just a matter of the UI here. The whole "Extra Networks" tab is performing much worse than before. I think there's some underlying structure that's been heavily modified into oblivion as it is.

I'm not sure where to start looking at it. Any insights and maybe I can help debugging.

[Sj-Si]

But remember: It's not just a matter of the UI here. The whole "Extra Networks" tab is performing much worse than before. I think there's some underlying structure that's been heavily modified into oblivion as it is.

I'm not sure where to start looking at it. Any insights and maybe I can help debugging.

I'm looking into the problem. If you're also interested, look in modules/ui_extra_networks.py, javascript/extraNetworks.js, and their respective HTML templates in the html/ directory.

[kaalibro]

@Sj-Si I guess the best approach would be to rollback and implement this feature as an extension.

I've rolled back #14588 in my fork and applied all subsequent commits up to eee46a5. I'm unsure if I should submit a PR, but you might find it helpful if you decide to follow my advice.

I've also noticed that sorting by "Path" doesn't function the way it did previously. And SVG icons, unlike emoji symbols, cannot be replaced in UI extensions like Lobe Theme.

[MrKuenning]

I wouldn't mind if it was just a vertical folder tree. But it should be expanded to the root list of folder by default, and there should be an option to not show the models in the tree.

I have wide monitors and never liked how the old buttons sorted sub folders at the end of the list. I like the idea of a vertical folder tree. But there are so many confusing choices and bugs with this current implementation.

• Its not expanded by default, so you have an extra click just to see the folders Not the tree view itself, the root folder

• It auto expands every folder you click on. They should only expand if you click the arrow next to them. It makes the screen cluttered and makes jumping between folders slower.

• It doesn't display checkpoint folders at all if you are redirecting to a different model location https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/15096

• The Tree box is fixed % width and uses up a lot of screen space on my monitors.

---

These things should be easy fixes and would probably make most people happy. There is currently a setting to

• [ ] enable the Extra Networks directory tree view by default

There should also be settings for:

• [ ] Expand root folder by default
• [ ] Hide models from tree view

The area should be drag resizable

[Vesperindustrial]

Also a suggestion for not showing everything in every subfolder under a given directory would be probably helpful in dealing with performance as well, it should act like every other file browser does and only shows the loras at the level currently selected. If one wants to search one folder or everything in a folder that should be separate. This would in fact be very helpful regardless of whether one uses the tree view or the old (imo unintuitive when you actually have more than 1 level of sorting) view.

However i find it strange that this seems to be a performance issue at all, the tab is not inherently doing more than showing thumbnails and a little bit of text. I assume no actual loading of items into memory is occurring until a prompt is actually calling for it, since you can drop a new lora into the lora folder and call it in a prompt without clicking refresh on the lora tab. So is there actually more steps going on behind the scenes that maybe could be looked at?

[MNeMoNiCuZ]

Regarding performance: I did not notice any issues when setting up my forge, when I had just a few test models in. But when I loaded my entire library, I got severe performance issues as mentioned in my previous post. It takes 5-10 seconds for the page UI to be responsive, and typing in the filter box adds a single letter, then filters all the models, and then does the next letter. So it can take up to a minute to "type" a word (you can paste in just fine).

So I suspect something is checking it constantly.

Additionally, it's also sorting weirdly for me, almost like reversed by folder name, meaning in my root LoRA folder, all models in a later letter shows up before earlier letters. But this was an issue before the tree view.

[Sj-Si]

@kaalibro

@Sj-Si I guess the best approach would be to rollback and implement this feature as an extension.

I've rolled back https://github.com/AUTOMATIC1111/stable-diffusion-webui/pull/14588 in my fork and applied all subsequent commits up to https://github.com/AUTOMATIC1111/stable-diffusion-webui/commit/eee46a5094f748ebe9fe4978b0d440a8ebbab4a6. I'm unsure if I should submit a PR, but you might find it helpful if you decide to follow my advice.

I'd say put in a PR for it. It would at least give me time to rewrite this stuff and fix the problems. How did you roll it back by the way, did you just manually revert my commits or what? I've never reverted a merged PR before so I don't know the best process for that when Github can't automatically revert it.

I've also noticed that sorting by "Path" doesn't function the way it did previously. And SVG icons, unlike emoji symbols, cannot be replaced in UI extensions like Lobe Theme.

I hadn't thought of the SVG thing. What would be a better approach? Should I instead store the icons as files locally and reference those? That way people making themes could simply swap out those files for something else.

@MrKuenning

I wouldn't mind if it was just a vertical folder tree. But it should be expanded to the root list of folder by default, and there should be an option to not show the models in the tree.

Do you mean that all directories should just be expanded? Or only the root level directory should be expanded?

I have wide monitors and never liked how the old buttons sorted sub folders at the end of the list. I like the idea of a vertical folder tree. But there are so many confusing choices and bugs with this current implementation.

Yeah haha this was really my first time messing with HTML/CSS/JS so I was trying to make it as robust as possible but I guess it didn't quite work out.

@Vesperindustrial

Also a suggestion for not showing everything in every subfolder under a given directory would be probably helpful in dealing with performance as well, it should act like every other file browser does and only shows the loras at the level currently selected.

Yeah I wasn't really sure how I should handle this one. I thought it might be unintuitive if someone were to click on a directory and not see all of the models in subdirectories. For me at least, I want to see all subdirectory models and I can drill down further if I want to narrow the set of results.

However i find it strange that this seems to be a performance issue at all, the tab is not inherently doing more than showing thumbnails and a little bit of text. I assume no actual loading of items into memory is occurring until a prompt is actually calling for it, since you can drop a new lora into the lora folder and call it in a prompt without clicking refresh on the lora tab. So is there actually more steps going on behind the scenes that maybe could be looked at?

Honestly I don't have any performance issues and I have hundreds of models/loras. However I did create 10,000 files to populate the list and it does definitely slow down. At the same time, if you have 10,000 models then you need to clean up your files or something or don't save your model every step of training.

The performance is just caused by an insane number of HTML nodes being redrawn or something. I'm still investigating the cause of the problem but I'm struggling a bit. I'm trying to find some way of reducing the number of elements in the DOM by dynamically loading elements when scrolling through the lists. Either way, I don't know why the previous version performs better with the same number of models. I've even totally removed the tree view from the page and it still performs slower than before even though everything should be practically the same.

@MNeMoNiCuZ

Regarding performance: I did not notice any issues when setting up my forge, when I had just a few test models in. But when I loaded my entire library, I got severe performance issues as mentioned in my previous post. It takes 5-10 seconds for the page UI to be responsive, and typing in the filter box adds a single letter, then filters all the models, and then does the next letter. So it can take up to a minute to "type" a word (you can paste in just fine).

In my attempts to fix these problems I updated the filter textbox so it only actually performs a filter after ~500ms of not typing. Previously it was just applying the filter on every key press event.

[MNeMoNiCuZ]

Thanks for the update and it looks like good solutions.

Regarding the 10k models: These are not my checkpoints, I just have a very large finely curated list of downloaded models :) It's a lot of course, but the tool should provide a solution to it. Whether that is pagination or something, to make sure that it's a smooth experience.

Before 1.8 it was smooth. I could filter the list near-instantly, and switch tabs instantly. Like it still took a few seconds for 10.000 thumbnails to load, that's totally fair! But something changed here to make it a pain to even consider switching models. It was the only real drawback to switching to Forge for me.

Keeping in mind I also have all models sorted in careful subfolders, so my subfolder list was huge the way it was displayed before. I think the tree view is a good improvement to it, except that it takes up so much permanent screen space compared to the folder-labels before. They would only take up space at the top of the screen. As it is right now, I navigate with the folder view, then close it, to make it not take up 1/5 of the screen-space. A bit tedious and frustrating for sure. Especially considering toggling the folder view also takes ~2 seconds with my list.

[Sj-Si]

Thanks for the update and it looks like good solutions.

Regarding the 10k models: These are not my checkpoints, I just have a very large finely curated list of downloaded models :) It's a lot of course, but the tool should provide a solution to it. Whether that is pagination or something, to make sure that it's a smooth experience.

Before 1.8 it was smooth. I could filter the list near-instantly, and switch tabs instantly. Like it still took a few seconds for 10.000 thumbnails to load, that's totally fair! But something changed here to make it a pain to even consider switching models. It was the only real drawback to switching to Forge for me.

Keeping in mind I also have all models sorted in careful subfolders, so my subfolder list was huge the way it was displayed before. I think the tree view is a good improvement to it, except that it takes up so much permanent screen space compared to the folder-labels before. They would only take up space at the top of the screen. As it is right now, I navigate with the folder view, then close it, to make it not take up 1/5 of the screen-space. A bit tedious and frustrating for sure. Especially considering toggling the folder view also takes ~2 seconds with my list.

Yeah when I revise this code I'll do something to add the old style of buttons as well as allow resizing the pane. HTML really isn't my forte so trying to figure out why this is all so slow is a bit difficult for me.

Out of curiosity... how much disk space does 10k models take up?

[MrKuenning]

@MrKuenning

I wouldn't mind if it was just a vertical folder tree. But it should be expanded to the root list of folder by default, and there should be an option to not show the models in the tree.

Do you mean that all directories should just be expanded? Or only the root level directory should be expanded?

Just root for starters. Instead of Seeing

> Lora I would like the lora folder to start expanded

- Lora 
 > Environment
 > Etc...

I do have subfolders, and don't mind expanding to go down a layer or too. But it seems useless to have the root folder collapsed by default.

Out of curiosity... how much disk space does 10k models take up?

For me I only have about 4k Loras but it takes up about 380GB

[a3nima]

The old view with buttons in a row for the existing folders acting as a filter, is what we're talking about here? because I've gone mad searching to activate that function again, cause I thought I had enabled it sometime ago, but it's gone, correct?!

[MNeMoNiCuZ]

The old view with buttons in a row for the existing folders acting as a filter, is what we're talking about here? because I've gone mad searching to activate that function again, cause I thought I had enabled it sometime ago, but it's gone, correct?!

Yes, the old row of folder-buttons which sent that folder-name to the filter box is gone. Bringing them back is the request.

[MrKuenning]

The old view with buttons in a row for the existing folders acting as a filter, is what we're talking about here? because I've gone mad searching to activate that function again, cause I thought I had enabled it sometime ago, but it's gone, correct?!

Yes, the old row of folder-buttons which sent that folder-name to the filter box is gone. Bringing them back is the request.

There is an extension that does this. https://github.com/Haoming02/sd-webui-boomer

[kaalibro]

@Sj-Si

How did you roll it back by the way, did you just manually revert my commits or what? I've never reverted a merged PR before so I don't know the best process for that when Github can't automatically revert it.

I'm unsure if it's possible to make this automatically)) So I took the following steps:

• Examined the changes made in #14588
• Reverted each file to its previous commit.
• For each file, I reviewed the change history up to the most recent commit and manually incorporated alterations unrelated to the tree view.

I hadn't thought of the SVG thing. What would be a better approach? Should I instead store the icons as files locally and reference those? That way people making themes could simply swap out those files for something else.

The simplest and most dependable way is to use emojis since they are merely a collection of characters.

Honestly, I felt a bit uneasy suggesting a rollback :) I see the considerable effort you and other contributors have invested. However, the legacy display method proves to be more convenient for many users (myself included). Therefore, I believe implementing as the extension is indeed could be a fitting solution.

[MNeMoNiCuZ]

The old view with buttons in a row for the existing folders acting as a filter, is what we're talking about here? because I've gone mad searching to activate that function again, cause I thought I had enabled it sometime ago, but it's gone, correct?!

Yes, the old row of folder-buttons which sent that folder-name to the filter box is gone. Bringing them back is the request.

There is an extension that does this. https://github.com/Haoming02/sd-webui-boomer

I tested this, and it doesn't quite do it. The slowness that was brought on with 1.8 is still there. Additionally it doesn't bring the old folder/breadcrumb interface back for me (not in Forge at least), even after I turn the option on.

It does however fix the file path sorting. Instead of putting a folder named "Z" at the top, it now puts it at the bottom as it should be.

[MNeMoNiCuZ]

Thanks for the update and it looks like good solutions. Regarding the 10k models: These are not my checkpoints, I just have a very large finely curated list of downloaded models :) It's a lot of course, but the tool should provide a solution to it. Whether that is pagination or something, to make sure that it's a smooth experience. Before 1.8 it was smooth. I could filter the list near-instantly, and switch tabs instantly. Like it still took a few seconds for 10.000 thumbnails to load, that's totally fair! But something changed here to make it a pain to even consider switching models. It was the only real drawback to switching to Forge for me. Keeping in mind I also have all models sorted in careful subfolders, so my subfolder list was huge the way it was displayed before. I think the tree view is a good improvement to it, except that it takes up so much permanent screen space compared to the folder-labels before. They would only take up space at the top of the screen. As it is right now, I navigate with the folder view, then close it, to make it not take up 1/5 of the screen-space. A bit tedious and frustrating for sure. Especially considering toggling the folder view also takes ~2 seconds with my list.

Yeah when I revise this code I'll do something to add the old style of buttons as well as allow resizing the pane. HTML really isn't my forte so trying to figure out why this is all so slow is a bit difficult for me.

Out of curiosity... how much disk space does 10k models take up?

Looks like it's 8867 .safetensor-files at least.

[kaalibro]

I don't have 10,000 of loras, but out of curiosity, I also decided to test the performance. In the second case the entire code remains the same, only the commits related to the tree view are absent.

Tree view Refresh — 44s Notice the sorting.

https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/44464226/a68748a6-613e-44bb-abb4-9ea6f9a0ac13

Buttons Refresh — 23s

https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/44464226/3f082281-8aa0-416d-aea4-ca4a652ddc46

[MNeMoNiCuZ]

Thank you for the demonstration! This matches my results as well.

[xmattar]

thats what im sayin

[catboxanon]

This has been added back in via https://github.com/AUTOMATIC1111/stable-diffusion-webui/commit/a551a43164b8baf1b5652a9ee73081cca54c612b, along with several other optimizations to improve performance of sorting and filtering.