Files
easy-png-tools/docs/backlog.md
T

5.2 KiB
Raw Blame History

Backlog

Идеи

  1. Менять первый инструмент цепочки — оценка M. Сейчас базовый инструмент зафиксирован при открытии страницы; хочется заменить его на другой без разборки цепочки: шаги и их параметры сохраняются, вход перечитывается. Открытый вопрос: что делать с несовместимыми параметрами (text-source ↔ file).

  2. UI-эксперимент: параметры между исходником и результатом — оценка S/M. Раскладка «Исходник → Параметры → Результат» в один ряд вместо параметров отдельным блоком снизу. Проверить на узких экранах; возможно за флагом/A-B, чтобы сравнить с текущей. Ждет нового дизайна

  3. Сворачивать инструменты в chain — оценка S. Тоггл сворачивания звена до заголовка «Шаг n: название» (превью скрываются). Состояние свёрнутости помнить в workspace-pipeline.

  4. Несколько цепочек: сохранение и загрузка — оценка M. Именованные цепочки в localStorage (список, создать/переименовать/удалить), быстрое переключение. Формат экспортного JSON расширить опциональным полем имени, старые файлы читаются как безымянные.

  5. Batch-обработка архивов выбранным chain — оценка L. Вход — zip-архив картинок (распаковка в браузере), прогон текущего или выбранного сохранённого chain по каждому файлу, сборка результата обратно в zip для скачивания. Зависит от п.4 (выбор цепочки) и от экспортного формата pipeline JSON; прогресс и ошибки — пофайлово.

  6. Избранные инструменты (fav tools) — оценка S/M. Тоггл-звёздочка на карточках каталога, результатах поиска и в шапке страницы инструмента; список id в localStorage. Избранное показывается отдельной секцией сверху каталога и поднимается в выдаче поиска (бонус к popularity при скоринге).

  7. Конвертация формата — НЕ отдельный инструмент, а выбор в кнопке Download — оценка M/L. Инструменты convert-png-to-jpg / convert-png-to-webp (и др. форматы) не должны жить как самостоятельные инструменты цепочки. Вместо этого — бесшовное внедрение выбора формата/качества прямо в кнопку/диалог Download: юзер скачивает результат в нужном формате (mime/ext/quality), а pipeline при этом не усложняется лишним звеном. Связано с планом типизации: в новом ToolEntry<P> под run в registry-new нет поля output (mime/ext/qualityParamId), которое есть у старых конвертеров — см. plan-composite-params.md, замечание по Фазе 2. Формат-метаданные должны переехать в понятие «формат результата» на уровне скачивания, а не отдельного инструмента. Решение «не сейчас» (исследование, 2026-09):

    • В старом UI этот паттерн уже работает: convert-*-инструменты не конвертируют в run, а только настраивают output (mime/ext/qualityParamId), который читает DownloadButtonencode(img, mime, quality). То есть формат уже фактически «поле скачивания» в старом pipeline.
    • В новом preview registry-new поля output нет, executor.worker возвращает только пиксели, а SchemaToolView.download() захардкожен на image/png + имя with-border.png. Делать ретработу сейчас = параллельный спец-проект.
    • Когда делать: вместе с достройкой нового download/сохранения в новом UI (в рамках plan-composite-params, Фаза 4/UI). Тогда выбор формата встраивается в download-flow естественно, без выдёргивания отдельным проектом. Не начинать, пока не закрыта типизация pipeline.