Переработанный API уведомлений скоро появится в Gnome

от автора


Многие приложения (например, Skype, Lifearea, Dropbox и т.д.) по-прежнему используют старый механизм уведомлений в Gnome Shell, некрасивый да еще и неудобный в использовании как на десктопе, так и на планшете.
В то время как модель отображения уведомлений с помощью GtkStatusIcon перестала развиваться, появившийся на горизонте новый API уведомлений несет с собой решение уже накопившихся проблем и некоторые полезные нововедения!
Matthias Clasen указал на проблемы в текущей реализации и отметил необходимость в новом API, а Cosimo Cecchi, уже работающий над ним, рассказал о преимуществах нового API. Конечно, новый API принесет много полезного и, прежде всего, он реализует все те цели, которые были поставлены в начале работы над Gnome 3.

Matthias Clasen говорит:

«Понятно, что GTK+ должен предоставить такой API уведомлений, используя который приложения перестанут обращаться со своими мелочами к отдельной библиотеке (libnotify). Вместо этого будет использоваться наш API.»

Требования к API уведомлений:

  • наличие четкой связи между уведомлением и приложением, его сгенерировавшим. Необходимо сделать фильтр уведомлений, основанный на приложении, как это сейчас реализовано в системных настройках.
  • позволить доставку уведомлений в будущее и разрешить такие функции уведомлений как запуск приложений — без этого приложения, у которых запланированы действия по расписанию, должны постоянно работать в фоновом режиме (типа evolution-alarm-notify) или генерировать уведомления через посредников (типа уведомления от менеджера обновлений, генерируемого через gnome-settings-daemon).

Проблемы с GtkStatusIcon:

  • Корень проблемы кроется в том, что приложения должны экспортировать небольшой фрагмент пользовательского интерфейса на «панель».
  • Предполагается, что все рабочие столы предоставляют приложениям на постоянной основе специальное место («системный трей»), в котором те выводят свою иконку и выпадающее меню.
  • Необходимо чтобы приложение постоянно работало в фоновом режиме, если его иконка находится в этом «системном трее».
  • Реализация Х использует XEmbed и из-за этого не может нормально работать в составной среде.
  • Реализация win32 также проблематична.

Проблемы с libnotify:

  • Отсутствие четкой связи между уведомлением и приложением, его сгенерировавшим.
  • Необходимость работы приложения в фоновом режиме как условие присутствия иконки в системном трее.
  • Проблематичный жизненный цикл объектов уведомлений.
  • Отдельная библиотека без поддержки OS X и win32.

Новый API.

Mathias говорит:

«GtkApplication — очень хороший кандидат для реализации на его основе API уведомлений, так как уведомления должны быть связаны с приложениями. Без дополнительной работы мы получаем ID приложений и другие метаданные такие как: имя шины, иконки, переведенные имена, дескрипторы и прочее. Нам также доступно повторное использование GAction для действий. А в GAction уже есть очень гибкий механизм состояний (основанный на GVariant), который позволяет реализовать доставку уведомлений в будущее и выполнение уведомлений без необходимости приложению работать постоянно в фоне.»

Cosimo Cecchi уже приступил к работе над новым API по вот этой спецификации.

Cosimo описывает некоторые преимущества для Gnome.

«Трансформировать старую модель уведомлений в новый API довольно сложно, учитывая перечень проблем, обозначенных в письме Mathias-a. Сейчас мы не планируем автоматически трансформировать иконки статусов приложения в уведомления — Shell по-прежнему будет поддерживать отображение статусов приложений в иконках трея и уведомления, реализованные старым методом через libnotify. Приложения сторонних разработчиков должны быть переработаны для того, чтобы иметь возможность использовать новый механизм уведомлений в полном объеме.»

Преимущества для Gnome:

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

Цели:

  • Отдельно содержание и представление уведомлений.
  • Отсутствие необходимости активного подключения для получения уведомления (надежная доставка уведомлений).
  • Возможность фоновых приложений информировать пользователя.
  • Возможность незапущенных приложений информировать пользователя.
  • Возможность удаленным приложениям информировать пользователя как локальным.
  • Возможность сервисным подсистемам информировать пользователя как локальным приложениям.
  • Возможность запуска приложения или выведения его на передний план для выведения важной информации.
  • Возможность добавления в приложения специфических действий с уведомлениями.
  • Поддержка изменения пользователем политики уведомлений (возможность настройки того, что может прервать какой процесс и когда).
  • Возможность приложений удалять или отменять уведомления.
  • Поддержка следующей информации для всех уведомлений: Иконка приложения, Имя приложения, Заголовок, Тело.
  • Поддержка дополнительной необязательной информации: дополнительные графические данные, специфические звуки.

Возможности пользователю:

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

Дополнительные задачи:

  • поддержка позиционирования уведомлений
  • поддержка времени отображения уведомлений
  • поддержка категорий уведомлений
  • поддержка классификации уведомлений по важности
  • поддержка возможности клиент\серверного обмена уведомлениями

Когда это появится в Gnome?

Эта работа уже начата, и даже если новый API появится в Gnome 3.8, полный список характеристик появится позже, так как он требует нового Центра управления Gnome, работа над которым еще не закончена.

Mathias говорит:

«Мы не уверены, что реально закончить эту работу до выхода Gnome 3.8 Скорее всего переход на новый механизм будет в несколько этапов. Сначала мы представляем GtkNotification API (к Gnome 3.8) и лишь к Gnome 3.10 мы полностью реализуем новый механизм. GtkStatusIcon будет запрещен после окончательной реализации нового механизма.»

В общем работа кипит в Gnome, и его будущее выглядит очень привлекательно. Помимо разработчиков, которые работают непосредственно в Gnome, как Matthias, Jasper, Cosimo и других, есть некоторые выдающиеся имена, Emanuelle Bassi (Clutter), Kristian Høgsberg (Wayland), Lennart Poettering (systemd) и это лишь немногие из тех, кого была бы рада принять любая команда разработчиков.

Перевод из моего блога.

ссылка на оригинал статьи http://habrahabr.ru/post/158519/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *