До своего полного перехода на светлую сторону Linux систем в 2008 году, использовал в повседневной жизни MS Windows и XnView для просмотра изображений. Пробегал тут как-то мимо сайта XnView и задумал забежать к своему старому знакомому - как у него теперь дела? Оказалось, что у XnView есть в семействе ещё программы и одна из них XnSketch, позволяющая в пару щелчков мыши наложить эффект на изображение. Некоторые эффекты навеяли мне мысль о Призме, но XnSketch работает локально и ничего не отправляет на сервера с нейронными сетями. Беглый осмотр архива был очень обманчив, казалось, что автор программы сделал на 100% portable версию для линукс систем, бери и пользуйся, но это оказалось далеко не так.
Статья носит исторический характер. Автор программы сам начал паковать своё детище в flatpak формате и мне лучше самоустраниться. Данную программу вы легко найдёте в графическом установщике Ubuntu Software и KDE Discover.
Прежде чем садиться паковать, следует добиться работы программы так как задумал автор. Запускающий shell скрипт xnsketch.sh манил своей простотой и намекал что будет всё хорошо.
#!/bin/sh
dirname="$(dirname "$(readlink -e "$0")")"
export LD_LIBRARY_PATH="$dirname"/lib
export QT_PLUGIN_PATH="$dirname"/lib
"$dirname"/XnSketch "$@"
Но программа тупо падала в segfault, выводя в Терминале только одну путеводную звезду - QCursor: Cannot create bitmap cursor; invalid bitmap(s)
Начал гуглить и читать всё что могло помочь. Набрёл на обсуждение спецов по Qt, которые обсуждали схожую проблему и наводили на мысль, что что-то не так с кодом в программе типа
QPixmap pix("cursor.png"); QCursor cur(pix); lbl.setCursor(cur);
Исходников программы нет и решил сильно не зацикливаться, логично предполагая, что ошибка QCursor говорит о последствии, а не о причине. Прошёлся по всем файлам-библиотекам *.so в подкаталоге lib/ с помощью утилиты ldd и нашёл что в чистой виртуальной машине с Ubuntu 16.04 LTS для программы нет:
libicui18n.so.54 => not found
libicuuc.so.54 => not found
libicudata.so.54 => not found
С помощью sudo updatedb && locate libicu
нашёл более новые версии библиотек в системе, но именно 54 - нет. Хитрая попытка сделать нужный симлинк с нужным именем на текущую библиотеку часто выручала, но не в этот раз. Сбегал на packages.ubuntu.com и packages.debian.org, а там либо 52 версия, либо 57. Да что же это такое!? Пришлось пойти на сайт проекта International Components for Unicode (ICU), взять именно 54 версию и скомпилировать её из исходников на сборочном сервере. Подкинул скомпилированные библиотеки в lib/, но это решило проблему лишь с not found, но падения программы продолжались.
Увеличил уровень отладки с помощью переменных:
export QT_DEBUG_PLUGINS=1
export QML_IMPORT_TRACE=1
Строк стало больше, но толку мало. Решил подключить тяжёлую артиллерию в лице strace. Начал читать огромный журнал трассировки и параллельно анализировать архив 32 битной программы и версию программы под MS Windows. Оказалось, что программа делает попытку прочесть lib/imageformats/, но такой папки нет в архиве с линукс версией, а виндовая версия содержала dll файлы. Взял первое попавшееся имя файла, но вместо расширения .dll представил мысленно .so и сделал запрос к apt-file для поиска пакета, который мог бы содержать такой файл. Ответ привёл к пакету qt5-image-formats-plugins, в котором были все нужные библиотеки. Скачал пакет и распаковал файлы в lib/imageformats/ и всё!
Программа перестала падать и показалась во всей красе.
Программа не была на 100% portable, но теперь стала. Осталось скопировать её на сборочный сервер и попросить snapcraft упаковать в снап пакет. Он доступен вам через графический GNOME Software или в терминале - sudo snap install xnsketch
Здесь хотелось бы заострить внимание на досадном моменте, который связан с технологией ограничений Snappy через AppArmor и seccomp. Я понимаю, что AppArmor и SELinux призваны своей мощью мандатного доступа (MAC) ограничить программы друг от друга и от системы, но когда Canonical решила увеличить роль AppArmor в традиционной Убунту и поставить во главу стола AppArmor в Ubuntu Core, то нужно было не упустить момент с визуальным отображением GUI программ. Ведь встречают по одёжке, а провожают по уму. Графическая программа в snap пакете часто выглядит безобразно, как будто ты вернулся в прошлое. Программа, находясь в тюрьме профиля системы мандатного доступа, имеет доступ к системным вещам только через интерфейсы, которые заранее были запрошены.
В чём именно затык у разработчиков я точно не знаю, но нашёл баг годичной давности Graphical snaps don't follow the window theme и даже написал разработчикам в почтовой рассылке. Дескать, что мне делать прямо сейчас!? Что добавить к программе внутрь snap пакета? Может есть какой-то ещё полезный интерфейс помимо добавленных x11, home, unity7, gsettings? Может как-то улучшить эталонный скрипт desktop-launch, который делает 100500 полезных штук перед запуском программы? Одни вопросы и ответов нет. Думаю всё даже ещё хуже. Нет ви́дения у разрабов как идеально реализовать вопрос - контролируемый допуск программы к системному оформлению. Итог один - программа XnSketch красиво выглядит только в Ubuntu с Unity 7 и в Kubuntu. Если учесть, что snap пакет по определению самодостаточен, то есть "всё своё ношу с собой", то почему это не касается визуального отображения?
Конкурент snap flatpak уже решил ситуацию с оформлением At Last! Flatpak Apps Can Now Be Themed и статья заканчивается словами - snappy твой ход! Но если почитать комментарии, то там станет понятно что у flatpak свои тараканы. Надеюсь, разрабы snappy быстрее очнутся от своего сна - на носу выход Ubuntu 17.10 с Gnome по умолчанию + сессия Wayland.
Дата последней правки: 2023-12-27 09:03:02