fltk не нативный

Может поэтому так весит

он и на линуксе qt creator содержит

На линуксе проще с PPA deb пакеты ставить

сука вот почему никто не может спиздить то как работают шрифты в ведре к себе?

dll-ки подгружать? уверен, что хорошая идея?

Опенсурс же

Не опенсурс

а че на расте даже не думают нативные гуишки-фреймворки пилить?

fltk не нативный

гм, а почему он тогда такой маленький

а че на расте даже не думают нативные гуишки-фреймворки пилить?

Не придумали парадигмы пока вроде. ООП не очень подходит, а с функциональщиной пока не осиливают

Точнее, есть уже функциональный подход — это реакт.

Но у реакта есть жсх

а у функционального подхода нету недостатков?

а подобие реакта в расте замутить нереально?

нууу

стек растет например

например чрезмерное использование памяти

в реакте даже свой движок написали чтобы с этим бороться

в стандарте C нет спецификации abi, оно устанавливется для каждой платформы отдельно есть тут http://refspecs.linuxfoundation.org/elf/index.html

https://rust-lang-nursery.github.io/rust-bindgen/cpp.html Так стоп, а зачем тогда bindgen может генерировать биндинги к c++

там наверное проходятся по сорцам и дублируют все вызовы через extern C, собирают в библиотеку, раст работает через неё

там наверное проходятся по сорцам и дублируют все вызовы через extern C, собирают в библиотеку, раст работает через неё

Да, тоже подозреваю такое

это нахуй такой тулкит графики

Так ониж там на модули его делят уже пару лет.

На финише я так понимаю можно будет только QtCore или QtUI тянуть

Но хз в каком оно сейчас состоянии

типо только в маке шрифты всех размеров норм сглаживаются?

Мылятся в смысле

потому питонисты херачат дохуя кода

Просто кто-то не осиливает декораторы

смерть кьют, гтк форева ин харт

Тв сначала допили чтобы в виндах работало

Просто кто-то не осиливает декораторы

Это какраз пример неявного, как и любое метапрограммирование.

И тут нужно начать холивар на тему определения слова явный 😄

Это какраз пример неявного, как и любое метапрограммирование.

Достаточно явное. Хотя оригинальный тезис о неосиляторстве питонистов мне не нравится.

Ну если сравнивать декораторы в python и аннотации в Java, то да декораторы в "явности" выигрывают))

а че на расте даже не думают нативные гуишки-фреймворки пилить?

в расте сидят сейчас по серьезке только всякие драйверодрочеры

тех кто по графике нема

все кто пишут для графики до сих пор на всяких с++ дрочат

Чтобы написать декоратор нужно написать некоторое количество кода, которое редко отличается от количества кода, в случае, реализации без декоратора.

ну или как гномовцы - насилуют труп ansi C

по

так что в расте все еще все в зачаточном состоянии графика

ну или как гномовцы - насилуют труп ansi C

Я объяснил, почему она в зачаточном состоянии

Опыт с сипп тут не поможет

это можно судить по всяким lyon, piston etc..

Я объяснил, почему она в зачаточном состоянии

хде

Не придумали парадигмы пока вроде. ООП не очень подходит, а с функциональщиной пока не осиливают

Тут

Тут

ну имхо да малафья на dart что сюда кидали вполне себе вписывается вроде также если под раст писать

Чтобы написать декоратор нужно написать некоторое количество кода, которое редко отличается от количества кода, в случае, реализации без декоратора.

Не совсем тебя понял? Декораторы же переиспользуются.

> ООП не очень подходит и что не так с ООП?

> ООП не очень подходит и что не так с ООП?

В расте нет ооп

да неужели

ООП considered harmful

> ООП не очень подходит и что не так с ООП?

Его не так поняли

а RAII просто так что ли

В расте нет ооп

почему нет?

RAII == ООП? Окей, тогда есть, извиняюсь

а RAII просто так что ли

Каким боком оно к ООП?

там есть subtype polymorphism?

нету

запили функцию которая принимает сообщения и хранит стейт

вот тебе ооп

наследование != ООП

Это какраз пример неявного, как и любое метапрограммирование.

Тогда любой вынос общей функции будет чем-то неявным

ООП это миф

Все же, что нужно для ооп - независимый стейт компоннентов и посылка между ними сообщений

Не совсем тебя понял? Декораторы же переиспользуются.

Функции тоже

ООП это миф

О, чую начало хорошего срачика

Функции тоже

Ну декоратор это по сути и есть функция))

Просто синтаксис вызова немного другой)

наследование != ООП

ООП не по Кею это subtype polymorphism, плюс state encapsulation

Все же, что нужно для ооп - независимый стейт компоннентов и посылка между ними сообщений

это по Кею

это для маргиналов определение

доказывать что оно более правильное - не имеет смысла : ]

тут скорее нужен компонентный подход с определением нескольких понятий: - api ористовки - собсно эти самые квадратики, кружочки, закругления фоны и все такое - понятие узлов, собственно нечто что позволит иметь представления о узле как холсте и как компоненте, апидля компоновки с эвентами и всем таким - создать возможность что каждый узел работает как текстурное представление, тоесть дать возможность не только делать узел как нарисованный объект - но и как некий модификатор - ну типо узел под которым все элементы будут блюрится шейдером - система эвентов для узлов - собсно клик, клак, драг и дроп и все такое - ивент луп для оного

это как говорить что signetons это instance для готорого есть однозначное соотвествие типа со значением

оказывается вот как передавать флаги gcc https://crates.io/crates/gcc

через build.rs

В расте нет ооп

Структуры есть? Есть. Поля с данными и методы? Есть. Инкапсуляция? Check. Плюс удобное управление ресурсами через RAII. Нет лишь наследования, но можно делать композицию. Зато есть типажи.

и да всякие там lyon показывают что они занимаются в основном самым простым графонием по отрисовке, там больше года висит таска по созданию сглаживания узла и до сих пор нихуя

у них там майлстон для 1.0 который все время пополяется и создается функционал

а таска по сглаживанию до сих пор так и висит

это для маргиналов определение

Описывать ооп как структуры с методами и инкапсуляцией - еще больший бред

Функции тоже

Декораторы от функции отличаются только тем что оборачивают входную функцию своим функционалом и вертают функцию с тем же именем что и входная.