Movatterモバイル変換


[0]ホーム

URL:


Skip toContent

AWT Enhancements in the Java 2 Platform Standard Edition 5.0

Major Changes
Window Bugfixes and Enhancements
DnD and Data Transfer Bugfixes andEnhancements
Layout Bugfixes
Miscellaneous Bugfixes
Known Bugs and Issues

Major Changes

4615479: XToolkit on Solaris and Linux

In this release, AWT has been reimplemented on theSolaris and Linux platforms. It is possible to force the Motiftoolkit on Linux or XAWT on Solaris. This is done either by settingtheAWT_TOOLKIT variable or using the-Dawt.toolkit command line parameter. The value forXAWT issun.awt.X11.XToolkit and the value for Motifissun.awt.motif.MToolkit. For more information, seetheXToolkit on Solaris/Linuxnote.

4638443: XDnD Support

As of this release, theXDnD Protocol supporthas been implemented as part of the data transfer system. Prior tothis release, only the Motif DnD protocol was supported onX11.

4009555: Obtaining the mouse location on thedesktop

API has been added to obtain the mouse location on thedesktop. The newPointerInfo classdescribes the pointer coordinates and the associatedGraphicsDevice object at the moment thePointerInfo instance is created.PointerInfo has the following methods:

The newMouseInfo class hasinformation about the current location of the mouse pointer.MouseInfo has two methods:

Other new methods:

java.awt.Component.getMousePosition()
java.awt.Container.getMousePosition(boolean)
java.awt.Toolkit.getMouseInfoPeer

Window Bugfixes andEnhancements

4632143: Window, Frame or Dialog Always on Top

New API has been added to ensure that a particularWindow,Frame orDialog isalways on top of the desktop. This is useful when implementingcertain GUI elements, such as tool boxes, notification orinformation applets, and other desktop-enhancing features. The newand modified API includes:

Depending on the system setup, always-on-top Windows, Frames orDialogs may not be supported. They are supported on MicrosoftWindows, Linux and Solaris running GNOME2/Metacity, as well asLinux running KDE/kwin. They are not supported on Solaris runningCDE/dtwm. It is possible that always-on-top windows do not work onLinux or Solaris running session and window managers other thanthose mentioned above.

4102292: New API to Specify Default Window Location byPlatform

Two new methods and one new property allow the user tospecify the default location for a newWindow,appropriate to the platform. This is especially important for X11.The new api includes:Note that thelocationByPlatform property must be setto true for the underlying window manager to tile the windowaccording to its own logic. Otherwise, AWT won't know whether thewindow was put at 0,0 intentionally or was just unspecified and thewindow will be placed at the upper-left-hand corner of thescreen.

4101435: Window/Dialog/Frame.setLocation doesn't alwayswork as expected

The location and size of Windows, Dialogs and Frames,is under the control of the desktop's window management system, notthe application or the toolkit. The window manager is free toignore or modify a window placement request. Therefore, whencalling Window.setLocation(x, y), you can't rely on the Windowbeing moved to location (x, y). The same situation exists forWindow.setSize and Window.setBounds. The Window documentation hasbeen clarified to explain this.

4401846: New _JAVA_AWT_WM_STATIC_GRAVITY EnvironmentVariable

Certain window managers position AWT windowsincorrectly. For example, a window that is requested to be moved to(0,0) will, under some window managers, be positioned so that thewindow's title and left border are off-screen. This is becausethere are two schools of window managers that disagree on theinterpretation of the ICCCM specification for the ConfigureRequestrequests that X11 programs make to position their windows.

To address this issue, the_JAVA_AWT_VM_STATIC_GRAVITY environment variable hasbeen added so that a power user can indicate that his windowmanager implements the StaticGravity behavior.

DnD and Data Transfer Bugfixes andEnhancements

4378091: New DropTarget.getTransferable method

The newjava.awt.dnd.DropTargetDragEvent.getTransferable method enablesthe drop target to access transfer data during a drag operation.

This also fixes bug4248542: DropTargetListener can't access thetransferable in dragOver and dragEnter.

4259272: Notification of Clipboard contents changes isnow supported

Previously, the Java clipboard API didn't allow anefficient way to track changes to the set of DataFlavors availableon the clipboard or notify interested parties about those changes.API has been added for this purpose:

4287795: New methods for querying information in aClipboard

Three new methods have been added:

4790833: Memory Usage No Longer Shoots Up usingClipboard.getContents

