Как выбрать существующую библиотеку для проекта?

Если вам действительно нужна только библиотека, то пусть Коля, Вася и Петя спроектируют единый интерфейс для перемножения 2 на 2. Псоле этого каждый может его реализовать поверх своей любимой библиотеки. Ближе к концу проекта опрпделитесь сами, с какой библиотекой вам удобнее в прод ехать.

Если вы хотите не просто библиотеку выбрать, а фреймворк, то тут будут уже совсем другие критерии.

спроектируют единый интерфейс для перемножения 2 на 2

Но по всей видимости нам надо будет еще умножать 3 на 2 и даже 2 на 3. Это не приведет нас к тому, что мы будем писать унифицированный фасад для библиотек XXX и YYY? А там тысячи, если не миллионы функций!

Петя считает, что XXX - это древнее говно мамонта, которое совершенно не поддерживается, монструозно и вообще не современно, особенно когда есть библиотека YYY - новая, быстрая, молодежная

Слать его в жопу с такой аргументацией.

Я руководствуюсь распространенностью библиотеки в первую очередь (чтобы было легче гуглить проблемы или отправлять issue на гитхабе). Для решения узкой проблемы я отдам предпочтение маленькой либе. Обычно, чем больше библиотека/фреймворк, тем сложнее ее интегрировать и поддерживать, потому что она требует больше фонового «знания», она может предъявлять требования к своему окружению и настройке и вообще быть несовместимой с другой жирной дурой. Кроме того в этих фреймворках вечно живут баги, а потому сиди обновляй это дерьмо каждую неделю.

Слать его в жопу с такой аргументацией.

Вот тебе реальный пример: OpenSSL. Чтобы просто посчитать чек-сумму, нужно написать строк десять заклинаний с инициализацией контекстов и прочей срамотой. Когда дело доходит до шифрования публичными ключами, там просто адовый пиздец в коде становится.

У рандомного программиста нет ни опыта в криптографии, ни знания OpenSSL. В лучшем случае он скопирует заклинания со стэк-оверфлоу, в худшем — нагородит ошибок и посчитает чек-сумму неверно. Модные молодежные надстройки над OpenSSL рулят!

Любая ультрасовременная либа это бомба с зависимостями или огромный блоб на 50ти языках.

Когда возникает такая неопределённость, корпорация по сложению чисел делает api обёртки отражающие суть нужного, далее из того что есть на выбор берётся самое проверенное временем ил/и выдирается ровно тот кусочек который нужен для сложения два плюс два и делается реализация это апи. В случае перехода на платформу на корой у выбранного кусочка/библиотеки есть проблемы через это API обёрточку прикручивается другая библиотека. Обёрточка может быть как динамическая загружающая/перезагружающая символы из подсунутых библиотек или по харду статическая оперделяемая во время компиляции. Короче через макросы обычные.

Больно будет если библиотеку для сложения 2 плюс 2 размазать тонким слоем по всему проекту дёргая её напрямую и работая со специфичным для неё образом, а потом надо её заменить на какой отдельной платформе на другую или на свою реализацию. Отета жопа будет гореть у всех, особенно если кто-то решит ещё размазать ifdef по всему проекту для поддержки 2х и более библиотек. Вместо размазывания в 1 файлике API обёрточки =)

Идеального решения нету как по мне, всё зависит от ситуации и требованиям к либе

пока Вася, Петя и Коля балаболят, пишется свой интерфейс, через который впоследствии будем дергать ту или иную, пофигу какую, либу.

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

решить же кто прав можно разными способами, как то:

• монеткой
• на боксерском ринге
• кто из троих раньше склеит Машу
• кто ссыт дальше
• кто ссыт дольше
• другие интересные конкурсы

не за что.

да ну нах.. а может это просто ктото другой не смог?! хде сдесь адово?

std::unique_ptr<BIO, void(*)(BIO*)> bCert{ BIO_new_mem_buf(cert.data(), cert.size()), BIO_free_all };
std::unique_ptr<BIO, void(*)(BIO*)> bData{ BIO_new_mem_buf(data.data(), data.size()), BIO_free_all };

