Commit Graph

15 Commits

Author SHA1 Message Date
psychedelicious
af726d1f15 feat(ui): split control layers from raster layers for UI and internal state, same rendering as raster layers 2024-09-06 21:27:36 +10:00
psychedelicious
edeb706d19 tidy(ui): rename canvas stuff 2024-09-06 21:27:35 +10:00
psychedelicious
2d123fa11c refactor(ui): use "entity" instead of "data" for canvas 2024-09-06 21:27:34 +10:00
psychedelicious
2a0d16d57d fix(ui): move lora followup fixes 2024-09-06 21:27:34 +10:00
psychedelicious
c2f60f33e6 refactor(ui): metadata recall (wip)
just enough let the app run
2024-09-06 21:27:34 +10:00
psychedelicious
bcfdae62e3 refactor(ui): canvas v2 (wip) 2024-09-06 21:27:34 +10:00
psychedelicious
23ad6fb730 feat(ui): handle missing images/models when recalling control layers 2024-05-08 08:39:18 -04:00
psychedelicious
8b25c1a62e tidy(ui): remove extraneous metadata handlers 2024-05-08 08:39:18 -04:00
psychedelicious
dfbd7eb1cf feat(ui): individual layer recall 2024-05-08 08:39:18 -04:00
psychedelicious
e537de2f6d feat(ui): layers recall
This still needs some finessing - needs logic depending on the tab...
2024-05-08 08:39:18 -04:00
psychedelicious
6363095b29 feat(ui): control adapter recall for control layers
- Add set of metadata handlers for the control layers CAs
- Use these conditionally depending on the active tab - when recalling on txt2img, the CAs go to control layers, else they go to the old CA area.
2024-05-02 23:09:26 -04:00
psychedelicious
d23f2de9d7 feat(ui): create metadata types for control adapters
These are the same as the existing control adapter types, but the model field is non-nullable, simplifying handling of these objects.
2024-03-01 10:42:33 +11:00
psychedelicious
9abfb02bf0 fix(ui): model metadata handlers use model identifiers, not configs
Model metadata includes the main model, VAE and refiner model.

These used full model configs, as returned by the server, as their metadata type.

LoRA and control adapter metadata only use the metadata identifier.

This created a difference in handling. After parsing a model/vae/refiner, we have its name and can display it. But for LoRAs and control adapters, we only have the model key and must query for the full model config to get the name.

This change makes main model/vae/refiner metadata only have the model key, like LoRAs and control adapters.

The render function is now async so fetching can occur within it. All metadata fields with models now only contain the identifier, and fetch the model name to render their values.
2024-03-01 10:42:33 +11:00
psychedelicious
a253047d8e tidy(ui): tidy model identifier logic
- Move some files around
- Use util to extract key and base from model config
2024-03-01 10:42:33 +11:00
psychedelicious
d1f4cde8c7 feat(ui): refactor metadata handling (again)
Add concepts for metadata handlers. Handlers include parsers, recallers and validators for different metadata types:
- Parsers parse a raw metadata object of any shape to a structured object.
- Recallers load the parsed metadata into state. Recallers are optional, as some metadata types don't need to be loaded into state.
- Validators provide an additional layer of validation before recalling the metadata. This is needed because a metadata object may be valid, but not able to be recalled due to some other requirement, like base model compatibility. Validators are optional.

Sometimes metadata is not a single object but a list of items - like LoRAs. Metadata handlers may implement an optional set of "item" handlers which operate on individual items in the list.

Parsers and validators are async to allow fetching additional data, like a model config. Recallers are synchronous.

The these handlers are composed into a public API, exported as a `handlers` object. Besides the handlers functions, a metadata handler set includes:
- A function to get the label of the metadata type.
- An optional function to render the value of the metadata type.
- An optional function to render the _item_ value of the metadata type.
2024-03-01 10:42:33 +11:00