Prior to this release,Clipboard.getContents fetched clipboard data in allprovided formats for which a mapping to the corresponding dataflavor in the default flavor map exists. If there were a lot offormats and the data were large, a lot of memory was consumed withthe fetched data in different formats. Thanks to the new methodsintroduced with bug fix4287795, this problem has been fixed.

4415175: New API to Globally Change the DnD GestureMotion Threshold

The drag motion gesture threshold represents the numberof pixels the cursor is dragged before the data transfer systeminitiates a drag operation. Prior to this release, this washard-coded to 5 pixels. As of release 5.0, there is support forpicking up the desktop properties for drag sensitivity and mappingit to the threshold, and new API that allows users to get andchange this threshold. The new API includes:

4712068: DnD Usability Issue for Dragging Text

Prior to this release, the hotspot of the drop iconsused on X platforms was located at the middle of the icon. Whendragging text, the text cursor moves to indicate the current droplocation, but this was obscurbed by the drop icon itself. For thisrelease, the drop cursors used on X platforms have been changed topoint to the upper-left corner of the drop icon. The correspondinghotspots have been changed accordingly.

4191708: Clarification in spec for severaljava.awt.dnd.DropTarget methods

The doc has been clarified with respect to passing in anull parameter for the followingjava.awt.dnd.DropTarget methods:

4819437: DragSourceListener.dragExit is now called in aconsistent way

The class specification for theDragSourceAdapterandDragSourceAdapterclasses, and the documentation for theDragSourceAdapter.dragExit andDragSourceListener.dragExit methods have been updated toclarify the notion that the drop site is associated with theprevious call todragEnter.

4654688: SystemFlavorMap Methods Now Consistent withDocumentation

TheSystemFlavorMap class is used to storemappings between native formats and Java data flavors in order tosupport data transfer between native and Java applications. Thedocumentation for theSystemFlavorMap.getNativesForFlavor(DataFlavor) method has beenclarified to say that aDataFlavor (or a nativeformat) is known if and only if it has at least one static mappingassociated with it.

4123385: Documentation Clarification for Drag SourceEvents Constructors Constructors

The documentation has been clarified with respect topassing in invalid parameters for the following constructors ofdrag source events:

Layout Bugfixes

GridBagLayout Bugfixes

GridBagLayout: Several bugfixes have beenimplemented for GridBagLayout. Note that two of these bugs listedapply to the documentation only. The most significant bugfixesinclude:

4254022: More than 512 horizontal or vertical componentsare now possible in a GridBagLayout

Previously, GridBagLayout had been implemented with ahard-coded width and height limit of 512. This is now allocateddynamically and the MAXGRIDSIZE constant is no longerused.

4532201: GridBagLayout.lookupConstraints doc isclarified

Documentation was added to clarify what happens whenthe specified Component is not in the grid bag layout.

4618355: Doc for GridBagLayout.gridwidth/gridheight isclarified

The class spec for GridBagLayout.gridwidth/gridheightwas confusing in its description of REMAINDER and RELATIVE. Thishas been corrected.

FlowLayout Bugfixes

FlowLayout: Several documentation bugs have beenfixed for FlowLayout

4586806: FlowLayout spec is corrected regardingalignment

Previously, the class spec stated that components arecentered on the line. Actually, thealign propertydetermines how the components are laid out. The doc has beencorrected.

4881919: FlowLayout class spec no longer implies thatcomponents are always left to right

The FlowLayout class spec was written before theability to go right to left was added. Therefore it assumed thatleft to right was the only possible orientation. The doc has beencorrected.

4587456: Corrected spec for FlowLayout constructor

Previously, the doc for the FlowLayout constructorneglected to mention that the hgap and vap were applied to thespacing between the components and the container border as well asbetween the components. The documentation has beencorrected.

4172932: New methods to get constraints for children inBorderLayout

