Скриншот для предыдущего поста. Чтобы было понятие, о чём я писал, что такое LibreOffice Startcenter

В свете бурных изменений в некоторых сообществах хочу отметить следующее. Статьи нашего сообщества могут появляться только на следующих сайтах/репозиториях/etc.:

1. Мой GitHub (репозиторий со статьями, сайт сообщества)
2. Руководство "Linux для себя"
3. Какие-то отдельные части могут быть в документации Calmira GNU/Linux-libre.
4. Сообщество группы в ВК.

Размещение статей оттуда (в первую очередь с сайта сообщества) на других сайтах или появление статей оттуда в иной литературе на других сайтах и/или в иных сообществах и/или в иных источниках до 15.05.2023 считаю недопустимым. Даже в том случае, если когда-либо я сам размещал их в соответствующих источниках. Не допускается публикация любых статей и иной информации сообщества в источниках, расположенных за пределами РФ, либо если владелец источника не является гражданином РФ, за исключением источников, указанных в начале поста. (пример недопустимого использования материалов нашего сообщества).

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

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

https://www.interfax.ru/russia/901159

На hh.ru на каждую вакансию по хрензнаетскольколион просмотров, отзывов и прочей фигни. Плюс всякие отсрочки, хуёчки и прочее. Не работа, а сказка, особенно когда учитель или врач получает условные 10 тыс рублей, а какой-то программист джун - 40. Понятное дело, что работать в IT - вещь всё-таки трудная, но и указанные выше профессии не менее сложны, а из важность быть может даже выше.

Немного про AppImage. Часть 2. Сборка AppImage.

Сегодня поговорим про сборку AppImage пакетов. Именно сборку ПО из исходного кода я пропущу, ибо это достаточно обширная тема, которую нужно затрагивать отдельно. Но как правило, вся сборка пакета из исходного кода сводится к следующим действиям:

1. Скачивание и распаковка архивов с исходным кодом ПО.
2. Конфигурирование пакета.
3. Сборка пакета (компиляция из исходного кода двоичных файлов в формате ELF, генерация иных необходимых файлов).
4. Установка пакета.

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

Для сборки пакета в формате AppImage нам нужно соблюсти следующую структуру каталогов:

APP.AppDir/
APP.AppDir/AppRun
APP.AppDir/app.desktop
APP.AppDir/app.png
APP.AppDir/APPDIR/файлы_программы

Здесь APP - это имя программы, которую мы собираем. Поэтому, если вы собираете программу из исходного кода, установите её в APP.AppDir/!
Если мы собираем Firefox, то вместо APP подставьте Firefox. Файлы app.desktop и app.png содержат файлы для интеграции пакета в систему. Также файл app.png может быть использован для генерации превью файлов с этими пакетами (см. предыдущий пост), точнее не сам этот файл, а ссылка на него, которая автоматически создаётся при создании AppImage.
Замените в именах этих файлов app на имя пакета. Для Firefox пусть будет firefox.desktop и firefox.png.

app.png - это иконка приложения. Обычно она содержится в директории APPDIR/share/icons или иной. Поищите её, она должна быть.

Простейший *.desktop файл выглядит так:

[Desktop Entry]
Name=MyApp
Exec=myapp
Icon=myapp
Type=Application
Categories=Utility;

Параметр Name должен совпадать с APP - именем программы (например, Firefox). Параметр Exec нам здесь не особо важен, ибо вместо него для запуска программы будет использован скрипт AppRun. Icon носит имя иконки программы, которую мы поместили в APP.AppDir/ до создания этого *.desktop. Параметр Categories описывает категории, к которым относится наша программа. В меню окружений KDE, MATE, Xfce и других оно попадёт в указанные категории. Зайдите сюда, чтобы посмотреть список допустимых категорий.

Проверьте *.desktop файл на правильность:

`desktop-file-validate app.desktop`

Если вы собираете программу без графического интерфейса (консольную программу), то обязательно добавьте параметр Terminal=true, чтобы после её возможной интеграции в меню системы мы могли запускать программу в терминале.

APPDIR - это каталог, в который установлена программа. Это может быть opt, может быть usr, тут уже без разницы. Например, у меня для программы Firefox этот каталог называется firefox. Название здесь не критично, но его нужно будет учитывать в будущем, когда мы будем создавать скрипт AppRun для запуска нашего приложения. Самое главное, чтобы из этой директории смогла работать программа и, не менее важное, чтобы из этого каталога мы смогли бы запустить эту программу.

AppRun, как вы поняли, это исполняемый BASH скрипт, запускающий программу из AppImage пакета. Тут возникает вопрос - а как нам запустить программу из пакета? Мы можем указать что-то вроде этого:

#!/bin/bash
./APP/app_name

(где APP - директория с установленной программой, а app_name - название двоичного файла или скрипта - собственно, нужной нам программы).

—== ПРОДОЛЖЕНИЕ В ПОСТЕ НИЖЕ ==—

А ты оформил под-письку на LinuxSovet???

#AppImage

—== ПРОДОЛЖЕНИЕ ПОСТА ВЫШЕ ==—

Но так у нас не сработает. Мы можем просто указать app_name, но и так тоже не сработает. Дело в том, что скрипту AppDir передаются некоторые переменные окружения, которые мы можем использовать для запуска нужных программ из пакета. Одной из них является переменная $APPDIR, которую мы и будем использовать для формирования пути до исполняемого файла программы:

#!/bin/bash
$APPDIR/APP/app_name

(где APP - директория с установленной программой, а app_name - название двоичного файла или скрипта - собственно, нужной нам программы).

Не забудьте сделать AppRun исполняемым:

chmod +x AppRun

Создание пакета

Скачайте отсюда пакет appimagetool. У меня скачан пакет с именем appimagetool-x86_64.AppImage, поэтому показываю на нём. Дайте этому пакету право исполнения: chmod +x appimagetool-x86_64.AppImage и запустите его следующим образом:

./appimagetool-x86_64.AppImage APP.AppDir APP-VERSION-ARCH.AppImage

Замените APP на имя программы, VERSION - на её версию, ARCH - на архитектуру, для которой программа собиралась (например, x86_64). Если всё прошло успешно, то у нас будет собран новый AppImage пакет.

А ты оформил под-письку на LinuxSovet???

#AppImage

К слову, вот так оно выглядит в Caja. Подобным образом и в Nemo.

Немного про AppImage. Часть 3. Превью в Nautilus.

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

Поэтому был написан простой скрипт для создания превью AppImage пакетов в файловых менеджерах типа Nautilus, Nemo, Caja и пр.

Я использую ArchLinux, установка там проста: yay -S appimage-thumbnailer-git. Для остальных дистрибутивов следуйте указаниям из README.md в репозитории проекта (ссылка выше).

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

Также у нас есть дичайший тайный чат для участников канала, только тихо, никому об этом не пишите ;-)

#AppImage

Экран в одном месте, топкейс в другом, всё остальное ещё непонятно где.

Поскольку корпус в ноуте приказал долго жить, решил восстановить его. Чтобы хотя бы экран хоть как-то держался на петлях, а не болтался на соплях, удерживаемый только шлейфом матрицы и WiFi антеной. Поскольку покупка нового железа не предвидется в ближайшие лет 50, это единственный выход

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

Птичку жалко 😰
https://opennet.ru/59193/
#News

В nightly версию Firefox добавили переводчик — наконец-таки. Работает пока так себе, да и браузер сам предупреждает, что перевод на русский пока ещё BETA. Что ж, это лучше, чем ничего. Да, до уровня переводчика в Яндексе (прости Господи) оно не дотягивает, но +- переведённые страницы понятны

#Firefox #Переводчики

Гы, оказывается, эта функция была и в более старых версиях лисы. Работает так же дерьмово

about:config
browser.translations.enable -> true

#Firefox #Переводчики

Раз уж продолжать тему переводчиков, то сегодня для себя открыл DeepL. Услышал про него ещё где-то год назад, но думал, что переводит он не так хорошо, как Yandex или Google. Сейчас же пришлось перевести одну доку по Rust [вот не учил я в своё время буржуйский язык, теперь мучаюсь с переводчиками] — DeepL вполне себе неплохо угадывает контекст и переводит только то, что нужно переводить, а не всё подряд. Красота!

If you find any of these libraries useful, please let us know what
you're using and why you aren't in a mental hospital yet.

В принципе, это справедливо не только к каким-то отдельным либам, но и ко всему Xorg в целом :)

https://flathub.org/ru/apps/io.github.amit9838.weather

О какую красоту написали! Использует GTK4 и libadwaita.

#Soft