// create x509
std::unique_ptr<X509, void(*)(X509*)> x509{ PEM_read_bio_X509(bCert.get(), nullptr, nullptr, nullptr), X509_free };
// create stack of
std::unique_ptr<STACK_OF(X509), void(*)(STACK_OF(X509)*)> stack{ sk_X509_new_null(), sk_X509_free2 };
sk_X509_push(stack.get(), x509.get());
// encrypt pkcs7
std::unique_ptr<PKCS7, void(*)(PKCS7*)> p7{ PKCS7_encrypt(stack.get(), bData.get(), EVP_aes_128_cbc(),  PKCS7_BINARY), PKCS7_free };
// store buf
std::unique_ptr<BIO, void(*)(BIO*)> bDest{ BIO_new(BIO_s_mem()), BIO_free_all };
PEM_write_bio_PKCS7(bDest.get(), p7.get());

Петю уволить, поговорить с Васей и Колей о реализации нужного и необходимого.

Сильно зависит что за проект. Для коммерсни/проприетарщины в которой не принято использовать внешние пакетные экосистемы, а также которую надо собирать подо всякие уродские платформы где их толком и нет, ближе третий подход, т.е. если не встраивание куска кода то вендоринг зависимости целиком и интеграция её в свою сборочную систему. В каких-то языках с собственными пакетными системами это всё менее важно, но был упомянут C++.

Для СПО, напротив, имеет значение где какие зависимости опакечены. Возможно «старую известную» уже отовсюду выпиливают потому что она не собирается актуальными компиляторами и дырявая насквозь. А новую, возможно, ещё ни в какие репы не завезли (хотя в отличие от это не шоу стоппер - понадобится и сразу завезут). Ещё важно насколько широко библиотека используется другими проектами, чтобы не заставлять пользователя тащить маргинальщину ради одного проекта. Впрочем, в СПО также принято давать выбор, поэтому часто делают поддержку нескольких вариантов. Если это не требует конского оверхеда то я бы выбрал именно это, тогда точно никто никого не поубивает. Потом в процессе разработки и эксплуатации можно уже точно понять какой вариант лучше и возможно выкинуть остальные чтобы не тратить силы. Хотя с точки зрения траты сил по личному опыту опыту написание обёрток над разными библиотеками - задача почти не требующая ресурсов. А вот е%ля с проблемами у пользователей, вызванными кривизной зависимости (зависимость не находится, зависимость не собирается на платформе XYZ, в зависимости сломали API и т.д.) тут решается на раз - «собирайте с другой библиотекой».

Упомянутые и дополнительные критерии списком:

• Стабильность API
• Опакеченность в репах дистрибутивов
• Что используется в других похожих проектах? Какие танденции по миграции?
• Лицензия
• Сборочная система (в проекте на cmake логично хотеть использовать библиотеку предоставляющую .cmake файлы, а не пердолиться с pkgconfig)
• Можно сильно развернуть пункты про зрелось и заброшенность - наличие CI с как минимум gcc/clang (лучше ещё cl), тестов, нормального оформлением проекта и куча других критериев

похоже каюк вашей мега-корпорации. За проект никто не отвечает и некому принять решение.

У нас есть N библиотек по перемножению 2х2, но все они очень разные и имеют свои недостатки. Давайте напишем идеальный универсальный интерфейс и м.б. отчасти что то реализуем сами идеальным образом!

Итог - у нас есть N+1 библиотека…

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

Ну нечитаемая параша же. Догадаться, что этот код делает, — можно. Уверенности в том, что он написан правильно, — нет совсем.

Например, ты парсишь приватный ключ, передаешь три nullptr в хвост. Надо гуглить, разбираться. Или создаешь стек ключей. Зачем? Опять надо разбираться. Модная молодежная библиотека будет иметь максимум две функции:

1. загрузить ключ,
2. закинуть данные в поток, на выходе из которого получить закодированный блоб.

Для решения типовой прикладной задачи гибкость openssl не нужна, она способствует ошибкам, она заставляет разбираться (или копипастить с SO).

ЗЫ RAII сократило тебе код вдвое, но читать проще не стало, скорее наоборот.