Three public methods have been added toBorderLayout, one to get the constraints for acomponent, and two different ways to get the component for a givenconstraint (one takes component orientation into account and theother doesn't). The new methods are:

4515041: Clarified spec for GridLayout.layoutContainerregarding vgap and hgap params

Previously, the spec for layoutContainer stated thatthe vgap and hgap was added between each cell and between thefirst/last cell and the border. In reality, the gaps are appliedbetween the components only. This has been corrected in thedoc.

Miscellaneous Bugfixes

4533021: New API to Change the Z-ordering ofChildren

New API has been added to specify the z-ordering ofchildren in aContainer. The two newContainer methods include:

4370733: AWTKeyStroke.getAWTKeyStroke(String) andtoString are now symmetric

Previously it was not possible to take the output fromAWTKeyStroke.toString and pass it to thegetAWTKeyStroke method. This has been changed so themethods

4341785: Clarify spec for several List methods

The spec for the followingList methodshas been clarified to state that unspecified behavior results whenthe range is out of bounds:

4368570: Clarify List spec regarding behavior ofclicking on a selected item

Previously, the class spec for List stated thatclicking on an unselected item selects it and clicking on aselected item de-selects it. This is true only if the list is inmultiple-selection mode. In single-selection mode, any click on alist's item selects the clicked item. The spec has beenclarified.

4082708: Clarified spec for theContainerEvent.getContainer method

TheContainerEvent.getContainer method assumes thatsource is of typeContainer. Previously,it casted the source to typeContainer without firstchecking which could result in ClassCastException. The method hasbeen changed to return a value of null if the source isn't aContainer.

4620715: New KeyEvent codes for two standard MicrosoftWindows keys.

Two keys on a standard Microsoft Windows keyboard don'thave Java keycodes — the windows key and the context menu key. Thisimpedes the ability to meet 508 requirements. Therefore, thejava.awt.event.KeyEvent.VK_WINDOWS andjava.awt.event.KeyEvent.VK_CONTEXT_MENU keycodes havebeen added.

4829063: Scrollbar now specifies that Scrollbar thumbmay not be visible

Previously, the doc for Scrollbar.getVisibleAmount andsetVisibleAmount did not say that sometimes the thumb might not bevisible or accurately describe what the scrollbar's range is usedfor. The specification has been cleaned up. This is a doc-onlychange.

4840172: Behavior of KeyEvent.getKeyChar isclarified

Use of KeyEvent.getKeyChar is explained in the KeyEventclass documentation, but the doc for the method itself was brief.The doc for getKeyChar has been improved for thisrelease.

4233061: Clarify spec that ENTER doesn't fire anActionEvent

There is confusion among some developers that when thefocus is on aButton, pressing the ENTER key doesn'tfire anActionEvent. This is correct behavior. TheSPACE bar fires anActionEvent. TheActionEventclass specification was updated to clarify this fact.

4221123: New FileDialog constructors

Three newFileDialog constructors havebeen added that can specify aDialog as the owner:

4691481: Updated spec for Robot.createScreenCapture

Previously, the documentation forRobot.createScreenCapture didn't mention that the mouse cursor isnot included in the captured image. This has always been true ofSolaris, Linux, Windows and Mac OS X. The documentation has beenupdated to reflect this information.

4704042: New method for setting Insets

A single method to set Insets has been added:set(int, int, int, int).

4492739: Clarify InputEvent.ALT_MASK/BUTTON2_MASK andMETA_MASK/BUTTON3_MASK doc

There is an overlap in the values for some of theInputEvent constants. This is confusing because when callingKeyEvent.getModifiersExText(int) andMouseEvent.getMouseEventModifiersText(int) the string returned forKeyEvent.BUTTON2_MASK is "Alt" and the string returned forKeyEvent.BUTTON3_MASK is "Meta". For this release, documentationwas added to the InputEvent, KeyEvent and MouseEvent classes toclarify this.

Known Bugs andIssues

Here is a list of known problems you may encounter inrelease 5.0.

Metacity versioning

We recommend using the latest build of Metacity (whichis currently 2.6.2). There were some bugs that occurred withversions prior to 2.4.34 (problems with programmatic iconification,and non-resizable frames, for example) that have since beenfixed.

5051557: Applet focus incompatibility

We have received reports that, in some applets,pressing a key on the keyboard doesn't have the expected result.This usually happens because the applet doesn't get the focusautomatically when there are no child components in the applet. Toensure that such an applet works across all platforms, it isrecommended that you request the focus at startup (viarequestFocus) and on mouse press. If you don't wantthe focus, callsetFocusable(false).

5050387: JVM may crash when JOptionPane is invoked fromdrop()

On Solaris/Linus running MToolKit, displaying aJOptionpane from thedrop method maycause the JVM to crash. This bug will be addressed in a futurerelease.

Focus bugs when running applets

There were focus-related bugs noticeable when runningapplets in Mozilla in release 1.4.2 and earlier. This includes:To solve this problem, the client side of the XEmbed protocol wasimplemented:However, the browser should support the server side of XEmbed inorder for it to work. We recommend using the following browserswith Java:

Copyright © 1993, 2020, Oracleand/or its affiliates. All rights reserved.
Contact Us

[8]ページ先頭

©2009-2025 Movatter.jp