[Homeros] I: Linux Journal о Luwrain

[Nikita]

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

> Если даже знаю, что в меню есть
> некоторый пункт, могу делать поиск с целью ускорения доступа к
> нему.

Ну в этом же случае должна быть горячая клавиша?
Быстрее нажать горячую клавишу, чем вбивать название элемента, пускай и 
частично.

> Что это даёт при
> правке кода, даже упоминать неприлично.

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

> именно вездесущность - это самое очевидное
> счастье в emacspeak. Это же просто очевидно.

Вот как раз вездесущность меня и напрягает.
Может я какой-то странный, но у меня обычно стоят разграниченные задачи: 
найти только в коде или найти только в меню.
В коде у меня итак в любом редакторе есть поиск по тексту, а в меню иногда 
бы это может и было полезно, но я не уверен, что горячие клавиши это бы не 
вытеснили. По крайней мере, мне кажется, что я бы по-прежнему пользовался 
именно горячими клавишами.
Для себя область применений этого я сейчас вижу лишь в очень развесистых 
меню, но ирония в том, что они характерны для таких приложений, аналогов 
которых в Luwrain, боюсь, не будет.
К слову, в новом Microsoft Office есть подобная командная строка. Причём она 
даже понимает формы слова и синонимы. Там, действительно, такое меню, что 
для него уже понадобилась своя поисковая система даже для зрячих. :-)

> GUI предназначен для того, чтобы на него смотреть. Там объекты имеют
> видимую часть и невидимую. Причём они неравноправны. Видимые части более
> важны, чем невидимые. Для незрячего человека это неравноправие
> бессмысленно. В Luwrain нет деления на видимое и невидимое.

Но в месте с этим и деление на "важное" и "неважное" тоже в явной форме 
отсутствует, так как есть просто сплошной текст, так что неравенство ты 
устранил снижением визуальной информативности, а не повышением невизуальной. 
:-)

> задействование видеоперехвата меня наводит на мысль, что доступ к
> невидимой части несколько специфичен.

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

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

Если этот контент есть в окне, пускай и, например, в свёрнутом виде, то 
можно.
Другой вопрос, что из-за визуальной ориентированности интерфейс может 
разрабатываться таким образом, что ненужные элементы не просто скрываются 
или сворачиваются, а вообще удаляются из дерева объектов. Но тут фишка в 
том, что это как раз делается тогда, когда эти элементы не нужны.
Например, если у тебя не введён пароль в авторизационную форму, то и кнопка 
"Войти" в этот момент тебе не нужна и её отрисуют только тогда, когда чем-то 
будет заполнено поле ввода пароля.

> кое-что про WinAPI я помню, и это мне сообщает, что проблемки будут.

Они, действительно, будут. Но основная проблема в том, что обход некоторых 
типов меню - это достаточно адское занятие. Например, новые ленточные меню с 
кучей выпадающих подменю индексировать будет сложно.
Luwrain, конечно, выигрывает нативностью решения, которое будет работать 
тупо быстрее и стабильнее. Хотя если в Luwrain будут нормальные горячие 
клавиши для пунктов меню, то я не очень понимаю, что заставит их искать, а 
не вызывать клавиатурными командами.
Успехов. Никита.