• S sverchok
  • Информация о проекте
    • Информация о проекте
    • Активность
    • Метки
    • Участники
  • Репозиторий
    • Репозиторий
    • Файлы
    • Коммиты
    • Ветки
    • Теги
    • Участники
    • Диаграмма
    • Сравнение
  • Задачи 148
    • Задачи 148
    • Список
    • Доски
    • Спринты
  • Запросы на слияние 21
    • Запросы на слияние 21
  • CI/CD
    • CI/CD
    • Конвейеры
    • Задания
    • Расписания
  • Развертывания
    • Развертывания
    • Окружения
    • Релизы
  • Пакеты и реестры
    • Пакеты и реестры
    • Реестр пакетов
    • Реестр контейнеров
  • Мониторинг
    • Мониторинг
    • Инциденты
  • Аналитика
    • Аналитика
    • Поток ценности
    • CI/CD
    • Репозиторий
  • Wiki
    • Wiki
  • Сниппеты
    • Сниппеты
  • Активность
  • Диаграмма
  • Создать новую задачу
  • Задания
  • Коммиты
  • Доски с задачами
Свернуть панель
  • nikitronn
  • sverchok
  • Запросы на слияние
  • !1998

User-defined node presets

  • Ревью изменений

  • Скачать
  • Почтовые патчи
  • Простое отличие
Слиты nikitronn запросил слияние presets в master Янв 02, 2018
  • Обзор 15
  • Коммиты 12
  • Конвейеры 0
  • Изменения 6

Created by: portnov

I really think this is kind of feature which Sverchok lacked very much from user perspective.

The main ideas are:

  • The main approach to solving complex problems (in this case - designing complex parametric setups) is to divide and conquer.
  • As we know very well from our programming experience, the right way to divide and conquer is to have a library of building blocks and be able to compose them in different ways.
  • As we know from using github, Maven central, pypi.org and others, a very good way to produce a large number of such building blocks is to allow users to produce them and share them.

My requirements as a user are:

  • F1. Be able to store settings of either one node (for nodes that have more than 2-3 properties), or some set of linked nodes, as a named preset for later usage in different setups.
  • F1.1. Special case 1 is to be able to save and use Monad node as a preset.
  • F1.2. Special case 2 is to be able to save and use a Scripted node with script in it. The same applies for Profile node, Mesh Expression and so on.
  • F2. Be able to manage my presets locally: rename them, remove unused and so on.
  • F2.1. Extension of F2 (not need it right now but very probably will need in future): be able to organize my presets in some sort of categories or tags locally.
  • F3. Be able to share my presets with people. It can be done via simple files or via some web service.
  • F3.1. Extension of F3 (want to see it implemented, but not sure whether it is possible to implement with our resources at all): be able to manage shared resources online. By that I mean some sort of asset management and sharing web-service, like opendesktop.org.
  • F4. Be able to use presets shared by someone else. It can be done via simple files or via some web service.

In current implementation, presets are stored in JSON format (the same as we use for gists), under .../datafiles/sverchok/presets/*.json. Rename/delete operators just do corresponding operations on json files.

I supported minimal set of metainformation attributes:

  • Preset description (displayed as tooltip)
  • Preset author
  • Preset license

All of them are optional. Metainformation is saved under "metainfo" key in json.

Nice thing is that all already existing gists can be now used as presets (user can import gists to local machine and use them as presets).

screenshot_20180102_234335

screenshot_20180102_234406

screenshot_20180103_180341 screenshot_20180103_180445

Ответственный
Назначить
Проверяющие
Запросить ревью
Оценка трудозатрат
Исходная ветка: presets