• Библиотека решает задачу в приемлемых ограничениях (по скорости, памяти)
• Библиотека имеет минимальное число зависимостей (поставьте ~100500 пакетов, половины которых нет в репах, чтобы собрать нашу либу - вот этого вот не надо)
• Интерфейс библиотеки можно использовать, без задействования совместимых с авторскими психостимулирующих веществ.

Етить-колотить, самый главный критерий забыл. Никакого GPL, ни под каким предлогом. LGPL только если альтернатив нет.

YYY - […] быстрая […] целый фреймверк

Неувязочка.

Коля же считает, что надо взять любую библиотеку, выдрать из нее те 15 строк, что требуются и запилить свою библиотеку ZZZ.

Если там замороченные 15 строк, то я Коля. Если простые или я знаю как лучше, то проще с нуля написать – под себя.

как давно был последний релиз библиотеки, не заброшена ли она

Не критерий. С ходу вспоминается только openbox, который тыщу лет уже не развивается потому что совершенен. Это не библиотека, но не так давно на ЛОРе пробегали и другие примеры, подробностей не помню.

а понял, мамкиным пограммистам нужны две строчки… так я вот что скажу, когда будет что можно в две строчки мамкины пограммисты будут не нужны :D

А что не в Talks то?

Наша крупная корпорация

Просто купите какой-нибудь стартап. Из всего кода стартапа вытащите код перемножения 2 на 2. Через полгода увольте всю команду стартаперов и закройте проект.

Не критерий.

Напротив, один из основных критериев.

С ходу вспоминается только openbox, который тыщу лет уже не развивается потому что совершенен

И это как раз замечательный пример почему. Там сотни issue в трекере с реальными проблемами, десятки PR с реальными фиксами, призыв «help translate openbox» в contributing при небольшом, на самом деле, покрытии переводами, сотни патчей в дистрибутивах чтобы это гнильё хоть как-то собиралось, никакой поддержки hidpi, разных dpi на разных мониторах, даже не заикаюсь о wayland. И ни одного коммита с 15 года. Это прям эталон куска abandonware говна, использовать которое - большой риск. И если на openbox вы живёте сами (и почему нет, если вы никогда не видели нормальных WM и у вас один ЭЛТ монитор), то зависимость от библиотеки вы спускаете на всех своих пользователей, и завязаться на вот так вот поддерживаемую библиотеку - это просто подписать приговор проекту. Не говоря уже о том как классно будет интегрировать такую вот «совершенную» библиотеку, не знающую ничего про современные конструкции языка, содержащую deprecated фичи (может даже auto_ptr) и не собирающуюся с современным стандартом, с вашим кодом.

Есть тут, правда, один плюс - можно взять на себя поддержку такого проекта. Мне лично причёсывать старьё приятно - выкидывать все эти autotools, ручные мейкфайлы, python2, plain C код, swap методы, сишную работу со временем и файлами и менять на современные аналоги. Но, понятно, это ответственность и время.

И это как раз замечательный пример почему.

Ок, согласен. :)

Запостил бы уже названия библиотек, был бы предметный срач :) А так — среднепотолочная «многокритериальная оптимизация» — стройте в любимой проге для чартов многоугольник по критериям, смотрите какой максимально выпуклый :) (одновременно посретесь какая прога для чартов лучше)

А какие аргументы для выбора библиотек знаете вы?

Тридцать лет назад созданием программ для электронно-вычислительных машин занимались думающие люди с научным и техническим образованием. В наши дни в погоне за быстрым обогащением в отрасль набежали толпы сброда, которые думать своей головой не приучены.

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

К чему это привело? Кухаркины дети понятия не имеют о душевной ответственности за результаты своего труда и работают по-наплевательски, тяп-ляп. «Зачем что-то тестировать? Для чего тратить своё время? И так сойдёт!», - рассуждают бездари.

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

Короче говоря, если требуется высокое качество конечного товара, то делают всё своё. Если же на обеспечение качества нет денег или времени - заимствуют стороннее.

Брать надо ту либу с которой прокачаешься сам. Приложение умрёт, лид сопьётся, дирик сторчится. И только ты будешь востребован на рынке труда при правильном выборе. 1С говно, яндекс говнище

