Я знал, что ты оставишь неизгладимое впечатление

скопирую сюда что ты ему про архитектуру расписал пожалуйста

+

Напиши пост на медиум

Ща воскресну, кофе налью и отпишусь что там да как

https://python-gtk-3-tutorial.readthedocs.io/en/latest/ - собственно это базовый туториал по работе с виджетами, в нем нет архитектурных хаков и тд, так что не вариант из него взять архитектуру, также есть этот замечательный референс по байдингам https://lazka.github.io/pgi-docs/, обычно его я и использую чтобы понимать как работают виджеты gtk чтобы использовать потом это в rust. По поводу эвентлупа знаю коннектор для gobject только этот: https://bitbucket.org/a_ba/gbulb/src, он допотопный уже, но думаю тебе будет не сильно проблемно под 3.6 его адаптировать. Пример использования найдешь там же, он конечно также допотопный, но если будешь использовать сахар, особой проблемы не будет. Лично я советую все таки использовать синхронную архитектуру основанную на базовом эвентлупе, в большинстве случаев этого более чем достаточно, и куда проще поддерживать. По поводу построения архитектуры, советую тебе использовать создать свой MV* на псевдоэвентах (хотя это скорее FLUX + Views). Это как по мне один из самых простых способов сделать хорошую архитектуру GUI для GTK, с учетом динамичной типизации python делать это куда проще. В твоем случае это может выглядеть примерно так: App - класс инициализации, тут ты у нас создаешь базовую оболочку GtkApplication, с основным окном, навигатором и тд Navigator - класс навигации, хранит в себе экземпляр Stack для пагинации, который берет все твои инстансы вьюх и регистрирует их в stack для последующей навигации по названию. EventEmitter - собственно твой сихнорнный эвент эмитер, он хранит все экшены которые к нему приходят, и отправляет их по всем подписчикам View - класс экземпляры которого хранят страницу (например gtk::Box), и имеют метод для обработки входящих эвентов. Во время инициализации вьюхи в навигаторе, ты подписываешься на EventEmitter этим методом, и отдаешь во владение ссылку на EventEmitter в классе: чтобы создать возможность и принимать, и посылать эвенты. Некоторые компоненты придется подписывать самостоятельно, отдельно от основной пагинации которая находится в навигаторе, например gtk::HeaderBar. Получается базовый скелет приложения, в котором у тебя есть контейнер базовой пагинации Stack для переключения страниц, есть навигатор работы с эвентами, где каждая вьюха может соеденятся с другими компонентами и контейнерами. В данном случае асинхронность не особенно нужна, асинхронность нужна если ты делаешь сложные и долгие обработчики, например "сделать 100500 запросов/скачать 100500 картинок и тд, в такой ситуации, лучше чтобы не заебыватся, создать отдельный тред с синхронными эвентами, и там запустить asyncio event loop с твоими задачами. Ну или если охота еби гу.. Glib интегратором эвентлупа для asyncio написанным 4 года назад) Также для базовых скелетов вьюх советую использовать GtkBuilder + PUG (для компиляции в XML), так проще будет контролировать базовую верстку, все свои ассеты собирай в gresource пакеты, их куда проще потом подключать чем ебацо с файловой системой, открывать, закрывать файлы и тд. За базовым скелетом и работой с ассетами можешь у меня в репе глянуть. https://github.com/friktor/wiki-reader Код на расте читать не обязательно, но скелет боилерплейта работы с статикой и расположением всего мира можешь таки глянуть.

Короче можешь расплакаться и сразу сказать "нахуй gtk" и убиться о стену в отчаянии))))

че там на расте пишут нативный аналог gtk/qt и прочим?

Напиши пост на медиум

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

И да я таки переписал рендер

И научился обрабатывать асинхронно ленивые шаблоны gtk

в расте есть что-то вроде flutures? https://github.com/fluture-js/Fluture

че там на расте пишут нативный аналог gtk/qt и прочим?

Хуй там

Хуй там

че так хуево

Хщ

там же кто то делал что то под композицию?

По идее есть либы

С хорошими предпосылками

Для написания тулкита

Но там муторно

в расте есть что-то вроде flutures? https://github.com/fluture-js/Fluture

tokio

Даже близко например аналога pango нет

Нет даже близко таких удобных либ как cairo

tokio

не уловил сарказма

ааа

увидел там fututes

че

Есть только уебанские оболочки для gl

че

прост flutures и tokio это дико разные вещи

И подобия игровых движков умеющих немного в эвенты

поясни

tokio futures vs. flutures

там же кто то делал что то под композицию?

Поверх servo)

бля

Ну и конрод еще

Но конрод как ui скорее эксперимент

Причем не совсем удачный

tokio futures vs. flutures

futures не в комплекте tokio идут же

futures не в комплекте tokio идут же

tokio зависит от futures

ну и что

можно ж было линк дать на futures сходу

без разницы

Вообще у меня большие надежды на lyon

вполне возможно что когда либа стабилизируется

вполне возможно будет неплохая рисовалка

хотя до cairo конечно будет все равно как раком до китая

Имхо, лучше бы кто оригинальный cairo с похожей структурой переписал, но чтобы обработка была на GPU

