В этом выпуске AWT был повторно реализован на платформах Linux и Солярисе. Возможно вызвать инструментарий Мотива на Linux или XAWT на Солярисе. Это делается любой, устанавливая AWT_TOOLKIT переменная или использование -Dawt.toolkit параметр командной строки. Значение для XAWT sun.awt.X11.XToolkit и значение для Мотива sun.awt.motif.MToolkit. Для получения дополнительной информации см. XToolkit на ноте Соляриса/Linux.
Поддержка XDnD
С этого выпуска поддержка была реализована как часть системы передачи данных. До этого выпуска только Мотив протокол DnD поддерживался на X11.
Получение расположения мыши на рабочем столе
API был добавлен, чтобы получить расположение мыши на рабочем столе. Новый класс PointerInfo описывает координаты указателя и связанное GraphicsDevice возразите в настоящее время PointerInfo экземпляр создается. PointerInfo имеет следующие методы:
Окно, Фрейм или Диалоговое окно Поверх остальных окон
Новый API был добавлен, чтобы гарантировать что деталь Window, Frame или Dialog имеет поверх остальных окон рабочий стол. Это полезно, реализовывая определенные элементы GUI, такие как панели инструментов, уведомление или информационные апплеты, и другие улучшающие рабочий стол функции. Новый и измененный API включает:
В зависимости от системной установки поверх остальных окон не могут поддерживаться Windows, Фреймы или Диалоговые окна. Они поддерживаются на Microsoft Windows, Linux и Солярисе, выполняющем GNOME2/Metacity, так же как Linux, выполняющий KDE/kwin. Они не поддерживаются на Солярисе, выполняющем CDE/dtwm. Возможно, что поверх остальных окон окна не работают над Linux или Солярисом рабочий сеанс и менеджеры окон кроме упомянутых выше.
Новый API, чтобы Определить Расположение Окна По умолчанию Платформой
Два новых метода и одно новое свойство позволяют пользователю определять расположение по умолчанию для нового Window, приспособьте платформе. Это особенно важно для X11. Новый api включает:
Отметьте что locationByPlatform свойство должно быть установлено в истину для базового менеджера окон разместить окно рядом согласно своей собственной логике. Иначе, AWT не будет знать, было ли окно помещено в 0,0 преднамеренно или было только неуказанным, и окно будет помещено в верхний левый угол экрана.
4101435: Window/Dialog/Frame.setLocation не всегда работает как ожидалось
Расположение и размер Windows, Диалоговых окон и Фреймов, находятся под контролем системы управления окнами рабочего стола, не приложением или инструментарием. Менеджер окон свободен проигнорировать или изменить запрос размещения окна. Поэтому, вызывая Window.setLocation (x, y), невозможно положиться на Окно, перемещаемое в расположение (x, y). Та же самая ситуация существует для Window.setSize и Window.setBounds. Документация Окна была разъяснена, чтобы объяснить это.
Новая _JAVA_AWT_WM_STATIC_GRAVITY Переменная окружения
Определенная позиция менеджеров окон окна AWT неправильно. Например, окно, которое требуют быть перемещенным в (0,0) под некоторыми менеджерами окон, будет расположено так, чтобы заголовок окна и уехал, граница являются внеэкранными. Это - то, потому что есть две школы менеджеров окон, которые не соглашаются на интерпретации спецификации ICCCM для запросов ConfigureRequest, что программы X11 делают, чтобы расположить их окна.
Решать эту проблему, _JAVA_AWT_VM_STATIC_GRAVITY переменная окружения была добавлена так, чтобы продвинутый пользователь мог указать, что его менеджер окон реализует поведение StaticGravity.
Это также исправляет ошибку : DropTargetListener не может получить доступ к передаваемому в dragOver и dragEnter.
Уведомление об изменениях содержания Буфера обмена теперь поддерживается
Ранее, API буфера обмена Java не позволял эффективному способу отследить изменения к набору DataFlavors, доступного на буфере обмена или уведомить заинтересованные стороны о тех изменениях. API был добавлен с этой целью:
Использование памяти Больше Не Поднимает использование Clipboard.getContents
До этого выпуска, Clipboard.getContents выбранные данные буфера обмена всего обеспеченный форматы, для которых существует отображение на соответствующую разновидность данных в карте разновидности по умолчанию. Если было много форматов, и данные были большими, много памяти было поглощенно выбранными данными в различных форматах. Благодаря новым методам, начатым с исправления ошибки , была решена эта проблема.
Новый API, чтобы Глобально Изменить Порог Движения Жеста DnD
Перетащить порог жеста движения представляет число пикселей, курсор перетаскивается прежде, чем система передачи данных инициирует перетащить работу. До этого выпуска это было трудно кодировано к 5 пикселям. С выпуска 5.0 есть поддержка собирания настольных свойств для, перетаскивают чувствительность и отображение этого к порогу, и новому API, который позволяет пользователям получать и изменять этот порог. Новый API включает:
Проблема Удобства пользования DnD для Перетаскивания текста
До этого выпуска горячая точка значков отбрасывания, используемых на X платформах, была расположена в середину значка. Перетаскивая текст, текстовый курсор перемещается, чтобы указать на текущее расположение отбрасывания, но это было obscurbed значком отбрасывания непосредственно. Для этого выпуска курсоры отбрасывания, используемые на X платформах, были изменены, чтобы указать на верхний левый угол значка отбрасывания. Соответствующие горячие точки были изменены соответственно.
Разъяснение в спецификации для нескольких java.awt.dnd. Методы DropTarget
Документ был разъяснен относительно передачи в нулевом параметре для следующего java.awt.dnd.DropTarget методы:
Методы SystemFlavorMap, Теперь Непротиворечивые с Документацией
SystemFlavorMap класс используется, чтобы сохранить отображения между собственными форматами и разновидностями данных Java, чтобы поддерживать передачу данных между приложениями Java и собственным. Документация для SystemFlavorMap.getNativesForFlavor (DataFlavor) метод была разъяснена, чтобы сказать это a DataFlavor (или собственный формат), известен, если и только если у него есть по крайней мере одно статическое отображение, связанное с этим.
Разъяснение документации для Перетаскивает Исходных Конструкторов Конструкторов Событий
Документация была разъяснена относительно передачи в недопустимых параметрах для следующих конструкторов, перетаскивают исходные события:
GridBagLayout: Несколько bugfixes были реализованы для GridBagLayout. Отметьте, что две из этих перечисленных ошибок применяются к документации только. Старшие значащие bugfixes включают:
Больше чем 512 горизонтальных или вертикальных составляющих теперь возможны в GridBagLayout
Ранее, GridBagLayout был реализован с трудно кодированным пределом ширины и высоты 512. Это теперь выделяется динамически, и константа MAXGRIDSIZE больше не используется.
Документация была добавлена, чтобы разъяснить то, что происходит, когда указанный Компонент не находится в расположении сумки сетки.
Документ для GridBagLayout.gridwidth/gridheight разъясняется
Спецификация класса для GridBagLayout.gridwidth/gridheight сбивала с толку в ее описании ОСТАТКА и РОДСТВЕННИКА. Это было исправлено.
FlowLayout Bugfixes
FlowLayout: Несколько ошибок документации были исправлены для FlowLayout
Спецификация FlowLayout исправляется относительно выравнивания
Ранее, спецификация класса, утвержденная, что компоненты центрируются на строке. Фактически, align свойство определяет, как компоненты размечаются. Документ был исправлен.
Спецификация класса FlowLayout больше не подразумевает, что компоненты всегда слева направо
Спецификация класса FlowLayout была записана прежде, чем возможность пойти справа налево была добавлена. Поэтому это предполагало, что слева направо была единственная возможная ориентация. Документ был исправлен.
Исправленная спецификация для конструктора FlowLayout
Ранее, документ для конструктора FlowLayout забыл упоминать, что hgap и vap были применены к интервалу между компонентами и контейнерной границей так же как между компонентами. Документация была исправлена.
Новые методы, чтобы получить ограничения для дочерних элементов в BorderLayout
Три открытых метода были добавлены к BorderLayout, один, чтобы получить ограничения для компонента, и два различных способа получить компонент для данного ограничения (каждый принимает во внимание компонентную ориентацию и другой, не делает). Новые методы:
Разъясненная спецификация для GridLayout.layoutContainer относительно vgap и hgap params
Ранее, спецификация для layoutContainer, утвержденного, что vgap и hgap были добавлены между каждой ячейкой и между первой/последней ячейкой и границей. В действительности разрывы применяются между компонентами только. Это было исправлено в документе.
Разъясните спецификацию Списка относительно поведения щелчка по выбранному пункту
Ранее, спецификация класса для Списка, утвержденного, что щелчок по отменявшему элементу выбирает это и щелчок по выбранному пункту, отменяет выбор его. Это - истина, только если список находится в режиме множественного выбора. В единственном режиме выбора любой щелкает по элементу списка, выбирает элемент, по которому щелкают. Спецификация была разъяснена.
Разъясненная спецификация для метода ContainerEvent.getContainer
Метод ContainerEvent.getContainer принимает это source имеет тип Container. Ранее, это casted источник, чтобы ввести Container без первой проверки, которая могла привести к ClassCastException. Метод был изменен, чтобы возвратить значение нуля, если источник не является a Container.
Новый KeyEvent кодирует для двух стандартных ключей Microsoft Windows.
Два включает стандартную клавиатуру Microsoft Windows, не имеют Java keycodes â ключ окон и ключ контекстного меню. Это препятствует возможности удовлетворить 508 требований. Поэтому, java.awt.event.KeyEvent.VK_WINDOWS и java.awt.event.KeyEvent.VK_CONTEXT_MENU keycodes были добавлены.
4829063: Полоса прокрутки теперь определяет, что ползунок Полосы прокрутки, возможно, не видим
Ранее, документ для Scrollbar.getVisibleAmount и setVisibleAmount не говорил, что иногда ползунок не мог бы быть видимым или точно описать то, для чего используется диапазон полосы прокрутки. Спецификация была очищена. Это - изменение только для документа.
Поведение KeyEvent.getKeyChar разъясняется
Использование KeyEvent.getKeyChar объясняется в документации класса KeyEvent, но документ для самого метода был краток. Документ для getKeyChar был улучшен для этого выпуска.
Разъясните спецификацию, которые ВХОДЯТ, не увольняет ActionEvent
Есть беспорядок среди некоторых разработчиков это, когда фокус находится на a Button, нажатие клавиши ENTER не стреляет ActionEvent. Это - корректное поведение. КЛАВИША "ПРОБЕЛ" стреляет ActionEvent. Спецификация класса ActionEvent была обновлена, чтобы разъяснить этот факт.
Новые конструкторы FileDialog
Три новый FileDialog конструкторы были добавлены, который может определить a Dialog как владелец:
Обновленная спецификация для Robot.createScreenCapture
Ранее, документация для Robot.createScreenCapture не упоминала, что курсор мыши не включается в полученное изображение. Это было всегда верно для Соляриса, Linux, Windows и Mac OS X. Документация была обновлена, чтобы отразить эту информацию.
Разъясните InputEvent. ALT_MASK/BUTTON2_MASK и документ META_MASK/BUTTON3_MASK
Есть перекрытие в значениях для некоторых из констант InputEvent. Это сбивает с толку потому что, вызывая KeyEvent.getModifiersExText (интервал) и MouseEvent.getMouseEventModifiersText (интервал) строка, возвращенная для KeyEvent. BUTTON2_MASK является "Высокий звук" и строка, возвращенная для KeyEvent. BUTTON3_MASK является "Мета". Для этого выпуска документация была добавлена к InputEvent, KeyEvent и классам MouseEvent, чтобы разъяснить это.
Вот список известных проблем, с которыми можно встретиться в выпуске 5.0.
Метагородское управление версиями
Мы рекомендуем использовать последнюю сборку Метагорода (который является в настоящий момент 2.6.2). Были некоторые ошибки, которые произошли с версиями до 2.4.34 (проблемы с программируемым iconification, и фреймы неизменяемого размера, например), которые были с тех пор фиксированы.
Несовместимость фокуса апплета
Мы получили отчеты, у которого, в некоторых апплетах, нажимая клавишу на клавиатуре нет ожидаемого результата. Это обычно происходит, потому что апплет не получает фокус автоматически, когда нет никаких дочерних компонентов в апплете. Чтобы гарантировать, что такой апплет работает через все платформы, рекомендуется, чтобы Вы запросили фокус при запуске (через requestFocus) и при щелчке мышью. Если Вы не хотите фокус, вызвать setFocusable(false).
JVM может отказать, когда JOptionPane вызывается от отбрасывания ()
На Solaris/Linus рабочий MToolKit, выводя на экран a JOptionpane от drop метод может заставить JVM отказывать. Эта ошибка будет адресоваться в будущем выпуске.
Ошибки фокуса, когда рабочие апплеты
Были связанные с фокусом ошибки, примечательные когда рабочие апплеты в Mozilla в выпуске 1.4.2 и ранее. Это включает:
Фокус ввода, не работающий с многократными апплетами
Символы текстового поля не могут удалить, делая тест Плагина Java
Неспособный ввести текст в JTextField в 1.4.1_02
requestFocus метод не приносит фокус к компоненту на Netscape 7 на Солярисе
Ничего не может ввести к SpreadSheet
Не может ввести charact, чтобы войти в систему AnswerCenter с апплетом Java
Клавиша Tab не может работать, делая прецедент Java
Чтобы решить эту проблему, клиентская сторона протокола XEmbed была реализована:
4849238: Добавьте поддержку XEmbed AWT
4907325: XEmbed должен быть реализован для инструментария Мотива
Однако, браузер должен поддерживать серверную сторону XEmbed для этого, чтобы работать. Мы рекомендуем использовать следующие браузеры с Java:
На Linux, выпуск сообщества Mozilla, по крайней мере, версия 1.5 или выше.
На Солярисе, Mozilla Sun, по крайней мере, версия 1.4 или выше.