Хотя я больше болею я Колю.

В принципе - всё правильно сказали уже. Как «злостный проприетарщик» - я бы тоже поступил как Коля. Особенно если речь действительно идёт о handful строк кода.

AntonI,

у нас есть N+1 библиотека…

Это происходит только если новая реализация публична.

Тридцать лет назад созданием программ для электронно-вычислительных машин занимались думающие люди с научным и техническим образованием. В наши дни в погоне за быстрым обогащением в отрасль набежали толпы сброда, которые думать своей головой не приучены.

К чему это привело? Кухаркины дети понятия не имеют о душевной ответственности за результаты своего труда и работают по-наплевательски, тяп-ляп. «Зачем что-то тестировать? Для чего тратить своё время? И так сойдёт!», - рассуждают бездари.

Смешно. Именно текущие разработчики ввели CI/CD, миллионы автотестов, линтеры и санитайзеры и всегда работающий и готовый к деплою в прод main и т. д.

Деды не знали даже что такое юнит тесты, достаточно посмотреть на Xlib как представителя какие плохие практики использовали деды.

Смешно. Именно текущие разработчики ввели … и всегда работающий и готовый к деплою в прод main и т. д.

Последнее особенно сильно.

Деды не знали даже что такое юнит тесты,

Вполне себе знали.

достаточно посмотреть на Xlib как представителя какие плохие практики использовали деды.

Не показатель. Мне кажется - Вы подменяете понятия. И таки да - я действительно вижу разницу мировосприятия между поколениями. Нынешняя молодёжь (так это назовём) за деревьями леса не видит. Условные «деды» привыкли докапываться до сути сами и не на кого не надеятся. Я очень хорошо помню времена когда основным девизом было «хочешь лучше - сделай сам». Нынче, к сожалению, всё совсем по другому.

Помогите Васе, Пете и Коле не поубивать друг друга.

Уголовный кодекс (УК РФ)

Особенная часть (ст. 105-361)

Раздел VII. Преступления против личности (ст. 105-157)

Глава 16. Преступления против жизни и здоровья (ст. 105-125)

Статья 105. Убийство

Надо заставить прочитать каждого из них эту и смежные статьи про насилие.

Помогите Васе, Пете и Коле не «поубивать» друг друга.

Теперь мы исключили рукоприкладство и перешли в зону психологического насилия, лидерства и доминирования. Очевидно, что лидера этим людям нехватает (иначе бы вопросов что делать не возникало). Тут помогут уставы внутренней службы и система званий.

всегда работающий и готовый к деплою в прод main

Гхм… я тут пару раз пытался поставить LinuxMint - и каждый раз это превращалось в какие то хтонические танцы с бубном и адищенский глюкодром на выходе. Вынужден сидеть на Ubuntu - она мне не нравится, но хотя бы работает. Правда у предыдущей Ubuntu LTS (20й) сдохла пакетная база или как там оно называется и становить что либо стало вообще невозможно несмотря на всякие update/upgrade.

Буквально две недели назад мы разворачивали свой код на стороннем сервере и налетели на баг линкера - раздельная компиляция просто не работала. То есть работала, но .so-шка не импортилась, какой то системный символ не находился. Через три часа плясок с бубном я уходя попробовал собрать все одним вызовом g++ - взлетело.

Так что про всегда работающий код - это шутка такая? Пока что я вижу что процент отказов кода в релизах неуклонно растет.

Деды не знали даже что такое юнит тесты

На сегодняшний день самой отлаженной программой ЕМНИП является TeX Дональда Кнута. Уж не знаю знал дед Дональд про юнит-тесты или не знал…

Это происходит только если новая реализация публична.

Это происходит в любом случае. Если реализация публична - N+1 библиотоека есть у всех, если не публична - у всех по прежнему есть N библиотек, а у нас есть N+1 из которых та самая одна с милыми нашему сердцу шлюхами и блэкджеком;-)

В целом, я сам конечно склонен к велосипедостроению. Моется тот кому лень чесаться, а либы пишет тот кому лень гуглить;-)

Последнее особенно сильно.

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

Можешь взять за образец: https://github.com/microsoft/STL

