Всем привет!
В этом канале я буду постить разное о разработке на языке Rust.
Сам я не настоящий сварщик. У меня всего лишь один коммит в std.
Но я пишу на Rust c дорелизных времен и иногда немного преподаю его студентам.
А когда-то и писал на Rust за деньги в настоящий продакшн.
Сейчас у меня есть несколько пет проектов, о которых в основном и буду тут писать.
В этом канале я буду постить разное о разработке на языке Rust.
Сам я не настоящий сварщик. У меня всего лишь один коммит в std.
Но я пишу на Rust c дорелизных времен и иногда немного преподаю его студентам.
А когда-то и писал на Rust за деньги в настоящий продакшн.
Сейчас у меня есть несколько пет проектов, о которых в основном и буду тут писать.
🤔2
Первый проект, о котором хотел бы рассказать это
Я большой фанат
Может он и не самый красивый и местами делает слишком много работы, но на нем чертовски удобно писать UI, чего не скажешь о всех остальных UI фреймворках, что я пробовал, не только растовых.
egui-snarl
.Я большой фанат
egui
как UI фреймворка для разработчика.Может он и не самый красивый и местами делает слишком много работы, но на нем чертовски удобно писать UI, чего не скажешь о всех остальных UI фреймворках, что я пробовал, не только растовых.
egui-snarl
это библиотека для создания визуальных нод-графов.В отличии от существующих нод-граф крейтов у egui-snarl используется концепт вьюера.
Это он решает какие у ноды пины, сколько их, как выглядят, что рисуется рядом с ними.
При отрисовке
Это он решает какие у ноды пины, сколько их, как выглядят, что рисуется рядом с ними.
egui-snarl
предоставляет контейнер для графа Snarl
и трейт для вьюера SnarlViewer
.При отрисовке
Snarl::show
регулярно обращается к SnarlViewer
что бы отрисовать шапку ноды, узнать сколько сейчас пинов у ноды, отрисовать контент у пина, узнать как выглядит сам пин, а так же с событиями, что бы вьюер сам решил что делать, соединять ли ноды, а может между ними вставить еще одну для преобразования типа, удалять ли связь или ноду.Граф на картинке выше имеет очень простое определение типа ноды.
Это такой вот энум
И уже вьюер сам знает что у
Это такой вот энум
enum DemoNode {
/// Node with single input.
/// Displays the value of the input.
Sink,
/// Value node with a single output.
/// The value is editable in UI.
Integer(i32),
/// Value node with a single output.
String(String),
/// Value node with a single output.
///
/// It has two inputs, ediable if not connected.
Add(Vec<i32>),
/// Converts URI to Image
Show(String),
}
И уже вьюер сам знает что у
Sink
есть 1 вход и 0 выходов, а у Add
входов сколько значений + 1, а выход 1Так же вьюер решает, что
Когда
Конечно при большем количестве вариантов надо заводить нормальные типы передаваемых данных, а не хэндлить каждый тип ноды отдельно, но в примере так нагляднее пока что.
Sink
показывает у своего входа.Когда
Sink
подключен к выходу от Integer
или Add
, то вьюер сделает ui.label()
с числовым значением, от String
со строковым значением, а от Show
загрузит картинку, хотя в типе там тоже строка лежит.Конечно при большем количестве вариантов надо заводить нормальные типы передаваемых данных, а не хэндлить каждый тип ноды отдельно, но в примере так нагляднее пока что.
Связи вообще и необязательно передают какие-то данные.
Я собираюсь использовать нод-графы в двух местах сейчас.
1. Для организации зависимостей между системами для ЕЦС.
Планирую дать возможность менять порядок систем прямо в рантайме, когда симуляция игры запущена в эдиторе.
2. Для визуализации рендерграфа. Как-то модифицировать граф будет нельзя, только двигать ноды по плоскости.
Я собираюсь использовать нод-графы в двух местах сейчас.
1. Для организации зависимостей между системами для ЕЦС.
Snarl
с системами будет передан в скедулер.Планирую дать возможность менять порядок систем прямо в рантайме, когда симуляция игры запущена в эдиторе.
2. Для визуализации рендерграфа. Как-то модифицировать граф будет нельзя, только двигать ноды по плоскости.
Сейчас вот подумал, что для рендерграфа можно при выборе пина показывать содержимое. Даже для буферов, если будет описание структуры данных там