А вообще тот же lyon не особо будет готов к проде, даже если реализует хуеву тучу хелперов и тд, если они не пофиксят эту багу https://github.com/nical/lyon/issues/6 которой уже полтора года)

Сейчас в расте ни одной либы для графики и шрифтов где было бы сглаживание

Пока эту проблему не решат, оно нахуй будет никому не всрато

Имхо, лучше бы кто оригинальный cairo с похожей структурой переписал, но чтобы обработка была на GPU

лол Mozilla же юзает его в FF

есть шанс

лол Mozilla же юзает его в FF

хуй там

убрали уже

бля

полгода назад, как часть рефакторинга

теперь там впилен skia

который в отличии от cairo рендерится на GPU, имеет божественную доку и почти понятный API

из минусов - он на плюсах

и он жирный

но относительно именно производительности рендеринга - он ебет cairo во все щели

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

и идет очень болезненный процесс выковыривания из ядра инъекций cairo

(которые там везде)

и идет очень болезненный процесс выковыривания из ядра инъекций cairo

с этого момента поподробнее

ммм

ща

Ну короче, сейчас в gtk с недавних пор решил начать огромный рефакторинг отрисовки некий хуй по имени Эмануэль Басси, раньше отрисовка велась по принципу: рисуем поебень в cairo, отправляем поебень в X.org, поебень рисуется, делаю клац по мышке - иксы овтечают, опять рисуют и опять отправляют. Эта хуйня называлась GDK. Но эта поебень стала слишком много кушать ресурсов, а делать чтото полезное прекратила почти совсем. И тут в наш мирок пришел Wayland и кинул палку всем разрабам gnome на клыка. Ибо теперь нужно самому все рисовать и обозначать контект отрисовки, и получилось что теперь делается так вообще тройная работа - сначала рисуем на процике, потом отправляем картинку в видюху, которая нам потом отдает ее обратно - пиздец прям. И тут возник великий ебасси который еще 8 лет назад предлагал всем к хуям выкинуть Cairo ибо он скатит все в пизду - его само собой тогда никто не слушал. Сейчас же все таки послушали и наш герой начал делать замену для GDK - которую назвал GSK, и которая работает по принципу сходим с Web DOM Nodes. Но для этой хуйни нужна своя рисовалка - поэтому наш гЫрой, начал делать целую хуеву тучу поделок для замены рисовалки - так появились эти хуйни: https://github.com/ebassi/graphene и https://github.com/ebassi/emeus, которые собсно все делают без гондонов реально рисуемым на GPU. Но воть проблема, большая часть всех стандартных UI виджетов (не контейнеров) рисуется этим вашим Cairo, и вообще он впилен сука везде в апишниках GTK как родной, а теперь оказалось что он какбы нахуй и не нужен, и понеслось...

надеюсь пояснил простым языком)

еба, я пока не прочитал. Но за такую простыню уже стоит поблагодарить Спасибо!

Плюс эмануэль последнее время в бложике нехило так восхвалял rust, плюс у него есть свои либы для раста и все такое, так что возможно, и вполне возможно что потом будут все к хуям на rust переписывать, с bindgen для сохранения обратной совместимости с С

Ну короче, сейчас в gtk с недавних пор решил начать огромный рефакторинг отрисовки некий хуй по имени Эмануэль Басси, раньше отрисовка велась по принципу: рисуем поебень в cairo, отправляем поебень в X.org, поебень рисуется, делаю клац по мышке - иксы овтечают, опять рисуют и опять отправляют. Эта хуйня называлась GDK. Но эта поебень стала слишком много кушать ресурсов, а делать чтото полезное прекратила почти совсем. И тут в наш мирок пришел Wayland и кинул палку всем разрабам gnome на клыка. Ибо теперь нужно самому все рисовать и обозначать контект отрисовки, и получилось что теперь делается так вообще тройная работа - сначала рисуем на процике, потом отправляем картинку в видюху, которая нам потом отдает ее обратно - пиздец прям. И тут возник великий ебасси который еще 8 лет назад предлагал всем к хуям выкинуть Cairo ибо он скатит все в пизду - его само собой тогда никто не слушал. Сейчас же все таки послушали и наш герой начал делать замену для GDK - которую назвал GSK, и которая работает по принципу сходим с Web DOM Nodes. Но для этой хуйни нужна своя рисовалка - поэтому наш гЫрой, начал делать целую хуеву тучу поделок для замены рисовалки - так появились эти хуйни: https://github.com/ebassi/graphene и https://github.com/ebassi/emeus, которые собсно все делают без гондонов реально рисуемым на GPU. Но воть проблема, большая часть всех стандартных UI виджетов (не контейнеров) рисуется этим вашим Cairo, и вообще он впилен сука везде в апишниках GTK как родной, а теперь оказалось что он какбы нахуй и не нужен, и понеслось...

Спасибо, позновательно, не жалею что сижу на Qt =)

Лел

А gpu рисивалка под раст это будет гуд, на одноплатниках может через directfb буду рисовать

У qt какбэ проблем тож дохуя)

Но они все в плоскости кастомного рисования, дизайна и выжирания тонн памяти

В любом случае меньше чем у гтк =)

В любом случае меньше чем у гтк =)

та ладно

м?

Пофлеймим =)