Анализ моей проблемы.
Слепые люди используют программу чтения с экрана для взаимодействия с приложениями.Эти программы чтения с экрана произносят содержимое, сообщения и тому подобное с предпочтительной скоростью речи и другими настройками.С точки зрения разработчика, есть и несколько удобных функций: при передаче текста в программу чтения с экрана она может быть напористой (поэтому прервите программу чтения с экрана) или вежливой (программа чтения с экрана завершает чтение текущего текста, прежде чем перейти к следующему.текст).
Однако некоторые слепые (или слепоглухие) дополнительно или исключительно используют дисплей Брайля.Дисплей Брайля (в идеале) отображает текст, который читает программа чтения с экрана, или подходящую версию.В действительности, многие программы чтения с экрана лишают пользователей дисплея Брайля определенной информации, если они не настраивают свои дисплеи Брайля для чтения журнала чтения с экрана вместо просмотра текущего приложения.
Я создаю звуковую игру споддержка Брайля.Что само по себе необычно - большинство аудио игр - это просто аудио.
Моя первая проблема заключалась в том, чтобы заставить программу чтения с экрана произносить сообщения и одновременно передавать их на дисплей Брайля.Решением этой проблемы стала библиотека абстракций программы чтения с экрана Tolk
. Она работает так, как рекламируется, но есть проблема, которую tolk не может исправить: сообщения Брайля отправляются слишком быстро.Из-за использования брайлевских сообщений во многих программах чтения с экрана (если не во всех), если два сообщения отправляются одно за другим, они поступают почти одновременно, не давая пользователю времени прочитать первое сообщение до появления второго (если они вообще заметили первое сообщение).
В Толке есть функция Tolk_IsSpeaking(), которая возвращает истину, если программа чтения с экрана говорит, и ложь, если нет, ИЛИ, если программа чтения с экрана не реализует такую функцию.
И это главная проблема: у большинства программ чтения с экрана есть буфер, в который передается текст для речи.Если утверждающее сообщение поступает, буфер просто сбрасывается перед добавлением нового сообщения.Это означает, что большинство программ чтения с экрана не знают, разговаривают ли они (включая NVDA и JAWS, которые являются моей основной целевой аудиторией), поэтому для них IsTalking всегда оценивается как ложное.
Следовательно,проверка, говорит ли программа чтения с экрана, ожидание его остановки и последующая отправка следующих сообщений.
Другое решение, о котором я подумал, - это задержка между двумя сообщениями, которую пользователь может настроить по мере необходимости.Программа чтения с экрана будет говорить нормально, в то время как только сообщения Брайля задерживаются.Реализация этого в основном потоке - плохая идея, так как это заблокирует поток.Однако я не понял, как использовать другой поток для этой задачи.
Основной поток должен был бы начать и отправить сообщение Брайля, а затем поспать некоторое время.
Основной поток должен был бы проверить, завершается ли другой поток (без блокировки!), А затем отправить следующее сообщение.
Если у кого-то есть идея, как реализовать вышеупомянутое решение, или имеется другое решение, ядействительно оценил бы это.