О статье

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

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

Что такое desktop-уведомления?

Десктоп-уведомления – сообщения пользователю, отображаемые на рабочем столе. Вроде, всё просто, да..?

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

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

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

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

Для всех десктоп-уведомлений в дистрибутивах Linux существует базовая спецификация Desktop Notifications Specification. У любой версии Linux, ориентированной на десктоп, есть подсистема, основанная на данной спецификации.

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

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

Что есть интересного в Desktop Notifications Specification?

Body HTML

Возможность отображения примитивного HTML-контента: сделать шрифт жирным, курсивом, подчёркнутым, вставить в уведомления гиперссылки или локальные изображения. Заметим, что полная поддержка HTML-контента, как и с современными браузерами, не рекомендуется по спецификации.

Actions

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

Sound

Воспроизведение звука при получении уведомлений. Некоторые клиенты при отправке уведомления сами воспроизводят звук, если были на это настроены. Но в Linux есть возможность передать, какой звук должен быть воспроизведён на стороне сервера уведомлений, и не воспроизводить на стороне приложения.

Capabilities

В первую очередь нужно понять, что может сервер уведомлений. Узнать все возможности можно запросом «GetCapabilities». Если сервер уведомлений не способен, например, отображать HTML, то отправлять сообщение с HTML-содержимым не нужно, а стоит отправлять простой (plain) текст.

Как это использовать для моих приложений?

Этот раздел написан как раз для разработчиков. Здесь можно найти библиотеки и утилиты, которые помогут с выбором основы для взаимодействия с сервером уведомлений. Все приведённые ниже API могут работать на любых серверах уведомлений в разных дистрибутивах Linux, которые поддерживают данную спецификацию. Также стоит отметить, что все приведённые библиотеки и утилиты есть в ОС Astra Linux, их можно использовать в базовой системе, а если они не были установлены в системе изначально, то можно установить из наших репозиториев.

Заключение

Напомним, что есть множество других способов взаимодействовать с сервером уведомлений, но в данном материале были рассмотрены самые базовые, которые могут понадобиться для разработки приложений. Применение каждого API имеет варианты: вы можете выбрать библиотеку libnotify как основу взаимодействия с сервером уведомлений для своего приложения, а отладку производить с помощью «dbus-monitor», и для тестирования сервера уведомления использовать python c модулем gi и библиотекой libnotify. Выбор за вами.

Если вы хотите освещения каких-то других тем, пожалуйста, напишите об этом в комментариях. Мы могли бы рассказать о спецификации более подробно, а точнее: как реализовывать взаимодействия с сервером уведомлений, что нужно делать на стороне приложения. Также мы хотели бы рассказать о библиотеке KNotifications, так как в KDE Plasma разработчики пересмотрели и расширили работу с десктоп-уведомлениями для своей графической оболочки, отказавшись от некоторых возможностей в спецификации. А может, кому-нибудь захочется обзорную статью о том, как с точки зрения пользовательского интерфейса операционная система может взаимодействовать с пользователем для уведомления его о событиях в системе или конкретных приложениях — написать об этом тоже вполне реально.