Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Следующее изображение показывает полную структуру платформы и ее клиентов. Части, обрисованные в общих чертах полужирным, интегрируются с входной платформой метода как часть Java 2 платформы; другие могут быть разработаны и распределены отдельно независимыми поставщиками программного обеспечения.
Входной клиентский API метода определяет классы и интерфейсы, которые компоненты редактирования текста могут использовать, чтобы реализовать интегрированный текстовый входной пользовательский интерфейс. Текстовые компоненты AWT TextArea и TextField обеспечивают на месте или!P сверхопределяют состав, в зависимости от реализации. Текстовые компоненты инструментария пользовательского интерфейса Swing обеспечивают интегрированный текстовый входной пользовательский интерфейс. Управление контекстом управляет каналами связи между компонентами редактирования текста и входными методами. Входной SPI механизма метода определяет интерфейсы, которые позволяют входным механизмам метода и адаптерам быть включенными в платформу. Входные механизмы метода могут быть реализованы непосредственно в языке программирования Java, используя эти интерфейсы. Чтобы использовать собственные входные методы, интегрированные с входным менеджером по методу узла, адаптер преобразовывает информацию между моделями данных, используемыми собственными входными методами и входной платформой метода, и обеспечивает окно состава. Адаптеры для других входных систем, таких как Речь Java или Входной Протокол Метода Интернет-интранет (IIIMP), могут также быть реализованы, используя этот интерфейс.
Каждый экземпляр класса Component является потенциально клиентом входной платформы метода. Платформа различает четыре вида компонентов:
Все четыре вида компонентов могут сосуществовать в том же самом окне. Входная платформа метода, поэтому, должна определить возможности компонентов и скорректировать ее поведение, поскольку фокус перемещается от одного компонента до другого.
Клиентские компоненты не ответственны за рисование списков кандидатов или за элементы пользовательского интерфейса, которые управляют входным поведением метода. В зависимости от платформы эта ответственность лежит на входных методах, входном менеджере по методу узла, или входной платформе метода.
Входные методы не касаются различий между клиентскими компонентами. Они взаимодействуют с ними косвенно через входную платформу метода, которая представляет интерфейс, подобный активному клиенту, и обрабатывает различия внутренне.
Входная платформа метода поддерживает три входных стиля:
Платформа выбирает между вводом ниже пятна и на месте для активных клиентов, основанных на системном свойстве или свойстве AWT "java.awt.im.style". Системное свойство может быть определено из командной строки (конечным пользователем), свойство AWT в локализованном awt.properties файле (localizer или системным администратором). Если оба определяются, системное свойство имеет приоритет. Если значение свойства "ниже пятна", ниже пятна вводится, используется, иначе ввод на месте.
Поддержка ввода ниже пятна с собственными входными методами является зависимой платформой. В Java Sun 2 среды выполнения это поддерживается на Windows, но не на Солярисе. Где это не поддерживается, ввод на месте используется вместо этого.
Входной стиль, используемый для текстовых компонентов, с которыми взаимодействуют (экземпляры класса TextComponent), является зависящим от реализации и, возможно, не ни один из стилей, описанных выше. В Java Sun 2 среды выполнения для Windows ввод ниже пятна может быть выбран как описано выше, иначе!P сверхопределить ввод, используется, где составленный текст оттягивается в отдельном окне, покрывающем точку вставки. В Java Sun 2 среды выполнения для Соляриса входной стиль зависит от входного метода.
Никакой входной стиль не связывается с неклиентами.
Входные методы не касаются различий между входными стилями. Они взаимодействуют с клиентскими компонентами косвенно через входную платформу метода, которая представляет интерфейс, принимающий ввод на месте, и обрабатывает различия внутренне.
Входной SPI механизма метода включает разработке входных методов в языке программирования Java. Адаптеры для других входных систем, таких как Речь Java или Входной Протокол Метода Интернет-интранет, могут также быть реализованы, используя этот интерфейс. Для получения информации определенный для SPI, см. спецификацию пакета SPI.
SPI также используется для входных адаптеров метода узла, которые соединяются с собственными входными методами, интегрированными с входными менеджерами по методу узла, такими как Входной менеджер по Методу на Microsoft Windows, текстовый менеджер по Службам на МАКОСЕ, и XIM на Солярисе. Входной адаптер метода узла играет роль входного метода в пределах входной платформы метода, и преобразовывает события и запросы между моделями данных, используемыми AWT и входной платформой метода на одной стороне и входном менеджере по методу узла с другой стороны. Это также сотрудничает с входным контекстом в управлении окном состава - для пассивных клиентов, взаимодействующих входные методы узла, обычно корневое окно, обеспеченное входным менеджером по методу узла, используется. Адаптер передает запросы на определенные входные методы к узлу, но пользователи могут также использовать механизм выбора узла, чтобы выбрать входные методы.
Экземпляры InputContext управляют коммуникационными контекстами между клиентскими компонентами и вводят методы. Основная задача входного контекста состоит в том, чтобы поддержать соединение от текущего клиентского компонента до его текущего входного метода. Это диспетчеризирует входные события, такие как ключевые события и события от нажатия мыши от компонента до текущего входного метода, и входные события метода от входного метода до клиентского компонента. Это также диспетчеризирует запросы на информацию от входного метода до клиентского компонента.
Каждый экземпляр InputContext обеспечивает свою собственную текстовую входную среду, отдельную от всех других входных контекстов. Это позволяет приложениям поддерживать многократные параллельные входные операции. Например, в середине ввода текста в документ, пользователь может открыть диалоговое окно файла и ввести имя файла, не влияя на состояние состава текста, вводимого в документ.
По умолчанию один экземпляр InputContext создается на экземпляр Окна, и этот входной контекст совместно используется всеми компонентами в пределах иерархии включения окна. В случае необходимости компоненты могут создать частные входные контексты. Компонент, у которого нет его собственного входного контекста, использует тот, используемый его родителем. У входного контекста есть самое большее один текущий клиентский компонент, компонент, у которого в настоящий момент есть фокус. Переключаясь на новый клиентский компонент, входной контекст вызывает свой метод endComposition, чтобы фиксировать или отменить составленный текст для предыдущего клиентского компонента.
Входной контекст создает входной экземпляр метода для каждого входного механизма метода, который должны использовать его клиентские компоненты. Отдельные входные экземпляры метода создаются для каждого входного экземпляра контекста. Экземпляры сохраняются, пока входной контекст не располагается, так, чтобы экземпляры могли хранить информацию о тексте, который вводился в окно.
Входной контекст также обрабатывает входной выбор метода и окно состава.
У входного контекста есть текущий входной метод и текущая локаль.
Входная платформа метода обеспечивает два отдельных способа выбрать входные методы и входные локали:
Платформа не дает предпочтение выборам, сделанным так или иначе, таким образом, последний успешный выбор, сделанный так или иначе для входного контекста, определяет текущий входной метод для входного контекста (отметьте, что selectInputMethod может перестать работать, если никакой доступный входной метод не поддерживает требуемую локаль).
Прежде, чем переключиться на новый входной метод, входной контекст вызывает старый входной метод endComposition метода. Входной контекст сохраняет старый входной экземпляр метода и снова использует его, когда тот же самый входной метод выбирается снова для этого входного контекста позже.
InputContext.selectInputMethod ищет входной метод, поддерживающий указанную локаль, используя результаты методов InputMethodDescriptor.getAvailableLocales всех установленных входных методов. Если пользователь ранее выбрал входной метод с указанной локалью от пользовательского интерфейса, этот входной метод выбирается. Иначе это является зависящим от реализации, которые вводят метод, выбирается, если многократные входные методы поддерживают указанную локаль.
Пользовательский интерфейс для того, чтобы выбрать входные методы является зависящим от реализации. Это должно предоставить пользователю список всех доступных входных методов и позволить ему/ее выбирать одного из них. Где входной метод поддерживает многократные локали, пользовательский интерфейс также позволяет пользователю выбирать входную локаль (это средство может быть опущено для хост-адаптеров, если узел предоставляет альтернативную услугу, чтобы выбрать входную локаль). Лица, имеющие патент, разрабатывающие среды выполнения Java для их собственных платформ, поощряются интегрировать пользовательский интерфейс с существующими пользовательскими интерфейсами для того, чтобы выбрать клавиатуры или ввести методы.
В Java Sun 2 среды выполнения для Windows и Соляриса (с Основанным на мотиве AWT), пользовательский интерфейс состоит из трех частей: пункт меню "Select Input Method", добавленный к меню Window в Мотиве или Системному меню в Windows, определяемом пользователем входном ключе выбора метода, и раскрывающемся меню, переведенном в рабочее состояние или пунктом меню "Select Input Method" или входным ключом выбора метода. "Избранный Входной элемент" Метода только показывают, если среда выполнения Java имеет больше чем один входной метод в наличии, или входной метод поддерживает многократные локали (входной адаптер метода узла обрабатывается как единственный входной метод). Раскрывающееся меню перечисляет доступные входные методы, с поддерживаемыми локалями входных методов мультилокали как подменю, и позволяет пользователю выбирать из этого списка. Java Sun 2 среды выполнения для Соляриса (с X-based AWT) и Linux не обеспечивает пункт меню "Select Input Method", то есть. Всплывающее меню только переводится в рабочее состояние, нажимая входную клавишу выбора метода. Входное ключевое определение выбора метода, постоянно сохранено используя два предпочтения, одно определение основного значения кода ключа и другое определение модификаторов. Предпочтение "модификаторов" является дополнительным. Если запись модификаторов определяется, не соответствуя keyCode запись, что запись модификаторов игнорируется. Следующая таблица показывает содержание.
|
манипулируйте имя (Строка) |
значение (интервал) |
|---|---|
| "keyCode" | любой java.awt.event. KeyEvent. VK_* оценивают кроме VK_UNDEFINED |
| "модификаторы" |
любая комбинация java.awt.event. InputEvent. * _ МАСКА |
Java 2 времени выполнения ищут это предпочтение сначала в привилегированном узле дерева пользователя/java/awt/im/selectionKey, тогда, если никакое определение не могло бы быть найдено в системном привилегированном узле с тем же самым путем.
Для пассивных клиентов и для активных клиентов, использующих ввод ниже пятна, входная платформа метода обеспечивает окно состава. Окно открывается, когда входной метод начинает отправлять составленный текст; это закрывается, когда весь текст фиксируется. Самое большее одно окно состава открыто в любое время, даже если многократные составы (использующий отдельные входные контексты) в настоящий момент происходят.
Для ввода ниже пятна окно автоматически располагается только ниже точки вставки, где текст будет вставлен, фиксируясь. Расположение окна вычисляется сначала, когда окно открывается, затем обновляется всякий раз, когда фиксировавший текст был диспетчеризирован клиентскому компоненту. Если расположение окна ниже точки вставки переместило бы это частично или полностью вне экрана, это перемещается выше точки вставки.
Платформа обеспечивает два механизма, чтобы передать информацию между текущим клиентским компонентом и текущим входным методом:
И событие диспетчеризирующие и вызывающие методы InputMethodRequests делается косвенно через входной контекст. Это позволяет входному контексту перенаправлять информацию к окну состава в случае необходимости. Окно состава обеспечивает полную реализацию активного клиента, и таким образом, входной метод может всегда предполагать, что это взаимодействует с активным клиентом.
Следующие разделы показывают поток событий через входную платформу метода и объясняют связанную обработку входных запросов метода. Четыре альтернативы описываются, в зависимости от вида клиентского компонента и выбранного входного стиля. Все схемы принимают входной метод, реализованный в языке программирования Java, используя входной SPI механизма метода. Потоки события для текстовых компонентов, с которыми взаимодействуют, или собственных входных методов являются зависящими от реализации, могут измениться существенно, и не показываются.
Входные события, такие как KeyEvent и MouseEvent отправляются текущему входному методу через объект InputContext. Если входной метод использует событие для текстового состава, это отмечает использованное событие и генерирует входное событие метода к компоненту. Клиентский компонент, должно быть, зарегистрировал InputMethodListener, таким образом, он может обработать InputMethodEvent s прибывающий из входного метода и получить составленный и фиксировавший текст.
Вызовы InputMethodRequests от входного метода переводятся к объекту, возвращенному методом getInputMethodRequests клиентского компонента.
Входные события, такие как KeyEvent и MouseEvent отправляются текущему входному методу через объект InputContext. Если входной метод использует событие для текстового состава, это отмечает использованное событие и генерирует входное событие метода. Так как ввод ниже пятна выбирается, событие перенаправляется к окну состава, которое обрабатывает это. Когда текст фиксируется (частично или полностью), окно состава генерирует новое входное событие метода, содержащее фиксировавший текст для клиентского компонента. Клиентский компонент, должно быть, зарегистрировал InputMethodListener, таким образом, он может обработать InputMethodEvent s, которые в этом случае прибывают из окна состава и только содержат фиксировавший текст.
InputMethodRequests вызывает от входного метода, которые касаются дисплея составленного текста (getTextLocation, getLocationOffset) обрабатываются окном состава; все другие передаются объекту, возвращенному методом getInputMethodRequests клиентского компонента. Окно состава использует реализацию getTextLocation клиентского компонента, чтобы расположить себя.
Входные события, такие как KeyEvent и MouseEvent отправляются текущему входному методу через объект InputContext. Если входной метод использует событие для текстового состава, это отмечает использованное событие и генерирует входное событие метода. Событие перенаправляется к окну состава, которое обрабатывает его. Когда текст фиксируется, окно состава преобразовывает его в ключевые события для слушателя ключевого события фактического клиента. Только события KEY_TYPED отправляются.
Вызовы InputMethodRequests от входного метода обрабатываются окном состава. Шляпа вызовов касается дисплея составленного текста (getTextLocation, getLocationOffset) обрабатываются основанные на информации о составленном выводимом на экран тексте. Все другие вызовы обрабатываются всегда базируемые при условии, что состав только что запустился и нет никакого фиксировавшего текста, потому что у окна состава нет доступа к тексту в клиентском компоненте.
События для неклиентов не идут во входной контекст. Все события идут прямо к слушателям компонента (сюда, ключевому слушателю).
