[Homeros] Q: Терминал в MacOS

[Nikita]

Здравствуйте, Michael Pozhidaev.

> Оооп, минуточку. В этом месте  можно, пожалуйста, развернуть Вашу мысль?

Я был бы с такими просьбами по-осторожнее, потому что я могу завестись и 
безумно растечься мыслью по древу, ударившись в сравнение разных подходов и 
средств доступности на очень многих платформах. :-)

> Я крайне жаден до концептуальных проблем чего бы там ни было, так что за
> ценную аналитическую информацию вынесу респект!

Я всё-таки постараюсь тезисно, чтобы кратко донести основную мысль.
У accessibility в OS X есть масса проблем, часть из которых хронические не 
исправляющиеся ошибки, например, скачки высоты и громкости синтезатора в 
зависимости от объектов GUI, часть - просто недоработки, потому что 
разработчикам не хватает знаний в каких-то областях, например, в Брайле, а 
часть как раз является фундаментальными концептуальными проблемами.
К последней группе я бы отнёс две основные вещи:
Во-первых, сама Mac OS исторически была ориентирована на мышку. Если верить 
официальной биографии, то Джобс даже испытывал реальную неприязнь к 
курсорным клавишам на клавиатуре.
Полноценная навигация с клавиатуры в системе невозможна. Даже самые 
банальные вещи без мышки там не сделать.
В итоге, VoiceOver вынужден обходить это двумя путями: либо повальной 
навигацией по экранным контролам, либо прямой эмуляцией мышиных действий. 
Для VoiceOver является вполне рядовой ситуацией фиксировать точку, затем 
эмулировать на ней зажимание мышки, потом фиксировать вторую точку, 
эмулировать перетаскивание мышки на неё и отпускание. Это реально те 
действия, которые должен достаточно часто выполнять слепой пользователь OS 
X.
В Windows и обычно в оконных интерфейсах для Linux клавиатурное управление 
дублирует практически всё, а в OS X даже между кнопками диалога не всегда 
возможно переместиться с клавиатуры.
На мой взгляд, путь обеспечение невизуальной доступности через прямую 
эмуляцию мышки - это, пожалуй, один из самых неудачных путей, по которым 
только можно пойти, если вообще не самый неудачный.
Во-вторых, VoiceOver использует последовательную линейную навигацию по 
экранным контролам. То есть мы открываем окно и дальше начинаем 
последовательно перемещаться по всем его дочерним объектам.
Одна из самых слабых мест этой идеи заключается в том, что в этой цепочке 
объектов очень много хлама.
Например, в углу окна, как правило, есть три маленькие цветные кнопочки для 
закрытия, сворачивания и восстановления размера. Очевидно, что они нужны 
далеко не всегда, а скорей даже иногда.
С точки зрения визуальной работы они и не бросаются в глаза, потому что 
находятся в углу. Но вот для пользователя VoiceOver они-то попадают в 
цепочку навигации.
В итоге, цепочка последовательного перемещения по экранным элементам для 
слепого пользователя всегда начинается с этих самых кнопок. Потом туда ещё 
попадает иконка программы, а уже только после всего этого начинается 
актуальное содержимое окна.
В визуальном интерфейсе можно сделать элементы более акцентированными и 
менее акцентированными, за счёт размеров, цвета, расположения. А вот в 
невизуальном они получаются все одинаковой степени акцентированости.
При полном переборе всех объектов окна с VoiceOver для нас одинаковую 
значимость получают и второстепенные и первостепенные элементы, что, на мой 
взгляд, является возможно даже самой страшной ошибкой разработчиков Apple.
Да, с одной стороны, мы вроде как достаточно неплохо защищены от того, что 
есть риск пропустить какой-то элемент окна, но за это мы расплачиваемся 
катастрофической потерей производительности из-за необходимости продираться 
через все второстепенные элементы, а также просто статические объекты типа 
меток label или иконок. А главное каждый из таких элементов представляет 
собой как бы отдельный этап навигации, то есть если сначала идёт иконка, 
потом label, а только потом кнопка "ОК", то до этой самой кнопки нам надо 
добираться в три шага, дабы прошагать два предыдущих статических объекта.
В общем вот вы всё ругаетесь на Windows, говоря, что там ваша работа 
существенно замедляется. Если бы вы попробовали OS X, то, боюсь, тогда 
вообще бы застрелились. :-)
Там для увеличения производительности можно обвешаться скриптами и просто их 
дёргать при необходимости, но это очень трудоёмкое решение и не очень 
масштабируемое на высоковариативные задачи.
Именно поэтому лично в моих глазах Luwrain на OS X намного более 
востребован, чем на Windows, потому что он сможет предложить реально более 
производительную альтернативу даже базовым задачам, типа чтения почты, тогда 
как на Windows в таких вещах преимущества Luwrain для меня как раз не 
очевидны, потому что там не всё так запущено, как на OS X.
Есть и много других проблем реализации accessibility OS X, но это уже 
отдельный и очень долгий разговор. Самые фундаментальные проблемы, на мой 
взгляд, именно вот в том, что я описал.
Успехов. Никита.