Приветствую всех.
Виктор, ты, вероятно, забыл, с чего начал: с утверждения, что бессмысленно использовать
VBS в Cobra, потому что там нет функционала, который нужен скриптам скринридера.
Тебе пояснили, что этот функционал там есть и расширять возможности скриптового
движка дополнительным функционалом -- это подразумеваемая (!) возможность любого
(!) встраиваемого скриптового движка. Об этом даже речи не идет, потому что это
само собой разумеется!
Ты упрямо твердил, что в VBS нет и не может быть ничего полезного для скринридеров,
из чего следует, что ты не только со скриптовыми движками не знаком, но и не
знаешь, как в MS Windows реализована поддержка скриптинга, встраиваемого в приложения.
Так что извини, но это факт.
> 43 функции
> и 9 событийных функций.
> как бы меня не убеждали что это очень классно
> мне как то не очень верится что подобным количеством пусть даже при просто
таки
> супер качестве можно хотя бы близко подойти к тому функционалу что есть у JAWS
Тебе эту статью дали, чтобы ты не заблудился в описаниях функций и понял принцип
использования скриптовых движков, а не для того, чтобы ты сравнивал функционал
недавно появившегося бесплатного скринридера с его платным конкурентом, который
уже лет 15 или более того окучивает рынок.
Кроме того, количество скриптовых функций в JAWS -- это не достоинство, а его
беда, указывающая на то, что процесс расширения языка скриптов JAWS идет стихийно,
концептуально не выдержан, функции добавляются на скорую руку под конкретную
проблему или баг (поэтому их функционал часто перекрывается или дублирует друг
друга). Сам язык тоже лишен сколько-нибудь явно выраженной продуманности, единообразия
в подходах и т.п. Вот ты можешь объяснить, зачем нужна строгая типизация, когда
сам движок втихую занимается неявным преобразованием из одного типа в другой
(например, строк в целое и наоборот).?
> интересно насколько в этом плане продвинута кобра и nvda?
По поводу Cobra напиши Павлу -- он предлагал выслать документацию для разработчиков.
Думаю, функционал у Кобры будет почище, более структурирован и менее походить
на нагромождение функций JAWS -- бессмысленное и беспощадное.
В NVDA, если ты до сих пор не в курсе, вообще нет пользовательских скриптов как
таковых. Python используется в NVDA не как скриптовый язык, а как язык разработки
приложения и среда его выполнения.
> можно конечно сказать что JAWS на рынке давно и мы просто его скрипты лучше
знаем
Некоторые просто больше ничего не знают.
> производителей скринридеров в плане подробной
> документации,
> и объясняется что в итоге не смотря на все прелести и правильности как питона
> так и vbs
По VBS документация гораздо полнее, чем по скриптовым функциям JAWS (не говоря
уже о том, что выражение "полнота документации" к скриптам и скриптовым функциям
JAWS никак не подходит).
Плюс документация от разработчика скринридера по добавляемым объектам и т.п.
> мы имеем то что имеем:
> на JAWS скриптов пишется во многие разы больше чем на прочие скринридеры скорее
> всего вместе взятые.
Рынок JAWS гораздо больше, чем рынок Virgo (а других коммерческих скринридеров
с поддержкой скриптов до 2008 г. я что-то не припомню, либо их рынок ничтожно
мал).
> но например Сергей буквально на днях был одним из тех кто приводил данные о
том
> что NVDA
> при всей правильности её скриптов почему то потребляет ресурсов в несколько
раз
> больше чем тот же JAWS с его неправильными скриптами.
Во-первых, не "в несколько раз". Во-вторых, не ресурсов, а конкретно процессорное
время. А главное, он ни слова не обмолвился о причинах, по которым NVDA загружает
процессор, больше чем JAWS. То есть виноваты ли в этом скрипты или нет, он не
сказал ни слова.
И еще раз: в NVDA нет поддержки скриптов! Там нет скриптов в принципе.
Ты же не называешь программы на JAVA, C# или C++.Net скриптами, а они по сути
не отличаются от программ на python -- тот же байт-код, та же виртуальная машина.
> видимо информация о том что скрипты JAWS так уж плохи всё таки сильно приувеличена.
Во-первых, до этого твоего сообщения никто не говорил, что скрипты JAWS плохи.
Речь шла о том, что как средство разработки скриптов язык сценариев JAWS уступает
VBS.
Надо понимать, что любая среда разработки включает два важных компонента:
1. реализацию языка программирования;
2. среду исполнения (в простейшем случае это run-time библиотека функций).
Так вот речь шла о языке(!) сценариев JAWS, а не о скриптовых функциях (которые
относятся ко второму пункту, то есть это run-time библиотека).
Язык (в том числе и язык программирования) -- это средство выразить свои мысли
(в программировании -- выразить алгоритмические мысли).
Если язык позволяет выразить мысль ясно и недвусмысленно при помощи наименьшего
числа конструкций, то это хороший язык. Если ты вынужден конструировать какие-то
трехэтажные трудновыговариваемые выражения, чтобы выразить совсем простую мысль,
то это плохой язык программирования.
Он плох и потому что твой трехэтажный код будет трудно понять другому человеку
(или тебе самому через какое-то время), и потому что, строя сложное выражение,
ты рискуешь сделать гораздо больше ошибок, чем когда пишешь просто.
Ошибки -- это время, которое ты тратишь на их поиск. Сложные выражения -- это
время, которое ты тратишь на его понимание.
У тебя много лишнего времени? И ты готов принести его на алтарь скриптинга под
JAWS?
Если программирование для тебя -- это хобби, то возможно, ты компенсируешь потраченное
время тем удовольствием, которое получаешь от процесса. Но не у всех это так...
> теперь внимание вопрос,:
> (приходится отмечать это особенно чтобы не получить ответов подобных тем что
> получил в прошлых письмах)
Ну, разумеется, ты опять получишь такие ответы, потому что невнимательно читаешь
то, что тебе пишут остальные.
> то тогда все разговоры о том что vbs в прочих скринридерах даёт какие то приимущества
> мне не понятны.
Перечитай предыдущее мое сообщение -- там явно и недвусмысленно указано, что
не "какие-то преимущества", в вполне конкретные: время и деньги.
Встроить поддержку доступа к спец. функционалу в уже существующий, отлаженный,
присутствующий в ОС по умолчанию скриптовый движок проще, быстрее, менее затратно,
чем писать этот самый движок с нуля.
Вот Freedom купила/стащила/разработала сама свой скриптовый движок и вот тянет
на себе уже не первый десяток лет бремя развития этого движка и его сопровождения
(тянет, конечно, без особого усердия, но время и деньги на это уходят, а столь
актуальный функционал все равно появляется гораздо позже, чем он становится необходимым
для скриптописателей). Возможно, Freedom таким образом создает рабочие места
для инвалидов по зрению, но ты не задумывался, за чей счет?..
В случае VBS бремя по развитию и сопровождению тащит на себе Microsoft, а разработчику
скринридера остается лишь сопровождать свой собственный компонент, который дает
доступ из скриптов к специфическим функциям.
> или обращения из языка скриптов JAWS напрямую или через wsh чем то отличаются
> от обращения из vbs и js
Отличаются своей недоделанностью.
> уж если я незнал о серьёзной документации по этой теме
А ты ей интересовался???
Если интересовался, то знаешь, что Cobra еще официально не вышла как стабильный
релиз, Window-Eyes реализовала поддержку скриптинга лишь с 2008 г., а материал
по скриптингу в Virgo лежит на тифлокомпе с незапамятных времен.
> может есть смысл выложить на тифлокомпе текущую документацию по расширениям
vbs
> для кобры
1. Думаю, ближе к официальному стабильному релизу это будет доступно на сайте
разработчика (как, например, fsdn).
2. Вопрос копирайтов: целиком выложить нельзя, надо разбивать на статьи и переписывать.
3. Если перепишешь (желательно на русском), то непременно выложу.
> и питона для nvda.
Документация по питону входит в состав дистрибутива этого языка. Документации
для разработчиков e NVDA нет (или почти нет) -- см. исходники (без этого все
равно ничего не сделаешь).
> или ссылки разместить.
Присылай. Буду очень признателен.
Успехов. Анатолий.