https://www.opennet.ru/opennews/art.shtml?num=57741
Вышел #gtk 4.8.0
Что они сделали нового, можно почитать по ссылке.
А что сломали - у меня!
Для сборки gtk4 требуется набор xml файлов от wayland. Фактически, это такой хреново сделанный protobuf + protoc + , собственно, сами xml(proto) файлы.
Эти файлы требуются только для сборки, но коллеги из gtk зачем-то впилили runtime зависимость от этих файлов. Пришлось выкорчевывать ее sed'ом - https://github.com/pg83/ix/blob/main/pkgs/lib/gtk/4/ix.sh#L39
Насчет runtime я не уверен, в pkg-config с этим сложно. В том плане, что вот написано, что gtk4 зависит от wayland-protocols. Это что значит? Что wayland-protocols нужны в runtime, или нужны для сборки зависимых от gtk4 целей?
Вышел #gtk 4.8.0
Что они сделали нового, можно почитать по ссылке.
А что сломали - у меня!
Для сборки gtk4 требуется набор xml файлов от wayland. Фактически, это такой хреново сделанный protobuf + protoc + , собственно, сами xml(proto) файлы.
Эти файлы требуются только для сборки, но коллеги из gtk зачем-то впилили runtime зависимость от этих файлов. Пришлось выкорчевывать ее sed'ом - https://github.com/pg83/ix/blob/main/pkgs/lib/gtk/4/ix.sh#L39
Насчет runtime я не уверен, в pkg-config с этим сложно. В том плане, что вот написано, что gtk4 зависит от wayland-protocols. Это что значит? Что wayland-protocols нужны в runtime, или нужны для сборки зависимых от gtk4 целей?
www.opennet.ru
Доступен графический тулкит GTK 4.8
После восьми месяцев разработки опубликован релиз многоплатформенного тулкита для создания графического интерфейса пользователя - GTK 4.8.0. GTK 4 развивается в рамках нового процесса разработки, который пытается предоставить разработчикам приложений стабильный…
👍4
В батле "статическая vs. динамическая линковка" есть один фактор, про который особо никто не рассказывает, ну или мне просто не встречалось раньше.
Это эстетика!
Причем не простая эстетика, что, дескать, в случае статической линковки по всей fs не валяются всякие разные .so, про которые, без пакетного менеджера, не сказать, откуда они и для чего нужны. Это лежит на поверхности, и не очень интересно.
Я как-то, когда рассказывал про #mesa, вскользь упоминал про то, как она собирается.
Речь шла про то, что, в процессе сборки 3 .so-шек собирается 10 .a-шек, и они каким-то, достаточно произвольным, образом, объединяются в соответствующие .so файлы, с использованием linker script для сокрытия общих частей.
Зачем так делается? Почему бы не сделать 10 .so-шек, которые просто линкуются друг с другом, как им и положено, и нет этой магии с дублированием кода и всего прочего?
Этого требует эстетика динамической сборки!
Потому что негоже вываливать на пользователя кучу непонятных .so, без какого-то понятного scope, которые делают невесть что. Надо отдать пользователю понятный набор артефактов, с понятным scope, а то, что между ними код дублируется - кого это волнует?
Кстати, ровно в эту же тему можно отнести мой недавний рассказ про дублирование символов в библиотеках #gtk и #wayland. Это же с ума сойти - выделить эти 3 несчастные функции в какую-то совершенно artificial библиотеку, как ее продать пользователю, как опакетить в дистрибутивах, и прочие неприятные вопросы.
И, наоборот, статическая линковка стимулирует к появлению бОльшего количества более гранулярных зависимостей, потому что это артефакты исключительно времени сборки, и их не видит пользователь. Поэтому они могут быть произвольно всратыми, хоть по 1 функции в каждой, если так удобно, все равно вживую это никто не увидит.
(пример такого разделения библиотек на части - в следующей серии, и так уже много текста)
Поэтому внутренняя эстетика, присущая тому или иному способу линковки, на самом деле, диктует то, как код будет разбит на модули, и (мое личное мнение) статическая сборка приводит к более лучшему, отражающему суть кода, разделению.
Это эстетика!
Причем не простая эстетика, что, дескать, в случае статической линковки по всей fs не валяются всякие разные .so, про которые, без пакетного менеджера, не сказать, откуда они и для чего нужны. Это лежит на поверхности, и не очень интересно.
Я как-то, когда рассказывал про #mesa, вскользь упоминал про то, как она собирается.
Речь шла про то, что, в процессе сборки 3 .so-шек собирается 10 .a-шек, и они каким-то, достаточно произвольным, образом, объединяются в соответствующие .so файлы, с использованием linker script для сокрытия общих частей.
Зачем так делается? Почему бы не сделать 10 .so-шек, которые просто линкуются друг с другом, как им и положено, и нет этой магии с дублированием кода и всего прочего?
Этого требует эстетика динамической сборки!
Потому что негоже вываливать на пользователя кучу непонятных .so, без какого-то понятного scope, которые делают невесть что. Надо отдать пользователю понятный набор артефактов, с понятным scope, а то, что между ними код дублируется - кого это волнует?
Кстати, ровно в эту же тему можно отнести мой недавний рассказ про дублирование символов в библиотеках #gtk и #wayland. Это же с ума сойти - выделить эти 3 несчастные функции в какую-то совершенно artificial библиотеку, как ее продать пользователю, как опакетить в дистрибутивах, и прочие неприятные вопросы.
И, наоборот, статическая линковка стимулирует к появлению бОльшего количества более гранулярных зависимостей, потому что это артефакты исключительно времени сборки, и их не видит пользователь. Поэтому они могут быть произвольно всратыми, хоть по 1 функции в каждой, если так удобно, все равно вживую это никто не увидит.
(пример такого разделения библиотек на части - в следующей серии, и так уже много текста)
Поэтому внутренняя эстетика, присущая тому или иному способу линковки, на самом деле, диктует то, как код будет разбит на модули, и (мое личное мнение) статическая сборка приводит к более лучшему, отражающему суть кода, разделению.
👍13🤔7🔥5😁1🆒1
commit -m "better"
#harfbuzz https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1220100263 Маски, наконец-то, сброшены, и владелец проекта сказал(как и нужно было сказать с самого начала!), что с этим ничего поделать нельзя. В общем-то, и понятно, им нужно или:…
https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1369649173
#harfbuzz
На этот раз в тикет пришелвеликий и ужасный Матиас Класен (я правильно транслитерировал?) - это тот человек, который виноват во всем плохом, что случается в #gtk и #gnome, и снова рассказал, что "ничего нельзя сделать", но я так просто их не отпущу :))
#harfbuzz
На этот раз в тикет пришел
GitHub
Discuss: resolve harfbuzz<->freetype circular dependency via a C header-only hb-ft.h implementation · Issue #2524 · harfbuzz/harfbuzz
This concept occurred to me while discussing the problems with the current circular dependency between these two libraries. Essentially, we could pull the contents of hb-ft.cc out into hb-ft.h, and...
🔥7👍5❤1🐳1
#rant
Я тут разбирался, почему у меня перестал собираться транковый #epiphany, выяснил, что они совершенно не стесняются заносить обратно-несовместимые изменения в нестабильную ветку gtk, и собираться с ней.
Само по себе это даже норм, кроме того факта, что они, зачем-то, переименовывают функции, вместо того, чтобы добавить новое имя, подождать, что старые использования отомрут, и тогда удалить старое название. Ну, вот такое вот чувство прекрасного у людей.
Но мой сегодняшний текст про другое.
Пока я грепал интернеты на предмет политики изменения epiphany и gtk, наткнулся на вот этот замечательный пост, https://blog.gtk.org/2022/12/15/a-grid-for-the-file-chooser/
(Кстати, пост написан небезызвестным нам господином Класеном)
Пост про то, как какой-то там рефакторинг в #gtk дал возможность запилить фичу, которую пользователи хотели последние 18 лет!
https://bugzilla.gnome.org/show_bug.cgi?id=141154
Теперь, после рефакторинга, это стало "easily possible now".
Прочел я это, сел, и задумался - очень мне интересно, что творилось в голове у человека, который 18 лет не давал запилить эту фичу(потому что #errogant разработчикам #gnome/gtk казалось, что оно будет сделано криво), и, наконец, написал в своем бложике "Judging from the number of likes on the merge request, this is a popular feature. We hope you enjoy it", и "It only took us 18 years"!
Реально, я это читаю как "мы 18 лет не делали популярную/нужную фичу, потому что нам казалась некрасивой/неправильной возможная реализация".
(да, я читал тред в багзилле, и я прекрасно понимаю, что, на самом деле, люди имеют в виду, когда пишут в такой ситуации "ну вы запилите патч, а мы на него посмотрим")
Иногда мне кажется, что разработка некоторых open source проектов totally broken.
Я тут разбирался, почему у меня перестал собираться транковый #epiphany, выяснил, что они совершенно не стесняются заносить обратно-несовместимые изменения в нестабильную ветку gtk, и собираться с ней.
Само по себе это даже норм, кроме того факта, что они, зачем-то, переименовывают функции, вместо того, чтобы добавить новое имя, подождать, что старые использования отомрут, и тогда удалить старое название. Ну, вот такое вот чувство прекрасного у людей.
Но мой сегодняшний текст про другое.
Пока я грепал интернеты на предмет политики изменения epiphany и gtk, наткнулся на вот этот замечательный пост, https://blog.gtk.org/2022/12/15/a-grid-for-the-file-chooser/
(Кстати, пост написан небезызвестным нам господином Класеном)
Пост про то, как какой-то там рефакторинг в #gtk дал возможность запилить фичу, которую пользователи хотели последние 18 лет!
https://bugzilla.gnome.org/show_bug.cgi?id=141154
Теперь, после рефакторинга, это стало "easily possible now".
Прочел я это, сел, и задумался - очень мне интересно, что творилось в голове у человека, который 18 лет не давал запилить эту фичу(потому что #errogant разработчикам #gnome/gtk казалось, что оно будет сделано криво), и, наконец, написал в своем бложике "Judging from the number of likes on the merge request, this is a popular feature. We hope you enjoy it", и "It only took us 18 years"!
Реально, я это читаю как "мы 18 лет не делали популярную/нужную фичу, потому что нам казалась некрасивой/неправильной возможная реализация".
(да, я читал тред в багзилле, и я прекрасно понимаю, что, на самом деле, люди имеют в виду, когда пишут в такой ситуации "ну вы запилите патч, а мы на него посмотрим")
Иногда мне кажется, что разработка некоторых open source проектов totally broken.
👍9🤡4🤔2🔥1🐳1
commit -m "better"
https://nullprogram.com/blog/2023/01/18/ #pkgconfig Оч. странный чувак, я пару раз уже кидал ссылки на его блог. Хотел кинуть и на предыдущую его заметку про SDL - https://nullprogram.com/blog/2023/01/08/, но мне, почти про каждый пункт из нее хотелось сказать…
https://nullprogram.com/blog/2023/02/11/
Коллега зачем-то рассматривает С runtime (libc), и, несмотря на то, что, как вежливый западный человек, вывод он явно не делает, он лежит на поверхности - ничего из libc использовать не надо.
Я бы сказал, что и С в современном мире использовать не надо, но, к сожалению, прямо адекватной замены С пока нет:
* C++, Go - имеют нетривиальные runtime.
* С++, Rust - слишком сложны для "портабельного ассемблера", из них надо половину выкинуть. (*)
* Zig - это вообще не язык программирования, а тонкая прослойка над llvm bitcode (я так пытаюсь схохмить на тему, что у Zig получилось быть еще более низкоуровневым, чем C)
Вот и коллеги из #gtk думают, чем бы им поэкспериментировать на замену С - https://blog.gtk.org/2023/02/09/updates-from-inside-gtk/
Думаю, возьмут Vala, а никакой там не Rust.
(*) (upd): я тут еще добавлю такую очень opinionated штуку - в С++/Rust слишком много любят мономорфизацию, что ведет к существенному code bloat.
Коллега зачем-то рассматривает С runtime (libc), и, несмотря на то, что, как вежливый западный человек, вывод он явно не делает, он лежит на поверхности - ничего из libc использовать не надо.
Я бы сказал, что и С в современном мире использовать не надо, но, к сожалению, прямо адекватной замены С пока нет:
* C++, Go - имеют нетривиальные runtime.
* С++, Rust - слишком сложны для "портабельного ассемблера", из них надо половину выкинуть. (*)
* Zig - это вообще не язык программирования, а тонкая прослойка над llvm bitcode (я так пытаюсь схохмить на тему, что у Zig получилось быть еще более низкоуровневым, чем C)
Вот и коллеги из #gtk думают, чем бы им поэкспериментировать на замену С - https://blog.gtk.org/2023/02/09/updates-from-inside-gtk/
Думаю, возьмут Vala, а никакой там не Rust.
(*) (upd): я тут еще добавлю такую очень opinionated штуку - в С++/Rust слишком много любят мономорфизацию, что ведет к существенному code bloat.
👍11🔥2🥰1
https://www.phoronix.com/news/Qt-6.5-LTS-Released
Вышел новый #QT, и ничего такого не случилось - все приложения собрались, и продолжили работать, как им и положено.
Разве что, разрабы опять сломали сборку в кросс-компилируемом окружении, но они это делают наждый раз, я даже начинаю думать, что разрабы берут деньги за суппорт. Хммм...
"With Qt 6.5's multimedia support the FFmpeg back-end is now the default for macOS / Windows / Android / desktop Linux while for embedded systems GStreamer is the default"
Теперь, по умолчанию, для проигрывания видосов используется ffmpeg, и это очень, очень хорошо. Чем быстрее помрет фабрика по загрузке .so с диска под названием #gstreamer, тем лучше.
Но, на самом деле, мой глаз зацепился за фразу "The Qt 6.5 toolkit brings improved theme and styling support, including better support around dark mode handling on Windows", и я вспомнил, что уже какое-то время хочу рассказать, что, наконец, понял, почему авторы #gtk/#gnome так хейтят сторонние темы!
Считайте меня слоупоком, но я это понял совсем недавно.
В #gtk виджеты не совсем виджеты, а, по сути, настройки для канвы.
Все очень и очень похоже на html + css, берешь любой div, приделываешь к нему рамки из картинок, навешиваешь onClick(), и, пожалуйста, это не div, а уже кнопка.
Поэтому сделать кастомную тему для gtk - это как сделать кастомную css тему для нескольких веб сайтов одновременно. Иногда даже может работать, но, чаще всего, ползет какая-то херня из всех углов!
Что я пока не понимаю - перешли ли разработчики QT на темную сторону со своими qt quick, или еще не перешли.
Вышел новый #QT, и ничего такого не случилось - все приложения собрались, и продолжили работать, как им и положено.
Разве что, разрабы опять сломали сборку в кросс-компилируемом окружении, но они это делают наждый раз, я даже начинаю думать, что разрабы берут деньги за суппорт. Хммм...
"With Qt 6.5's multimedia support the FFmpeg back-end is now the default for macOS / Windows / Android / desktop Linux while for embedded systems GStreamer is the default"
Теперь, по умолчанию, для проигрывания видосов используется ffmpeg, и это очень, очень хорошо. Чем быстрее помрет фабрика по загрузке .so с диска под названием #gstreamer, тем лучше.
Но, на самом деле, мой глаз зацепился за фразу "The Qt 6.5 toolkit brings improved theme and styling support, including better support around dark mode handling on Windows", и я вспомнил, что уже какое-то время хочу рассказать, что, наконец, понял, почему авторы #gtk/#gnome так хейтят сторонние темы!
Считайте меня слоупоком, но я это понял совсем недавно.
В #gtk виджеты не совсем виджеты, а, по сути, настройки для канвы.
Все очень и очень похоже на html + css, берешь любой div, приделываешь к нему рамки из картинок, навешиваешь onClick(), и, пожалуйста, это не div, а уже кнопка.
Поэтому сделать кастомную тему для gtk - это как сделать кастомную css тему для нескольких веб сайтов одновременно. Иногда даже может работать, но, чаще всего, ползет какая-то херня из всех углов!
Что я пока не понимаю - перешли ли разработчики QT на темную сторону со своими qt quick, или еще не перешли.
Phoronix
Qt 6.5 LTS Released With Many Improvements
Out today is the Qt 6.5 toolkit that is also now the second Qt6 long-term support release.
👍4🔥2❤1🤮1
commit -m "better"
Я давно откладывал эту тему, но вот вышла эта новость, и, видимо, пора: https://www.opennet.ru/opennews/art.shtml?num=56587 "Отмечается, что для полноценной работы приложений на базе SDL в Wayland требуется наличие библиотеки #libdecor для декорирования…
#GNOME #gtk #ssd
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6161
Продолжение темы про server side decorations, жирно, годно.
На этот раз господа из gtk прямым текстом говорят, что wayland - им не указ:
"There is no debate. And this is not a standard. It is an experimental protocol that somebody slapped the xdg name on and merged into the wayland repos. It is not implemented by anybody except sway and kwin"
И ответ:
"Please refrain from making fun of the Wayland community this way. We've worked very hard to reach a consensus among all wayland-protocols members, and it feels like you're dismissing this work"
Тут вот активно форсят тему про планирующийся бой Маска и Цукерберга, а я вот, конечно, хотел бы посмотреть, как подерутся Simon Ser и Clasen, например.
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6161
Продолжение темы про server side decorations, жирно, годно.
На этот раз господа из gtk прямым текстом говорят, что wayland - им не указ:
"There is no debate. And this is not a standard. It is an experimental protocol that somebody slapped the xdg name on and merged into the wayland repos. It is not implemented by anybody except sway and kwin"
И ответ:
"Please refrain from making fun of the Wayland community this way. We've worked very hard to reach a consensus among all wayland-protocols members, and it feels like you're dismissing this work"
Тут вот активно форсят тему про планирующийся бой Маска и Цукерберга, а я вот, конечно, хотел бы посмотреть, как подерутся Simon Ser и Clasen, например.
GitLab
wayland: Update to xdg-decoration protocol (!6161) · Merge requests · GNOME / gtk · GitLab
Updated version of !2191; as such, I've copied basically everything,...
🔥10🐳2
commit -m "better"
#foot https://codeberg.org/dnkl/foot/releases Changed Default color theme is now starlight (#1321). Новый релиз, новая цветовая схема. По крайней мере, его безумие вполне последовательно.
Пока читал changelog, натолкнулся на https://wayland.app/protocols/cursor-shape-v1 (foot его как раз поддержал).
TL;DR - в #wayland теперь можно сказать композитору, какой курсор сейчас отображать по порядковому номеру (значения которых заранее определены и известны), а не загружая кастомную текстуру каждый раз, когда мышка переезжает из окна с #gtk в окно с #QT. Курсоры (при поддержке этого протокола) теперь могут храниться в композиторе, и не загружаться каждым клиентом отдельно.
Короче, чуваки в первый раз в жизни сделали какбоженька велел надо просто, а не как "мы не хотим знать, что вокруг нашего тулкита есть кто-то еще, и хотим все настраивать сами".
UPD: "Copyright 2018 The Chromium Authors Copyright 2023 Simon Ser" - ну, понятно, все #хорошее для Linux Desktop делает гагл, а не какой-то там RH.
Интересно, поддержит ли это #gtk?
TL;DR - в #wayland теперь можно сказать композитору, какой курсор сейчас отображать по порядковому номеру (значения которых заранее определены и известны), а не загружая кастомную текстуру каждый раз, когда мышка переезжает из окна с #gtk в окно с #QT. Курсоры (при поддержке этого протокола) теперь могут храниться в композиторе, и не загружаться каждым клиентом отдельно.
Короче, чуваки в первый раз в жизни сделали как
UPD: "Copyright 2018 The Chromium Authors Copyright 2023 Simon Ser" - ну, понятно, все #хорошее для Linux Desktop делает гагл, а не какой-то там RH.
Интересно, поддержит ли это #gtk?
wayland.app
Cursor shape protocol | Wayland Explorer
A better way to read Wayland documentation
🔥11😁2🆒1
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212
#GNOME #gtk moment
К чувакам пришли с реализацией уже принятого в wayland протокола, на что им, в своей уникальной манере, ответили, что для GTK/GNOME от реализации этого протокола пользы не будет. Речь идет о server side cursor. Попытка решить очень древнюю проблему с неконсистентностью курсовров в разных приложениях (напомню, что поверхность с курсором отдает клиент, и это может быть вообще все, что угодно).
Они, на полном серьезе, сравнивают курсор (который, на минуточку, может быть отрисован не только клиентом, а еще композитором, когда курсор находится вне любого клиента, или клиентом другого DE), и рендеринг шрифтов - https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212#note_2056112
Цикл моих заметок про курсоры в Wayland:
https://t.iss.one/itpgchannel/185
https://t.iss.one/itpgchannel/1214
https://t.iss.one/itpgchannel/246
https://t.iss.one/itpgchannel/854
https://t.iss.one/itpgchannel/1758
Нет слов.
https://www.opennet.ru/opennews/art.shtml?num=60847
А вот "правильный" заход в #Wayland - #SDL говорят, что не будут включать Wayland по дефолту, пока им не запилят два нужных расширения. И тут уж коллегам из Wayland придется прогнуться, потому что один из основных потребителей SDL - Valve, которая сейчас пилит половину десктопного кода под Linux (стек драйверов, компиляторов шейдеров, да и свои компизиторы у них есть https://github.com/ValveSoftware/gamescope). Все #хорошее в графическом стеке Linux делают корпорации!
Будьте уверены, в данном вопросе все пойдет, как по маслу. Потому что одно дело, когда что-то нужно сообществу, тогда можно поломать комедию и повыебываться, а другое дело - когда оно нужно уважаемым людям, которые непосредственно вас кормят.
Вообще, бесит меня этим современный open source, что люди, которые нихуя не делают, а простосидят на трубе обладают паролем от нужного репозитория, палец о палец не пошевелят, пока у задачи не найдется спонсор с деньгами. Если бы эти негодяи просто сами не писали код - это еще полбеды, но они тупо не пропускают нужные изменения в код.
#GNOME #gtk moment
К чувакам пришли с реализацией уже принятого в wayland протокола, на что им, в своей уникальной манере, ответили, что для GTK/GNOME от реализации этого протокола пользы не будет. Речь идет о server side cursor. Попытка решить очень древнюю проблему с неконсистентностью курсовров в разных приложениях (напомню, что поверхность с курсором отдает клиент, и это может быть вообще все, что угодно).
Они, на полном серьезе, сравнивают курсор (который, на минуточку, может быть отрисован не только клиентом, а еще композитором, когда курсор находится вне любого клиента, или клиентом другого DE), и рендеринг шрифтов - https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212#note_2056112
Цикл моих заметок про курсоры в Wayland:
https://t.iss.one/itpgchannel/185
https://t.iss.one/itpgchannel/1214
https://t.iss.one/itpgchannel/246
https://t.iss.one/itpgchannel/854
https://t.iss.one/itpgchannel/1758
Нет слов.
https://www.opennet.ru/opennews/art.shtml?num=60847
А вот "правильный" заход в #Wayland - #SDL говорят, что не будут включать Wayland по дефолту, пока им не запилят два нужных расширения. И тут уж коллегам из Wayland придется прогнуться, потому что один из основных потребителей SDL - Valve, которая сейчас пилит половину десктопного кода под Linux (стек драйверов, компиляторов шейдеров, да и свои компизиторы у них есть https://github.com/ValveSoftware/gamescope). Все #хорошее в графическом стеке Linux делают корпорации!
Будьте уверены, в данном вопросе все пойдет, как по маслу. Потому что одно дело, когда что-то нужно сообществу, тогда можно поломать комедию и повыебываться, а другое дело - когда оно нужно уважаемым людям, которые непосредственно вас кормят.
Вообще, бесит меня этим современный open source, что люди, которые нихуя не делают, а просто
GitLab
wayland: implement cursor_shape_v1 (!6212) · Merge requests · GNOME / gtk · GitLab
This implements https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/194 Let me know if there's a more specific place that _gdk_wayland_cursor_get_enum would fit. Also, would a...
👍12🤯6😭3😢2💯1
#GNOME #gtk #bootstrap #rant
Вот есть такая библиотека https://gitlab.gnome.org/GNOME/gdk-pixbuf
Библиотека умеет загружать примерно 4 формата картинок (если не считать half baked поддержку svg), при этом, она не сама их парсит, а зовет соответствующие библиотеки по разбору форматов.
Казалось бы, 1 раз написал, и все - не надо ее ни трогать, ни дописывать, ничего?
У меня в репозитории лежит версия *.6 - https://github.com/pg83/ix/blob/main/pkgs/lib/gdk/pixbuf/t/ix.sh#L4
Потому что:
В версиях с 7 по 10 сломана сборка gtk3 с ней (А это, на минуточку, один из двух главных потребителей этой библиотеки! Кто второй? gtk4, а вы что думали? Это гномье говно больше никому не нужно, по очевидным причинам)
В версии *.11, которая вышла вчера, починили все ошибки сборки, зато с ней коркается примерно каждое второе gtk приложение, которое ее использует. Кажется, там где-то убрали проверку на 0, и зовут какую-то строковую функцию от nullptr, где-то в инициализации.
Мораль?
Не пользуйтесь кодом от проекта #GNOME, по возможности. Они не то что погромировать не умеют, у них даже работающего CI нет, который должен был бы это все поймать на этапе тестирования.
Вот есть такая библиотека https://gitlab.gnome.org/GNOME/gdk-pixbuf
Библиотека умеет загружать примерно 4 формата картинок (если не считать half baked поддержку svg), при этом, она не сама их парсит, а зовет соответствующие библиотеки по разбору форматов.
Казалось бы, 1 раз написал, и все - не надо ее ни трогать, ни дописывать, ничего?
У меня в репозитории лежит версия *.6 - https://github.com/pg83/ix/blob/main/pkgs/lib/gdk/pixbuf/t/ix.sh#L4
Потому что:
В версиях с 7 по 10 сломана сборка gtk3 с ней (А это, на минуточку, один из двух главных потребителей этой библиотеки! Кто второй? gtk4, а вы что думали? Это гномье говно больше никому не нужно, по очевидным причинам)
В версии *.11, которая вышла вчера, починили все ошибки сборки, зато с ней коркается примерно каждое второе gtk приложение, которое ее использует. Кажется, там где-то убрали проверку на 0, и зовут какую-то строковую функцию от nullptr, где-то в инициализации.
Мораль?
Не пользуйтесь кодом от проекта #GNOME, по возможности. Они не то что погромировать не умеют, у них даже работающего CI нет, который должен был бы это все поймать на этапе тестирования.
GitLab
GNOME / gdk-pixbuf · GitLab
Welcome to GNOME GitLab
👍19😢12🤡6