Когда приходит дата релиза просто делают текущий срез репы и всё.

Всё всегда должно быть протестировано и работать.

Деды это не понимают. Как пример недавний обсер Столмана когда он выложил свой мануал по С, и там не собирался pdf, можешь поискать ветку на лоре.

Для старого софта это сплошь и рядом, когда нет тестов, когда тесты не проходят, когда даже программа не компилируется. Когда инструкции сборки не полные и собирается только на компьютере автора.

У современного программиста в принципе не возможны эти ситуации, потому что CI не даст закомитить код, который ломает сборку/тесты. А то что в сборка тестируется во всяких докерах позволяет достичь повторяемости и устраняет риск сборки только на компьютерах авторов.

Культура разработки сейчас на порядки выше чем у дедов.

На сегодняшний день самой отлаженной программой ЕМНИП является TeX Дональда Кнута. Уж не знаю знал дед Дональд про юнит-тесты или не знал…

Приводить в пример сложной программы - однопоточную программу без GUI, которой никто не пользуется.

Дед Дональд в принципе не решал сложных инженерных задач.

Просто чтобы ты понял, вот олимпийские игры 1972 года: https://cs14.pikabu.ru/video/2022/09/26/1664156985249068207_608x1080.webm

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

В программировании ещё сильнее разница между сейчас и тогда.

Когда приходит дата релиза просто делают текущий срез репы и всё.

Существуют разные модели разработки. Знаете сколько у меня в среднем релизов в прод в день? 5-10. Extreme programming в полный рост.

Деды это не понимают.

Как то нынешний президент нашей конторы (на тот момент он им не являлся) мне сказал что адекватная оценка рисков приходит годам к 37. И с сегодняшней своей колокольни - я с ним согласен.

У современного программиста в принципе не возможны эти ситуации

Издеваетесь? Читаем про комбинаторный взрыв.

потому что CI не даст закомитить код, который ломает сборку/тесты.

За слом nightly у нас, мягко говоря, ебуть. Уже лет 30 как.

Культура разработки сейчас на порядки выше чем у дедов

Я умоляю.

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

И кстати, нет в однопотоке ничего плохого. Подавляющее число наших аппликух - именно однопоточны. Вы не кошек не любите, вы их готовить не умеете.

С ходу вспоминается только openbox, который тыщу лет уже не развивается потому что совершенен.

И все было прекрасно. Но сейчас Линукс практически перешел на Wayland. И что дальше? Пользователь ВМ просто поменяет его на что-то другое, а вот в ситуации ТС’а, если случится что-то подобное, придется вбухать огромное кол-во человекочасов, чтобы это переделать.

Приводить в пример сложной программы - однопоточную программу без GUI, которой никто не пользуется.

С алгоритмической т.з. тех куда сложнее чем 99% того что крутиться на рядовом десктопе. И техом очень даже пользуются, особенно те кто решают действительно сложные инженерные задачи. Скажем техом пользуюсь я и 100% моих коллег.

Дед Дональд в принципе не решал сложных инженерных задач.

Кнут заложил алгоритмический фундамент для решения таких задач.

В программировании ещё сильнее разница между сейчас и тогда.

И да и нет. Да - потому что компьютеры стали мощнее, их стало больше, команды стали больше и индустрия вышла на новый уровень. Нет - потому что средний уровень разработчика сейчас сильно упал. Технологии для того и нужны что бы уменьшать порог вхождения и делать возможным массовый рекрутинг.

Любите аналогии - их есть у меня. Кто более квалифицированный воин, средневековый йомен с длинным луком или современный стрелок срочник с калашом? Понятно что стрелок с калашом положит столько лучников насколько у него хватит патронов. Но йомен учился стрелять с детства, и физуха и куча нюансов. Курс молодого бойца сейчас - три месяца что ли…

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

Хорошо, начинай. Qt vs GTK

Петя дело говорит. Нужно использовать самые современные версии. А то через несколько лет говно мамонта станет ещё старее и говнистее.

Смешно. Именно текущие разработчики ввели CI/CD, миллионы автотестов, линтеры и санитайзеры и всегда работающий и готовый к деплою в прод main и т. д.

