Rust нормальный GUI

Cross-platform GUI toolkit (Windows, Linux, Mac)

У тебя настолько плохо с английским? Покажи, где здесь упоминается «Android»?

impl Layout for DataModel {
    fn layout(&self, _info: WindowInfo<Self>) -> Dom<Self> {
            Dom::new(NodeType::Div).with_id("email-container")
                .with_child(self.emails.iter().map(layout_email_component).collect())
    }
}

collect

если в списке 100500 имейлов, то при каждой отрисовке будет целый список пересоздавать в куче?

imgui ктото запрещает использовать?

или написать биндинги к <любому(С/С++) ГУЮ> тоже нельзя?

если в списке 100500 имейлов, то при каждой отрисовке будет целый список пересоздавать в куче?

добро пожаловать в мир гуе-писателей

(все эти гуи пишутся для вывода двух слов хелло+ворд об остальном подумают когда получат финансирование гугла)

GUI framework for rapid prototyping

тогда ладно.

а в чем смысл прототипирования, если потом все с нуля переписывать под нормальный фреймворк, с принципиально другими паттернами?

а в сложных проектах гуи - это не та часть, которая съедает больше всего человекочасов

поменял чуть главное сообщение, людиии помогите определиться пожалуйста

а в чем смысл прототипирования, если потом все с нуля переписывать

а в сложных проектах гуи - это не та часть, которая съедает больше всего человекочасов

Так всё переписывать или «не ту часть, которая»?

Скажите пожалуйста вот эту штуку https://azul.rs/index.html под андроид можно завести?

Не исключено: https://github.com/maps4print/azul/blob/fe7594bd3338023c4a0a420fa36c217494f62...

Так всё переписывать или «не ту часть, которая»?

если проект сложный (читай: составной), то гуишные модули (читай: клиенты)

если проект целиком просто одна гувина - то всё. не трогать бизнес-логику вряд ли получится, так как смена гуи-парадигмы потребует смены интерфейсов моделей данных

    Dom::new(NodeType::Div)
        .with_child(Dom::new(NodeType::Div)
        .with_class("email-header")
            .with_child(Dom::new(NodeType::Image(email.profile_pic)))
            .with_child(Dom::new(NodeType::Label(email.from.clone()))))
        .with_child(Dom::new(NodeType::Div)
        .with_class("email-content")
            .with_child(Dom::new(NodeType::Label(email.subject.clone())))
            .with_child(Dom::new(NodeType::Text(email.message))))

Ждем когда какой-нибудь хипстер напишет JSX транскомпилятор для этого ужаса и React Native можно будет закапывать

если в списке 100500 имейлов, то при каждой отрисовке будет целый список пересоздавать в куче?

В чятике дискорда просили передать, что для этого есть трейт IFrameCallback. С ним нет необходимости рисовать весь список целиком, так как все 10000 одновременно на экран не попадают. .collect() отработает только для тех 10-20, что видны на экране. Также IFrameCallback принимает дополнительные параметры, чтобы знать размер отображаемой области, где можно посчитать, сколько элементов нужно отобразить. Есть пример table, где это показано.

Андроид возможен, так как основные зависимости winit and webrender работают с ним, но в библиотеку нужно добавлять элементы для мобильных устройств и тестирование никто не проводил.

Какие вообще варианты есть?

Лол.

Ну можно написать сначала сишную либу, которая будет дёргать Android Java API через JNI, а потом эту сишную либу дёргать уже из Rust'а.

Чем-то подобным занимаются QtQuick/QML-программисты под Android. С тем лишь отличием что они из своего QML вылазят в C++ из которого Android API доступны по JNI. Ну а ты из Rust'а будешь вылазить в C.

а в чем смысл прототипирования, если потом все с нуля переписывать под нормальный фреймворк, с принципиально другими паттернами?

Под прототипирование понимается только разработка, и то, только в рамках горячей замены CSS.

Под прототипирование понимается только разработка, и то, только в рамках горячей замены CSS.

яннп, но в любом разе, мой вопрос снимается в связи с твоим предыдущим ответом

То есть ты смотрел сабж и/или используешь?

Мопед не мой, я просто разместил объяву.

Я лично пока только примеры тыкал. Выглядит лучше, чем rise-ui или limn.