Сформулирована дорожная карта работ над доступностью GTK4

Дата:29.03.2020
Источник:GTK Hackfest 2020 — Roadmap and accessibility
Поделиться в Twitter Поделиться в F******k Поделиться в VKontakte Поделиться в Telegram Поделиться в Mastodon

В период с 28 по 31 января 2020 года в Брюсселе прошёл третий GTK Hackfest 2020 - конгресс разработчиков кроссплатформенного фреймворка GTK, являющегося одним из наиболее распространённых решений для создания графических интерфейсов для Unix-подобных систем, в том числе не просто приложений, но и многих графических окружений. После обсуждения графика выпуска тестовых сборок следующей мажорной версии GTK4, а также недостающих возможностей, блокирующих выпуск стабильного релиза GTK 4.0, сообщество перешло к самой объёмной теме данного конгресса - вопросу доступности для пользователей с ограниченными возможностями.

Поддержка специальных возможностей была добавлена в GTK 2.0 в 2002 году командой доступности компании Sun Microsystems. Технически она зависит от абстрактных типов данных, предоставляемых ATK (Accessibility Tool Kit), которые затем реализуются конкретно в классах GTK, таких как GtkWidgetAccessible или GtkEntryAccessible. Каждый виджет имеет связанный с ним доступный объект, который либо автоматически создаётся GTK, либо может быть предоставлен кодом приложения при создании подкласса виджета GTK. С типами, не относящимися к виджетам, также могут быть связаны доступные объекты: наиболее распространённый случай - это набор визуализаторов для древовидных представлений и комбинированных списков. Под всем этим находится AT-SPI (Assistive Technology Service Provider Interface) - протокол, который используется вспомогательными технологиями, например, программами экранного доступа. Обычно вспомогательные технологии для работы с самим протоколом используют библиотеку типа libatspi.

В отношении обеспечения доступности интерфейсов на базе GTK4 в настоящий момент существуют следующие проблемы:

  • Есть множество косвенных причин, вызванных существованием ATK, из-за которых любая новая функция или исправление ошибки должны быть определены внутри ATK, а уже потом внедрены в GTK и libatspi.
  • ATK был написан в совершенно другой среде, и хотя он перенёс некоторое количество модификаций, его возраст всё равно сказывается в допущениях, которые он делает, например, в глобальных координатных пространствах, и в его дизайне.
  • Существует определенное пересечение между требованиями вспомогательных технологий и требованиями для тестирования графического интерфейса, что в конечном итоге создаёт трения в дизайне API.
  • Целостность стека распалась из-за того, что команда по доступности Sun была расформирована. В итоге, большая часть текущей работы всё ещё в значительной степени происходит в пространстве вспомогательных технологий, например, в программе экранного доступа Orca, и в веб-браузерах, вместо того, чтобы предоставляться централизовано уже в готовом унифицированном виде.
  • Весь стек специальных возможностей изначально был написан с ориентацией на стандарт написания распределённых приложений CORBA, а затем был портирован под систему межпроцессного взаимодействия D-Bus, как раз к релизу графического окружения GNOME 3. Однако существующий протокол не очень эффективен и требует много циклических переходов для перемещения небольших объёмов данных вместо массовых операций и уведомлений.

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

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

Поскольку сообщество GTK хочет изменить дизайн и обновить функциональность специальных возможностей в GTK4, то возникла необходимость дополнительного исследования требований со стороны существующих потребителей стека доступности, и на какие варианты использования следует ориентироваться. Для помощи в этом была привлечена компания Hypra, специализирующаяся на разработке доступных решений на основе бесплатного программного обеспечения с открытым исходным кодом.

Разработчики Hypra знакомы с GNOME и работают над стеком доступности Linux. Их клиенты охватывают широкую гамму пользователей с ограниченными возможностями, поэтому они лучше смогут сформулировать, какие типы вспомогательных технологий используются этими людьми в повседневной работе.

Существует широкий спектр инструментов и функциональных возможностей, которые должны быть предоставлены различными уровнями стека доступности, от toolkit до compositor. Разработчики приложений также должны иметь доступ к инструментам, необходимым для обеспечения надлежащей поддержки вспомогательных технологий, поскольку они гораздо лучше представляют, как должны выглядеть и вести себя их приложения.

В итоге, в течение двух дней на GTK Hackfest 2020 был определён следующий план работ:

  • Удалить ATK из стека и заставить GTK напрямую взаимодействовать с протоколом AT-SPI. Это похоже на то, что делает альтернативный кроссплатформенный интерфейсный фреймворк Qt со стороны инструментария, и такой подход облегчает как расширение, так и проверку возможных изменений протокола.
  • Очистить сам протокол AT-SPI, обновляя его там, где это необходимо, когда дело доходит до более эффективного использования D-Bus.
  • Отбросить концепцию глобальной шины доступности и заставить вспомогательные технологии согласовывать одноранговое соединение с каждым приложением.
  • Заставить вспомогательные технологии запрашивать у compositor глобальное состояние, такое как сочетания клавиш, вместо того, чтобы общаться с приложениями, которые затем должны будут запросить оконную систему, если это возможно, или вернуть недействительные данные, когда это не так.
  • Отделить тестирование графического интерфейса от специальных возможностей.
  • Написать виджеты и руководства по созданию приложений для разработчиков программного обеспечения и предоставить инструменты проверки, которые можно использовать как часть процессов сборки и непрерывной интеграции, чтобы проверить, имеют ли элементы пользовательского интерфейса правильное доступное описание и ссылки.

С более подробной информацией по дорожной карте работ над доступностью GTK4 можно ознакомиться в вики. На лето же 2020 года уже назначена следующая встреча ключевых членов команды GTK для дальнейшего обсуждения задач имплементации поддержки специальных возможностей.


Метки


Распространение материалов сайта означает, что распространитель принял условия лицензионного соглашения.
Идея и реализация: © Владимир Довыденков и Анатолий Камынин,  2004-2024