Многие приложения (например, 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) и это лишь немногие из тех, кого была бы рада принять любая команда разработчиков.
Перевод из моего блога.
Автор: usefree