Ага, из-за этого я сейчас бинарно патчу приложение, так как мне проще БИНАРНО ПАТЧИТЬ, чем поставить все эти ваши докеры и дженкинсы, без которых это модная дрисня просто не собирается. В какой-то момент я даже принял свою ограниченность, наплевал и растоптал свои идеалы и сделал apt-get install docker. И оно высрало ошибок кучу и теперь при каждой новой инсталляции любого пакета напоминает о себе ворохом ошибок.

Теперь мы исключили рукоприкладство и перешли в зону психологического насилия, лидерства и доминирования. Очевидно, что лидера этим людям нехватает (иначе бы вопросов что делать не возникало). Тут помогут уставы внутренней службы и система званий.

Но я и есть тимлид, пм, пр, цео и другие страшные буквы. Чо писать-то?

потрать пару часов и пройди бесплатный курс по docker для самых маленьких: https://stepik.org/course/123300/syllabus

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

Даже открывать не буду. Мне нужен курс «как не считать докер чем-то из мира айфонно-соевых куколдов(тм)» или хотя бы курс «Как наплевать на своё мировозрение за последние 40 лет и принять ограниченность». Ну так получилось, что мне даже думать о таких технологиях ПРОТИВНО.

Но я и есть тимлид, пм, пр, цео и другие страшные буквы. Чо писать-то?

Мне не ясно в чём Ваша проблема. Что считаете правильным, то и пиши́те. На всё воля неба, если напишете неправильное, то ответственность сама настигнет Вас - вы разоритесь (CEO же).

«А если я скажу тебе что...» Это все эскобаропроблемушки в случае именно этих «библиотек»?

Просто в команде либо все или кто-то их знает и «тянется к привычному молотку»(и обычно может обосновать применимость для задач проекта), либо... если никто — вам один фиг придется учиться и в процессе выяснять, подходят они вам («для чего?» «Чтобы что?») Или нет. Особенно без инфы для чего вам эти комбайны библиотек. В оппосте этого почему-то нет, а перечисленные задрочки про релизы и «вдруг понадобится» — последнее о чем нужно волноваться. (Скорее всего не понадобится, а умрет в бэклоге — особенно в формулировке «портирование проекта на BeOS, OS/2 и ZX-Spectrum», т.к. это все некотуально, если пример вообще адекватен) Тут обычно либастрал еще свежий советуют в таких случаях.

Итого: перечисли класс(ы) задач какие надо покрыть, будет ясно, Qt, Gtk... или это таки эскобар и эквичленно (обычно именно так и есть, но... вдруг удивишь).

«А если я скажу тебе что…» Это все эскобаропроблемушки в случае именно этих «библиотек»?

Вообще, когда я писал первый пост, я имел в виду именно эти библиотеки. На самом деле я начал выписывать себе некоторое сравнение характеристик и обнаружил, вопрос более общий, большинство вопросов можно задать любой библиотеки вообще, потому захотелось выделить какие-то критерии, применимые к любой либе.

Особенно без инфы для чего вам эти комбайны библиотек.

Вот прямо сейчас я делаю парочку мелких приложений, в них нужно бы сделать интерфейс для выбора файла, выбора директории, пары комбобоксов и все. Фактически просто один экран с настройками. Но выбрать нечего, в десктопной версии параметры задаются через прилагаемый bat-ник, а в ведропорте все данные захардкожены, чтобы «юзер» мог просто запустить мой говнокод.

«портирование проекта на BeOS, OS/2 и ZX-Spectrum», т.к. это все некотуально, если пример вообще адекватен

Это было написано на случай изобретения своего велосипеда. И велосипед реально портируется, правда в моем случае, на данный момент, только на Ведроид. А поскольку у меня фановый проект, то запуск его на Спектруме - вполне возможная цель.

Итого: перечисли класс(ы) задач какие надо покрыть, будет ясно, Qt, Gtk… или это таки эскобар и эквичленно (обычно именно так и есть, но… вдруг удивишь).

Класс задач: покрытие психологических проблем автора, развитие прокрастинации, эскапизм.

Вообще я генерирую вот такое вот безобразие: https://www.youtube.com/watch?v=7BSaI5GRmQE

Код самой графики написан на GLES - натырено с ShaderToy, обвязка над этим на OpenGL, аппаратное кодирование средствами… MediaCodec - частью фреймверка Ведроида. Не стреляйте в программиста, он не только программит как умеет, но и рендерит на том, что имеет (мобила мощнее компа). К генерации привлекаются сторонние мимокрокодилы, которым предлагается запустить троян. А у трояна ничего нет, даже внятного прогресс-бара. Звук генерируется из картинки при помощи ffmpeg и какой-то магии. Все параметры захардкожены в говнокоде, что крайне неприятно.

Задача минимум: сделать выбор директории с шейдерами, директории с выходным видео, параметры размера кадра, FPS, настройки кодека и тому подобное.

Задача максимум: сделать полноценный видеоредактор, который будет иметь таймлайн и возможность расставлять ключевые точки для тех или иных параметров, выбирать режимы генерации звука, и шобы можно было это слышать сразу, а не через 2 часа после рендеринга. Это задача максимум и конечно же делать я этого никогда не буду, у меня на простой конвертор ушел целый год. Но забывать это дело не хочу, душа требует…

Параллельно я уже лет 5 пишу^h^h^h^hпрокрастинирую свой видеоредактор. С настоящим таймлайном и собственными муксерами/демуксерами. Начинал писать его для ПК, но после того, как ПК помер, таргет сменился на Ведроид. И потому хотелось бы как-то переиспользовать все это безобразие. Основной проблемой ПК-версии был как раз поиск графического фреймверка, чтобы можно было сделать множество мелких окошек и как-то их докать в основное окошко, перетаскивать внутри него, раскладывать по вкладочкам и тому подобное. Ну и тогда, как и сейчас, все идет к написанию своего велосипеда «универсальной графической библиотеки».

Если говорить о «универсальной графической библиотеки», то у меня сразу въетнамские флешбеки, так как пару лет назад я работал над одним хайповым проектом, где я делал… Графическую подсистему для микроконтроллера. Толком ничего не сделал, но желание доделать осталось. Отсюда и zx-spectrum и все остальное. К генерации шейдеров это отношения уже не имеет, но идея «сделать свою супербиблиотеку и уже наконец-то с ней зарелизить свое говно» с каждым днем все сильнее.

Фактически просто один экран с настройками.

Для этого — эквичленно. Можешь фронтенды как перчатки менять. Они даже могут быть не частью бинаря, а тупо лончерами, собирающими строку параметров. Собственно, прототип ты можешь даже на Tk зафигачить или вообще на bash+dialog(1) для сосноли :)

запуск его на Спектруме

В виде чего?

И велосипед реально портируется, правда в моем случае, на данный момент, только на Ведроид.

на ведроид и у меня портировалось в лет — просто потому что написано было сразу в «систем-агностик», а гуй на Qt, если нужно, вообще пристегивается в виде плугина (обычно так не делают, но мне было лень делать из проги библиотеку и дергать ее из разных фронтендов, а тащить Qt там, где он не нужен не нужно :)). Уверен и на мак вкорячится, с поправками на сборку бандла вместо apk. Только вот платформы эти мутируют в «недружественном» ни к юзеру, ни к разработчику направлении.

Можешь фронтенды как перчатки менять.

Это очень больно. Сначала ты ломаешь себе голову идеологией того или иного инструмента, учишь глоссарий. К примеру, кто мог придумать, что editbox, который так называется почти во всех либах, в GTK зовется как entry? Я этот Энтри 2 часа искал и не понимал, что я вообще ищу. Потом ты смотришь на это безобразие, на километровую лапшу и понимаешь, что ХВАТИТ ЭТО ТЕРПЕТЬ. Берешь Qt. И тут тебе со всех сторон в систему устанавливаются сотни говн вроде qmake или qtdesigner. Оно вроде как даже работает, но на твоем калькуляторе тормозят и вызывают еще больше головной боли. В отчаянии берешь и верстаешь, аки HTML в коде… И все это вызывает еще больше головной боли. Через месяц ты смотреть на это не можешь, а мысли о верстке GUI вызывает или желание убивать, или желание полежать. И никогда не вставать.