Столкнулся с проблемой: при печати из Inkscape изображения получаются очень мелкими.
Гуглинг
навёл на то, что это проблема с xdg-desktop-portal-kde. Парень из форма создал
Bug Report в котором есть возможный WA. И там же есть отсылка на
репорт в самом проекте Inkscape.
Если коротко: xdg-desktop-portal это некая сущность (или сучность?) которая позволяет приложениям на различных тулкитах более бесшовно интегрироваться в “неродные” окружения рабочего стола: Gtk в окружение KDE и Qt в окружения на базе Gtk (Gnome, Cinnamon, Mate & etc). Интеграция по большей части затрагивает только переиспользование стандартных системных диалогов, типа диалогов открытия файлов, сохранения, вывода окон предупреждений, диалогов печати (тут отдельный акцент). В общем, все те вещи, которые вроде более приятны глазу, но жить без них можно (“вам шашечки или ехать?”). Но и дополнительный слой абстракции, который сам по себе может нести баги.
Собственно проблема как раз и заключается в стыке разных сред при использовании диалога печати. Причём
сначала поддержку Desktop Portal реализовали в Inkscape и сразу же это вызвало
проблемы.
Ладно, теперь к сути. Мне ехать нужно. Решение в лоб это общесистемно заявить:
Собственно после чего все приложения Gtk в окружении KDE станут использовать Gtk диалоги. Как оказалось, если использовать в массе, так себе. К визуалу тоже быстро привыкаешь :)
Поэтому достаточно сделать следующее:
- Меню
- Находим Inkscape
- ПКМ → Изменить приложение…
- Вкладка Приложение
- В поле “Переменные окружения” вставляем
GTK_USE_PORTAL=0
- OK
Теперь:
- если открыть Inkscape через меню или быстрый запуск, он запустится с этим значением
- если открыть SVG файл через Dolphin, то он тоже откроется с этим флагом
Если открывать через терминал ручками: inkscape file.svg, то имеет смысл завести alias с установкой переменной окружения в нужное значение. Если в скриптах (хммм), то указать явно в скрипте.
Когда ходили
нонстоп после нефтебазы немного не туда сунулись по пути на Капитанский мостик, но возникло жаление по осени прогуляться тут с сыном, просто посмотреть, куда идут дороги. Сентябрь пришёл, время реализовывать планы. Что бы долго не тянуть выбрали 7 сентября.
Внезапный поход на вершину, которую ещё не доводилось сходить. Сходили 17-18 августа, но руки написать дошли только сейчас.
С праздником всех причастных!
Век живи, век учись, а дураком помрёшь.
Открыл для себя чудную утилиту timeout из состава coreutils.
Делает ровно то, что описывает её название: запускает команду, переданную как аргумент, на заданное время в секундах (s), минутах (m), часах (h) или днях (d):
timeout 10s ping ya.ru
sudo timeout 10s tcpdump -i wlan0 -Q in -A udp
Обратите внимание: если команда должна быть выполнена под sudo, то sudo должно стоять перед timeout.
По истечении таймаута передаётся сигнал TERM в дочерний процесс. Если нужен другой, то укажите его через аргумент -s SIGNAL. Утилита дополнительно может послать сигнал KILL, если команда не отреагировала на сигнал TERM по истечении таймаута, указанного через параметр -k TIMEOUT. Прочие вкусности смотреть через --help, хотя их там, по большей части, и нет.
Или: казалось бы, при чём тут Firefox…
Заметка в мемориз, на случай когда /var/lib/docker/overlay2 весит неприлично много.
Первое:
вывод такой:
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 2 0 4.467GB 4.467GB (100%)
Containers 0 0 0B 0B
Local Volumes 6 0 0B 0B
Build Cache 193 0 21.39GB 21.39GB
Images - тут скорее то, что нужно. Чистим стандартными средствами:
- Смотрим образы:
docker images
- Удаляем ненужные:
docker rmi <IMAGE_ID>
Containers - аналогично:
- Смотрим через:
docker ps -a
- Удаляем:
docker rm <IMAGE_ID>
Local Volumes:
- Чистим:
docker volume prune
Build Cache:
- Чистим:
docker buildx prune
У меня большую часть занимал именно Build Cache. При последущей перестройке образов будет дольше. Но у меня этот процесс не частый, так что не критично.
Короткая заметка касательно пакета Quaternion для Octave. И, скорее всего, специфичная для ArchLinux/Manjaro.
Итак, пакет ставится из AUR:
Для использования в Octave нужно выполнить:
Ну а дальше всё согласно
документации:
octave:2> q = quaternion(1)
q = 1 + 0i + 0j + 0k
Но где-то на этом шаге можно получить ошибку:
Происходит это, обычно, после обновления Octave, когда меняется версия API: пакет собирает библиотеку для текущей версии API Octave и помещает её в то место, где Octave может её найти согласно версии API:
/usr/lib/octave/packages/quaternion-2.4.0/x86_64-pc-linux-gnu-api-v59/
Решение: просто пересобрать пакет после обновления Octave:
yay -S --rebuild octave-quaternion
Душевно прогулялись по маршруту руч.Смольный-Фалаза-Капитанский мостик-руч.Смольный.
28 апреля - 1 мая 2024.
19 марта началось составление планов на первые майские по части похода с простого, но ёмкого вопроса-предложения Ксюши в нашем походном чатике:
Давайте замутим поход на майские?
Сразу же поступила пара предложений от Жени. Точнее одно, но с вариациями. Вариация первая - совсем по лайту. Но места интересные, для меня ещё нехоженные. Вариация вторая - при прочих вводных разведать дорогу и подняться на г.Синяя… не по Икрянкам.
Других предложений не было (у меня вообще с идеями в последние годы как-то не очень), поэтому по отсутствию возражений остановились на первом варианте: водопад Зуевский, скальный массив “Белый город”, Еломовские водопады и радиальный выход на гору Лысая.
Группа собралась из пяти человек:
- Я, т.е. Саша
- Женя
- Маша
- Ксюша
- Алина
Как-то забывал сделать заметку, что данный ноутбук поддерживает обновления встроенных прошивок (как минимум BIOS и далее по накату: UEFI, System firmware, EC и так далее) через через
Linux Vendor Firmware Service (LVFS), для его используется пакет
fwupd.
Несколько месяцев назад у меня на ровном месте перестала работать Ethernet карточка, обновление FW решило вопрос в положительном русле.
У меня последовательность обновлений выглядит так:
sudo fwupdmgr get-devices
sudo fwupdmgr refresh --force
sudo fwupdmgr get-updates
sudo fwupdmgr update
Перед началом лучше закрыть всё лишнее и быть готовым к запросу на перезагрузку. Ну и питание от сети лучше не отключать.
Хотел на Khadas VIM3 выключить DWC3 (USB Host controller), сделал оверлей, поместил в /boot/dtb/overlays/kvim3, добавил запись в /boot/env.txt и… получил кирпич.
Оверлей простой и, вроде, правильный (в конце приведу), но система отказалась загружаться. Возможно на его клоки или ещё что что-то завязано, что не даёт ядру загружаться дальше. Но возникает резонный вопрос: “Шо делать!?”
Дальше посмотрим один из вариантов, как это можно решить. Возможно пригодится и на других платформах.
Дошёл до Manjaro и переезд на KDE6. В лучших традициях жанра, альтернативы в виде KDE5 не оставили.
Но не так страшен чёрт оказался. Правда, при моих 141 DPI (1080p при мониторе 15.6", скрипт для Octave для расчёта
тут) пришлось повозиться.
Если ничего не менять, то всё мелко. Если следовать рекомендациям и ставил глобальное масштабирование в 150%, которое и даёт DPI 144, то всё становится адово огромным. При этом установка DPI меняет не только шрифты, но и размеры элементов интерфейса (б$@). В результате вспомнил, что как только у меня QtC стал собираться с Qt6 в какой-то апдейт он тоже стал на моих 141, полез в мой родной .qtc-override (это моя самодеятельность, не обращайте внимание) и выставил теперь для всей системы то, что стояло для Qt Creator:
export QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor
что дало то, что мне прямо вот нужно!
Прописал этот параметр в ~/.config/plasma-workspace/env/dpi.sh. Для других окружений можно, например, в ~/.profile или в ~/.config/environment.d/dpi-plasma.conf, но в виде без export:
QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor
Детали:
При этом ложка дёгтя остаётся. Глобальное масштабирование рьяно требует шага в 6.25% (на X11). Как я выше писал: для 15.6" монитора при FullHD матрице - это 141 DPI. Два ближайшие значения глобального скалирования, кратные 6.25% это:
- 150%, что даёт DPI 144
- 143.75%, что даёт DPI 138
И мои 141 аккурат по середине: 3 пункта вверх и 3 пункта вниз. Ни туда, ни сюда. 138 DPI подходит, наиболее близко для новых матриц в 16". Но для X11 остаётся возможность вручную скорректировать DPI на вкладке Fonts, хотя они и не рекомендуют делать этого. На Wayland сессии этой возможности нет, но, вроде, нет и ограничения на кратность 6.25% (а ещё можно кратность меньше 100% задать). Wayland сильно не тыкал палочкой, так как там нужный мне VirtualBox тупо не работает (точнее гостевые OS с GUI, типа Windows 10).
Короче, что-то у них хреново с промежуточными DPI отличными от 100..200..300% но хоть такие ручки есть.
Ну и резюмируя:
- Указываем переменную
QT_SCALE_FACTOR_ROUNDING_POLICY (у меня в RoundPreferFloor)
- На X11:
- Ставим глобальный масштаб (“Input & Output” → “Display & Monitor” → “Display Configuration”) в ближайшее значение, что даёт 141 DPI, для простоты пусть будет 150%
- Корректируем DPI в 141 в настройках шрифтов (“Appearance & Style” → “Fonts” → “Fonts” и “Force Font DPI” в нужное значение). Или не трогаем, если вас всё устраивает. Плюсом не трогать: per-monitor работа.
- На Wayland:
- Судя по всему, только ручками глобального масштаба.
ЗЫ да, напоминаю, что 100% - это 96 DPI, поэтому все множители отсюда и пляшут. Исторически сложилось. Хотя на странице со
скриптом-калькулятором физически у мониторов может быть любая дичь.
В субботу 13 апреля Женя Воеводский анонсировал лёгкую прогулку от электрички до электрички на хр.Большой Воробей. В результате мы и сходили от электрички до электрички, но есть нюанс.
И так, в продолжение темы
Conan vs vcpkg. Как я там уже писал с vcpkg подружиться получилось.
