From b3c1eef2a77b9f68a37a905bf29f28f0e6ab9a32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E7=A7=A6=E8=8B=B1=E6=9D=B0?= <327782001@qq.com>
Date: Mon, 3 Apr 2023 14:54:39 +0800
Subject: [PATCH] =?UTF-8?q?fix:=E6=B7=BB=E5=8A=A0=E9=87=8D=E5=86=99?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
out/production/classes1/.idea/.gitignore | 8 +
.../classes1/.idea/easyCodeTableSetting.xml | 661 ++++++++
.../inspectionProfiles/Project_Default.xml | 38 +
out/production/classes1/.idea/misc.xml | 6 +
out/production/classes1/.idea/modules.xml | 8 +
out/production/classes1/.idea/vcs.xml | 6 +
out/production/classes1/READEME.md | 0
out/production/classes1/applet/package.html | 60 +
.../classes1/awt/color/package.html | 55 +
.../classes1/awt/datatransfer/package.html | 64 +
out/production/classes1/awt/dnd/package.html | 146 ++
.../classes1/awt/dnd/peer/package.html | 51 +
.../awt/doc-files/AWTThreadIssues.html | 193 +++
.../classes1/awt/doc-files/BorderLayout-1.gif | Bin 0 -> 2716 bytes
.../classes1/awt/doc-files/Button-1.gif | Bin 0 -> 1920 bytes
.../classes1/awt/doc-files/Checkbox-1.gif | Bin 0 -> 2375 bytes
.../awt/doc-files/CheckboxGroup-1.gif | Bin 0 -> 712 bytes
.../classes1/awt/doc-files/Choice-1.gif | Bin 0 -> 486 bytes
.../awt/doc-files/DesktopProperties.html | 277 +++
.../classes1/awt/doc-files/FlowLayout-1.gif | Bin 0 -> 1918 bytes
.../classes1/awt/doc-files/FocusCycle.gif | Bin 0 -> 6933 bytes
.../classes1/awt/doc-files/FocusSpec.html | 1367 +++++++++++++++
.../classes1/awt/doc-files/FontMetrics-1.gif | Bin 0 -> 290 bytes
.../awt/doc-files/GridBagLayout-1.gif | Bin 0 -> 2608 bytes
.../awt/doc-files/GridBagLayout-2.gif | Bin 0 -> 2592 bytes
.../awt/doc-files/GridBagLayout-baseline.png | Bin 0 -> 722 bytes
.../classes1/awt/doc-files/GridLayout-1.gif | Bin 0 -> 1764 bytes
.../classes1/awt/doc-files/GridLayout-2.gif | Bin 0 -> 1776 bytes
.../awt/doc-files/ImplicitFocusTransfer.gif | Bin 0 -> 5151 bytes
.../classes1/awt/doc-files/Label-1.gif | Bin 0 -> 819 bytes
.../awt/doc-files/LinearGradientPaint.png | Bin 0 -> 3347 bytes
.../classes1/awt/doc-files/List-1.gif | Bin 0 -> 4193 bytes
.../classes1/awt/doc-files/MenuBar-1.gif | Bin 0 -> 2268 bytes
.../classes1/awt/doc-files/Modality.html | 471 ++++++
.../classes1/awt/doc-files/MultiScreen.gif | Bin 0 -> 3131 bytes
.../awt/doc-files/RadialGradientPaint-1.png | Bin 0 -> 21911 bytes
.../awt/doc-files/RadialGradientPaint-2.png | Bin 0 -> 25468 bytes
.../awt/doc-files/RadialGradientPaint-3.png | Bin 0 -> 14389 bytes
.../awt/doc-files/RadialGradientPaint-4.png | Bin 0 -> 9784 bytes
.../classes1/awt/doc-files/Scrollbar-1.gif | Bin 0 -> 968 bytes
.../classes1/awt/doc-files/Scrollbar-2.gif | Bin 0 -> 1938 bytes
.../classes1/awt/doc-files/TextArea-1.gif | Bin 0 -> 2234 bytes
.../classes1/awt/doc-files/TextField-1.gif | Bin 0 -> 2522 bytes
.../classes1/awt/doc-files/modal-example1.gif | Bin 0 -> 2175 bytes
.../classes1/awt/doc-files/modal-example2.gif | Bin 0 -> 2353 bytes
.../classes1/awt/doc-files/modal-example3.gif | Bin 0 -> 2822 bytes
.../classes1/awt/doc-files/modal-example4.gif | Bin 0 -> 2868 bytes
.../classes1/awt/event/package.html | 58 +
out/production/classes1/awt/font/package.html | 53 +
out/production/classes1/awt/geom/package.html | 63 +
out/production/classes1/awt/im/package.html | 69 +
.../classes1/awt/im/spi/package.html | 126 ++
.../classes1/awt/image/package.html | 58 +
.../awt/image/renderable/package.html | 52 +
out/production/classes1/awt/package.html | 83 +
out/production/classes1/awt/peer/package.html | 51 +
.../classes1/awt/print/package.html | 58 +
.../classes1/beans/beancontext/package.html | 55 +
out/production/classes1/beans/package.html | 156 ++
out/production/classes1/classes.iml | 11 +
out/production/classes1/classes1.iml | 11 +
out/production/classes1/io/package.html | 52 +
.../classes1/lang/doc-files/ValueBased.html | 42 +
.../classes1/lang/doc-files/capchi.gif | Bin 0 -> 144 bytes
.../classes1/lang/doc-files/capiota.gif | Bin 0 -> 111 bytes
.../classes1/lang/doc-files/capsigma.gif | Bin 0 -> 131 bytes
.../classes1/lang/doc-files/captheta.gif | Bin 0 -> 153 bytes
.../classes1/lang/doc-files/capupsil.gif | Bin 0 -> 140 bytes
.../classes1/lang/doc-files/chi.gif | Bin 0 -> 145 bytes
.../classes1/lang/doc-files/iota.gif | Bin 0 -> 112 bytes
.../lang/doc-files/javalang.doc.anc21.gif | Bin 0 -> 206 bytes
.../lang/doc-files/javalang.doc.anc38.gif | Bin 0 -> 220 bytes
.../lang/doc-files/javalang.doc.anc40.gif | Bin 0 -> 187 bytes
.../lang/doc-files/javalang.doc.anc41.gif | Bin 0 -> 191 bytes
.../classes1/lang/doc-files/sigma1.gif | Bin 0 -> 135 bytes
.../classes1/lang/doc-files/theta.gif | Bin 0 -> 144 bytes
.../classes1/lang/doc-files/upsilon.gif | Bin 0 -> 133 bytes
.../classes1/lang/instrument/package.html | 281 +++
.../classes1/lang/management/package.html | 248 +++
out/production/classes1/lang/ref/package.html | 147 ++
.../net/doc-files/net-properties.html | 242 +++
.../nio/ByteBufferAs-X-Buffer.java.template | 225 +++
.../nio/Direct-X-Buffer-bin.java.template | 124 ++
.../nio/Direct-X-Buffer.java.template | 490 ++++++
.../classes1/nio/Heap-X-Buffer.java.template | 601 +++++++
.../classes1/nio/X-Buffer-bin.java.template | 132 ++
.../classes1/nio/X-Buffer.java.template | 1503 +++++++++++++++++
.../classes1/nio/channels/exceptions | 194 +++
.../classes1/nio/channels/spi/package.html | 45 +
.../nio/charset/Charset-X-Coder.java.template | 996 +++++++++++
.../classes1/nio/charset/exceptions | 53 +
.../classes1/nio/charset/package.html | 88 +
.../classes1/nio/charset/spi/package.html | 45 +
out/production/classes1/nio/exceptions | 60 +
out/production/classes1/nio/package.html | 139 ++
.../classes1/rmi/activation/package.html | 61 +
out/production/classes1/rmi/dgc/package.html | 55 +
out/production/classes1/rmi/package.html | 59 +
.../classes1/rmi/registry/package.html | 57 +
.../classes1/rmi/server/package.html | 74 +
out/production/classes1/sql/package.html | 340 ++++
out/production/classes1/text/package.html | 65 +
out/production/classes1/text/spi/package.html | 50 +
out/production/classes1/time/overview.html | 169 ++
.../classes1/util/CurrencyData.properties | 598 +++++++
out/production/classes1/util/jar/package.html | 63 +
.../classes1/util/logging/package.html | 134 ++
out/production/classes1/util/package.html | 55 +
.../classes1/util/prefs/package.html | 44 +
.../classes1/util/regex/package.html | 66 +
out/production/classes1/util/spi/package.html | 50 +
out/production/classes1/util/zip/package.html | 98 ++
util/HashMap.java | 931 +++++-----
113 files changed, 12586 insertions(+), 405 deletions(-)
create mode 100644 out/production/classes1/.idea/.gitignore
create mode 100644 out/production/classes1/.idea/easyCodeTableSetting.xml
create mode 100644 out/production/classes1/.idea/inspectionProfiles/Project_Default.xml
create mode 100644 out/production/classes1/.idea/misc.xml
create mode 100644 out/production/classes1/.idea/modules.xml
create mode 100644 out/production/classes1/.idea/vcs.xml
create mode 100644 out/production/classes1/READEME.md
create mode 100644 out/production/classes1/applet/package.html
create mode 100644 out/production/classes1/awt/color/package.html
create mode 100644 out/production/classes1/awt/datatransfer/package.html
create mode 100644 out/production/classes1/awt/dnd/package.html
create mode 100644 out/production/classes1/awt/dnd/peer/package.html
create mode 100644 out/production/classes1/awt/doc-files/AWTThreadIssues.html
create mode 100644 out/production/classes1/awt/doc-files/BorderLayout-1.gif
create mode 100644 out/production/classes1/awt/doc-files/Button-1.gif
create mode 100644 out/production/classes1/awt/doc-files/Checkbox-1.gif
create mode 100644 out/production/classes1/awt/doc-files/CheckboxGroup-1.gif
create mode 100644 out/production/classes1/awt/doc-files/Choice-1.gif
create mode 100644 out/production/classes1/awt/doc-files/DesktopProperties.html
create mode 100644 out/production/classes1/awt/doc-files/FlowLayout-1.gif
create mode 100644 out/production/classes1/awt/doc-files/FocusCycle.gif
create mode 100644 out/production/classes1/awt/doc-files/FocusSpec.html
create mode 100644 out/production/classes1/awt/doc-files/FontMetrics-1.gif
create mode 100644 out/production/classes1/awt/doc-files/GridBagLayout-1.gif
create mode 100644 out/production/classes1/awt/doc-files/GridBagLayout-2.gif
create mode 100644 out/production/classes1/awt/doc-files/GridBagLayout-baseline.png
create mode 100644 out/production/classes1/awt/doc-files/GridLayout-1.gif
create mode 100644 out/production/classes1/awt/doc-files/GridLayout-2.gif
create mode 100644 out/production/classes1/awt/doc-files/ImplicitFocusTransfer.gif
create mode 100644 out/production/classes1/awt/doc-files/Label-1.gif
create mode 100644 out/production/classes1/awt/doc-files/LinearGradientPaint.png
create mode 100644 out/production/classes1/awt/doc-files/List-1.gif
create mode 100644 out/production/classes1/awt/doc-files/MenuBar-1.gif
create mode 100644 out/production/classes1/awt/doc-files/Modality.html
create mode 100644 out/production/classes1/awt/doc-files/MultiScreen.gif
create mode 100644 out/production/classes1/awt/doc-files/RadialGradientPaint-1.png
create mode 100644 out/production/classes1/awt/doc-files/RadialGradientPaint-2.png
create mode 100644 out/production/classes1/awt/doc-files/RadialGradientPaint-3.png
create mode 100644 out/production/classes1/awt/doc-files/RadialGradientPaint-4.png
create mode 100644 out/production/classes1/awt/doc-files/Scrollbar-1.gif
create mode 100644 out/production/classes1/awt/doc-files/Scrollbar-2.gif
create mode 100644 out/production/classes1/awt/doc-files/TextArea-1.gif
create mode 100644 out/production/classes1/awt/doc-files/TextField-1.gif
create mode 100644 out/production/classes1/awt/doc-files/modal-example1.gif
create mode 100644 out/production/classes1/awt/doc-files/modal-example2.gif
create mode 100644 out/production/classes1/awt/doc-files/modal-example3.gif
create mode 100644 out/production/classes1/awt/doc-files/modal-example4.gif
create mode 100644 out/production/classes1/awt/event/package.html
create mode 100644 out/production/classes1/awt/font/package.html
create mode 100644 out/production/classes1/awt/geom/package.html
create mode 100644 out/production/classes1/awt/im/package.html
create mode 100644 out/production/classes1/awt/im/spi/package.html
create mode 100644 out/production/classes1/awt/image/package.html
create mode 100644 out/production/classes1/awt/image/renderable/package.html
create mode 100644 out/production/classes1/awt/package.html
create mode 100644 out/production/classes1/awt/peer/package.html
create mode 100644 out/production/classes1/awt/print/package.html
create mode 100644 out/production/classes1/beans/beancontext/package.html
create mode 100644 out/production/classes1/beans/package.html
create mode 100644 out/production/classes1/classes.iml
create mode 100644 out/production/classes1/classes1.iml
create mode 100644 out/production/classes1/io/package.html
create mode 100644 out/production/classes1/lang/doc-files/ValueBased.html
create mode 100644 out/production/classes1/lang/doc-files/capchi.gif
create mode 100644 out/production/classes1/lang/doc-files/capiota.gif
create mode 100644 out/production/classes1/lang/doc-files/capsigma.gif
create mode 100644 out/production/classes1/lang/doc-files/captheta.gif
create mode 100644 out/production/classes1/lang/doc-files/capupsil.gif
create mode 100644 out/production/classes1/lang/doc-files/chi.gif
create mode 100644 out/production/classes1/lang/doc-files/iota.gif
create mode 100644 out/production/classes1/lang/doc-files/javalang.doc.anc21.gif
create mode 100644 out/production/classes1/lang/doc-files/javalang.doc.anc38.gif
create mode 100644 out/production/classes1/lang/doc-files/javalang.doc.anc40.gif
create mode 100644 out/production/classes1/lang/doc-files/javalang.doc.anc41.gif
create mode 100644 out/production/classes1/lang/doc-files/sigma1.gif
create mode 100644 out/production/classes1/lang/doc-files/theta.gif
create mode 100644 out/production/classes1/lang/doc-files/upsilon.gif
create mode 100644 out/production/classes1/lang/instrument/package.html
create mode 100644 out/production/classes1/lang/management/package.html
create mode 100644 out/production/classes1/lang/ref/package.html
create mode 100644 out/production/classes1/net/doc-files/net-properties.html
create mode 100644 out/production/classes1/nio/ByteBufferAs-X-Buffer.java.template
create mode 100644 out/production/classes1/nio/Direct-X-Buffer-bin.java.template
create mode 100644 out/production/classes1/nio/Direct-X-Buffer.java.template
create mode 100644 out/production/classes1/nio/Heap-X-Buffer.java.template
create mode 100644 out/production/classes1/nio/X-Buffer-bin.java.template
create mode 100644 out/production/classes1/nio/X-Buffer.java.template
create mode 100644 out/production/classes1/nio/channels/exceptions
create mode 100644 out/production/classes1/nio/channels/spi/package.html
create mode 100644 out/production/classes1/nio/charset/Charset-X-Coder.java.template
create mode 100644 out/production/classes1/nio/charset/exceptions
create mode 100644 out/production/classes1/nio/charset/package.html
create mode 100644 out/production/classes1/nio/charset/spi/package.html
create mode 100644 out/production/classes1/nio/exceptions
create mode 100644 out/production/classes1/nio/package.html
create mode 100644 out/production/classes1/rmi/activation/package.html
create mode 100644 out/production/classes1/rmi/dgc/package.html
create mode 100644 out/production/classes1/rmi/package.html
create mode 100644 out/production/classes1/rmi/registry/package.html
create mode 100644 out/production/classes1/rmi/server/package.html
create mode 100644 out/production/classes1/sql/package.html
create mode 100644 out/production/classes1/text/package.html
create mode 100644 out/production/classes1/text/spi/package.html
create mode 100644 out/production/classes1/time/overview.html
create mode 100644 out/production/classes1/util/CurrencyData.properties
create mode 100644 out/production/classes1/util/jar/package.html
create mode 100644 out/production/classes1/util/logging/package.html
create mode 100644 out/production/classes1/util/package.html
create mode 100644 out/production/classes1/util/prefs/package.html
create mode 100644 out/production/classes1/util/regex/package.html
create mode 100644 out/production/classes1/util/spi/package.html
create mode 100644 out/production/classes1/util/zip/package.html
diff --git a/out/production/classes1/.idea/.gitignore b/out/production/classes1/.idea/.gitignore
new file mode 100644
index 0000000..73f69e0
--- /dev/null
+++ b/out/production/classes1/.idea/.gitignore
@@ -0,0 +1,8 @@
+# Default ignored files
+/shelf/
+/workspace.xml
+# Datasource local storage ignored files
+/dataSources/
+/dataSources.local.xml
+# Editor-based HTTP Client requests
+/httpRequests/
diff --git a/out/production/classes1/.idea/easyCodeTableSetting.xml b/out/production/classes1/.idea/easyCodeTableSetting.xml
new file mode 100644
index 0000000..a374cc5
--- /dev/null
+++ b/out/production/classes1/.idea/easyCodeTableSetting.xml
@@ -0,0 +1,661 @@
+
+
+The applet framework involves two +entities: the applet and the applet context. An applet is an +embeddable window (see the Panel class) with a few extra methods that the applet +context can use to initialize, start, and stop the applet. +
+The applet context is an application that is responsible for loading and running +applets. For example, the applet context could be a Web browser or an applet +development environment. +
+ + +@since JDK1.0 + + diff --git a/out/production/classes1/awt/color/package.html b/out/production/classes1/awt/color/package.html new file mode 100644 index 0000000..41fa95a --- /dev/null +++ b/out/production/classes1/awt/color/package.html @@ -0,0 +1,55 @@ + + + + +
+It also provides a clipboard mechanism, which is an object that +temporarily holds a transferable object that can be transferred +between or within an application. The clipboard is typically used +for copy and paste operations. Although it is possible to create +a clipboard to use within an application, most applications will +use the system clipboard to ensure the data can be transferred +across applications running on the platform. + + + +@since JDK1.1 + + diff --git a/out/production/classes1/awt/dnd/package.html b/out/production/classes1/awt/dnd/package.html new file mode 100644 index 0000000..4673485 --- /dev/null +++ b/out/production/classes1/awt/dnd/package.html @@ -0,0 +1,146 @@ + + + + +
+This package defines the classes and interfaces necessary to perform Drag +and Drop operations in Java. It +defines classes for the drag-source and the drop-target, as well as +events for transferring the data being dragged. This package also provides +a means for giving visual feedback to the user throughout the +duration of the Drag and Drop operation. +
+A typical Drag and Drop operation can be decomposed into the following +states (not entirely sequentially): +
DragSource
comes into existence,
+associated with some presentation
+element (Component
) in the GUI, to initiate a Drag and Drop of
+some potentially Transferable
data.
+DropTarget
(s) come into/go out of
+existence, associated
+with presentation elements in the GUI (Components), potentially
+capable of consuming Transferable
data types.
+DragGestureRecognizer
is
+obtained from the DragSource
and is
+associated with a Component
in order
+to track and identify any Drag
+initiating gesture by the user over the Component
.
+Component
,
+which the registered
+DragGestureRecognizer
detects, and notifies its
+DragGestureListener
of.
+
+Note: Although this API consistently refers to the stimulus for a
+drag and drop operation being a physical gesture by a human user, this
+does not preclude a programmatically driven DnD operation given the
+appropriate implementation of a DragSource
. This package
+contains the abstract class MouseDragGestureRecognizer
for
+recognizing mouse device gestures. Other abstract subclasses may be
+provided by the platform to support other input devices or
+particular Component
class semantics.
+
+
DragGestureListener
causes the
+DragSource
to initiate the Drag
+and Drop operation on behalf of the user, perhaps animating the
+GUI Cursor and/or rendering an Image
of the item(s) that are the
+subject of the operation.
+Component
(s)
+in the GUI with
+associated DropTarget
(s), the DragSource
+receives notifications in order
+to provide "Drag Over" feedback effects, and the DropTarget
(s)
+receive notifications in order to provide "Drag Under" feedback effects
+based upon the operation(s) supported and the data type(s) involved.
+
+
+The gesture itself moves a logical cursor across the GUI hierarchy,
+intersecting the geometry of GUI Component(s), possibly resulting in
+the logical "Drag" cursor entering, crossing, and subsequently
+leaving Component
(s) and associated DropTarget
(s).
+
+The DragSource
object manifests "Drag Over" feedback to the user, in the typical case by animating the GUI Cursor
associated with the
+logical cursor.
+
+DropTarget
objects manifest "Drag Under" feedback to the user, in
+the typical case, by rendering animations into their associated GUI
+Component
(s) under the GUI Cursor.
+
+The determination of the feedback effects, and the ultimate success +or failure of the data transfer, should one occur, is parameterized +as follows: +
DragSource
and DropTarget
: Copy, Move or Reference(link).
+DragSource
and the set of data types comprehensible by the
+DropTarget
.
+DragSource
and DropTarget
+receive
+notifications that include, and result in the type negotiation and
+transfer of, the information associated with the DragSource
via a
+Transferable
object.
+main
method of some class.
+The virtual machine terminates all its activity and exits when
+one of two things happens:
+exit
method of class
+ Runtime
or class System
, and the exit
+ operation is permitted by the security manager.
+
+This implies that if an application doesn't start any threads itself,
+the JVM will exit as soon as main
terminates.
+This is not the case, however, for a simple application
+that creates and displays a java.awt.Frame
:
+
+ public static void main(String[] args) { + Frame frame = new Frame(); + frame.setVisible(true); + } ++The reason is that AWT encapsulates asynchronous event dispatch +machinery to process events AWT or Swing components can fire. The +exact behavior of this machinery is implementation-dependent. In +particular, it can start non-daemon helper threads for its internal +purposes. In fact, these are the threads that prevent the example +above from exiting. The only restrictions imposed on the behavior of +this machinery are as follows: +
EventQueue.isDispatchThread
+ returns true
if and only if the calling thread is the
+ event dispatch thread started by the machinery;
+ AWTEvents
which were actually enqueued to a
+ particular EventQueue
(note that events being
+ posted to the EventQueue
can be coalesced) are
+ dispatched:
+ AWTEvent
A is enqueued
+ to the EventQueue
before
+ AWTEvent
B then event B will not be
+ dispatched before event A.Component.isDisplayable
).
+exit
+ method of class Runtime
or class System
+ regardless of the presence of displayable components;
+ +Starting with 1.4, the behavior has changed as a result of the fix for + +4030718. With the current implementation, AWT terminates all its +helper threads allowing the application to exit cleanly when the +following three conditions are true: +
System.exit
must:
+Window.dispose
+ on all top-level Windows
. See
+Frame.getFrames
.
+ EventQueue
.
+ The argument is that methods
+ of AWT event listeners are typically executed on helper
+ threads.
++ <...> + Runnable r = new Runnable() { + public void run() { + Object o = new Object(); + try { + synchronized (o) { + o.wait(); + } + } catch (InterruptedException ie) { + } + } + }; + Thread t = new Thread(r); + t.setDaemon(false); + t.start(); + <...> ++ +The Java™ Virtual Machine Specification + guarantees +that the JVM doesn't exit until this thread terminates. + + diff --git a/out/production/classes1/awt/doc-files/BorderLayout-1.gif b/out/production/classes1/awt/doc-files/BorderLayout-1.gif new file mode 100644 index 0000000000000000000000000000000000000000..8a1a2bb670f2c5443fc1e0f5a1fa505b5ef93927 GIT binary patch literal 2716 zcmV;N3S;$0Nk%w1VQK*`0igf@0002Mz`+0i{{R30A^8LW00062EC2ui0BQj)0RRI2 zgpaAq?GK}zwAzca-n{z{hT=$;=82~2%C_zc$1)?-_KoNI&iDQg3<`(DqVb4KDwoXW zZ4rn{r_`$Tip^@b+^+Wv4vWX+viXcoOBw36`wfrF=k&Tg%D(IO{J#GWNR}5!SZH{N zn20r~*y#8O85zbXS!sER2}qgA+3EQywh1~)TG}aUnyR{Lh|2m38yn{;TWfpkMT@)3 zyQ|v^9K8B#1#osCoU9B-JY^8@To%n`ylj0<)x2grJ=U#NjV->c4V^6=zLh@C-dnz2 zt+0)py$(%(kI=r4`+lB}FF}=W0O#T3hwzm@XL$al>jv>*IC}{zrg|sO97Fz%cqBT5 z($JzvRTu?w4C!&($BZXOy8N_oO-Pw1BYs@;GAB%sUEp=p_miMal`|>oJgO)r$}2_- zuC#X$snn!AsX1i2C@RpEQ@c`SDGjUFv9QYFEJil%u&RQ@s(m}kEZn)i*wVdA&Mw}) zz~u7%YsxR+!8^ecK3rBW;>D!|Gk)yIG33dIBvZbuX@=&_oI88|3_7&v(WFb8K8-rH z>eV5fxPA>gw(QxoYumnUV*&2nynFlp4LrCK-NK6-KaM=PavzE@JCEG_x%A4>r(4f# z_`3E$mbd5f&a^ssG)=d62mFm7wTI&eipP8~qEC$`
xU$JSnTcS^dK6ejBzFtuEFtqG z-W<7*-!dq(}yw5rmpJhD!G36*OQuP)1l6^nH$h=}ko9x6t&X=G<&IVR%b$P` zeEZTv=5&hR!G2rXA&l6AVY^ptF^-h?aU#c(TScx6h%#nVmp6av?3wf5(3wG#mOA?M c=hUi22X5^;vFzEjYumn!JGbuLx(fgRJCauNM*si- literal 0 HcmV?d00001 diff --git a/out/production/classes1/awt/doc-files/DesktopProperties.html b/out/production/classes1/awt/doc-files/DesktopProperties.html new file mode 100644 index 0000000..0153a07 --- /dev/null +++ b/out/production/classes1/awt/doc-files/DesktopProperties.html @@ -0,0 +1,277 @@ + + + + + + + + + + AWT Desktop Properties
+ +The following refers to standard AWT desktop properties that +may be obtained via the + +Toolkit.getDesktopProperty
method. ++Each desktop property is named by a unique string, which +is the "name" of that property. +
+Desktop properties supported by the AWT but not documented +elsewhere - typically because there is no suitable +method or class - are documented here. +
+Desktop properties documented elsewhere are those which are +tightly coupled with a method or class which documents them. +
+Since desktop properties abstract an underlying platform +setting, they may not be available in environments that do +not support them. In the event that a desktop property is +unavailable for any reason, the implementation will return +
null
. ++The following table summarizes the desktop properties documented +here, and their value types. +
++
+ ++ +Property Name +Value Type +Summary Description ++ +awt.font.desktophints +java.util.Map +Font smoothing (text antialiasing) settings. ++ +sun.awt.enableExtraMouseButtons +java.lang.Boolean +Controls if mouse events from extra buttons are to be generated or not +Desktop Font Rendering Hints
+Desktop Property: "awt.font.desktophints" ++Modern desktops support various forms of text antialiasing (font smoothing). +
+These are applied by platform-specific heavyweight components. +However an application may want to render text using the same text +antialiasing on a drawing surface or lightweight (non-platform) component using +
Graphics2D
methods. +This is particularly important when creating + Swing components which +are required to appear consistent with native desktop components or other +Swing components. + +Basic Usage
+The standard desktop property named +"awt.font.desktophints" +can be used to obtain the rendering hints that best match the desktop settings. + +The return value is a + Map of +RenderingHints
which +can be directly applied to aGraphics2D
. ++It is a
Map
as more than one hint may be needed. +If non-null this can be directly applied to theGraphics2D
. +++Toolkit tk = Toolkit.getDefaultToolkit(); +Map map = (Map)(tk.getDesktopProperty("awt.font.desktophints")); +if (map != null) { + graphics2D.addRenderingHints(map); +} +
Advanced Usage Tips
+ +Listening for changes
++An application can listen for changes in the property +using a +
PropertyChangeListener
: ++Listening for changes is recommended as users can, on rare occasions, +reconfigure a desktop environment whilst applications are running +in a way that may affect the selection of these hints, and furthermore +many desktop environments support dynamic reconfiguration of these +running applications to conform to the new settings. ++tk.addPropertyChangeListener("awt.font.desktophints", pcl); +
+There is no direct way to discover if dynamic reconfiguration +is expected of running applications but the default assumption +should be that it is expected, since most modern desktop environments +do provide this capability. +
Text Measurement
++Text always needs to be measured using the same +
FontRenderContext
+as used for rendering. The text anti-aliasing hint is a component of +theFontRenderContext
. +AFontMetrics
+obtained from theGraphics
object on which the hint +has been set will measure text appropriately. +This is not a unique requirement for clients that specify this hint +directly, since the value of theFontRenderContext
should +never be assumed, so is discussed here principally as a reminder. +Saving and restoring Graphics State
++Sometimes an application may need to apply these hints on a shared +Graphics only temporarily, restoring the previous values after they +have been applied to text rendering operations. +The following sample code shows one way to do this. +
+ ++/** + * Get rendering hints from a Graphics instance. + * "hintsToSave" is a Map of RenderingHint key-values. + * For each hint key present in that map, the value of that + * hint is obtained from the Graphics and stored as the value + * for the key in savedHints. + */ +RenderingHints getRenderingHints(Graphics2D g2d, + RenderingHints hintsToSave, + RenderingHints savedHints) { + if (savedHints == null) { + savedHints = new RenderingHints(null); + } else { + savedHints.clear(); + } + if (hintsToSave.size() == 0) { + return savedHints; + } + /* RenderingHints.keySet() returns Set<Object> */ + for (Object o : hintsToSave.keySet()) { + RenderingHints.Key key = (RenderingHints.Key)o; + Object value = g2d.getRenderingHint(key); + savedHints.put(key, value); + } + return savedHints; +} + + +Toolkit tk = Toolkit.getDefaultToolkit(); +Map map = (Map)(tk.getDesktopProperty("awt.font.desktophints")); +Map oldHints; +if (map != null) { + oldHints = getRenderingHints(graphic2D, map, null); + graphics2D.addRenderingHints(map); + .. + graphics2D.addRenderingHints(oldHints); +} +
Details
++
+- The return value will always be null or a
Map
+
+- If the return value is null, then no desktop properties are available, +and dynamic updates will not be available. This is a typical behaviour if +the JDK does not recognise the desktop environment, or it is one which +has no such settings. The Headless toolkit is one such example. +Therefore it is important to test against null before using the map. +
+- If non-null the value will be a
Map
of +RenderingHints
such that every key is an instance of +RenderingHints.Key
and the value is a legal value for that key. +
+- The map may contain the default value for a hint. This is +needed in the event there is a previously a non-default value for the hint +set on the
Graphics2D
. If the map did not contain +the default value, thenaddRenderingHints(Map)
would leave +the previous hint which may not correspond to the desktop setting. ++An application can use
setRenderingHints(Map)
to reinitialise +all hints, but this would affect unrelated hints too. +
+- A multi-screen desktop may support per-screen device settings in which +case the returned value is for the default screen of the desktop. +An application may want to use the settings for the screen on +which they will be applied. +The per-screen device hints may be obtained by per-device property names +which are constructed as the String concatenation +
++"awt.font.desktophints" + "." + GraphicsDevice.getIDstring(); +
+An application can also listen for changes on these properties. +
+However this is an extremely unlikely configuration, so to help +ease of development, if only a single, desktop-wide setting is supported, +then querying each of these per-device settings will return null. +So to determine if there are per-device settings it is sufficient to +determine that there is a non-null return for any screen device using +the per-device property name. +
Mouse Functionality
+Desktop Property: "sun.awt.enableExtraMouseButtons" ++This property determines if events from extra mouse buttons (if they are exist and are +enabled by the underlying operating system) are allowed to be processed and posted into +{@code EventQueue}. +
+The value could be changed by passing "sun.awt.enableExtraMouseButtons" +property value into java before application starts. This could be done with the following command: ++java -Dsun.awt.enableExtraMouseButtons=false Application ++Once set on application startup, it is impossible to change this value after. +
+Current value could also be queried using getDesktopProperty("sun.awt.enableExtraMouseButtons") +method. +
+If the property is set to {@code true} then ++
+- it is still legal to create {@code MouseEvent} objects with +standard buttons and, if the mouse has more +then three buttons, it is also legal to use buttons from the range started +from 0 up to {@link java.awt.MouseInfo#getNumberOfButtons() getNumberOfButtons()}. + +
- it is legal to use standard button masks when using {@code Robot.mousePress()} +and {@code Robot.mouseRelease()} methods and, if the mouse has more then three buttons, +it is also legal to use masks for existing extended mouse buttons. +That way, if there are more then three buttons on the mouse then it is allowed to +use button masks corresponding to the buttons +in the range from 1 up to {@link java.awt.MouseInfo#getNumberOfButtons() getNumberOfButtons()} +
+If the property is set to {@code false} then ++
+ +This property should be used when there is no need in listening mouse events fired as a result of +activity with extra mouse button. +By default this property is set to {@code true}. + + diff --git a/out/production/classes1/awt/doc-files/FlowLayout-1.gif b/out/production/classes1/awt/doc-files/FlowLayout-1.gif new file mode 100644 index 0000000000000000000000000000000000000000..5f82d060fe9d60baa757ec1ad6f28b31e4548481 GIT binary patch literal 1918 zcmV-^2Z8uUNk%w1VYdP90HFW?0002Mz`+0i{{R30A^8LW00062EC2ui0Jj0|00091 zgpaAq?GK}zwAzca-n{z{hT=$;=82~2%C_zc$MQ_qb}Z!j&iDQg3<`(DqVb4KDwoWr z^9hYgr_lxVip^@b+^+Wv4kxXGfccD0tJmzd`wfrF=k&V$j?e4&{J#GWsMnAaSZH{N zn5ekO*y#8uH&_NqS!sERnW?!c$Uw*m8Y((UT3RY;nyR|W+Um-N`YJn1TWbp#d#k(4 z+dG@<8!S9b{0Ll(oUFVY={d;^9W7maJZ*iA&03w!-R*6;{VhID{ulmcuy;_--tK$u zmfi{AUT^>FY)2okpC=#J@1DScjo_*I$FI|zfCL*l#FcMhK!$Y?qI-xjqq_cx&Cu*q za0aADiU>j`(1- it is legal to create {@code MouseEvent} objects with standard buttons +only: {@code NOBUTTON}, {@code BUTTON1}, {@code BUTTON2} and +{@code BUTTON3} +
- it is legal to use standard button masks only: +{@code InputEvent.BUTTON1_DOWN_MASK}, {@code InputEvent.BUTTON2_DOWN_MASK}, +{@code InputEvent.BUTTON3_DOWN_MASK} +
8R9VR7O6z0>WFKNQ63fAh*l|T6{HCqyE&wgyfx^;II>QkvwyQ*!w^{w7- zaqTvxm{%#xbxQXd<~#Nd;HifjBTcODtK-R!$@E#gn6hSpeK&jF+xfF-u%Snr&RP1j zYLuy0yB2Htwd|^`XWMR9`?hXzxp(`{*88_`X~BmZS0?F(^5x8%JAV!xfPm=Kt6RU0 zJv)Nw+Pi!I4nDkx c&z9W-WvRdxswnJbM*=SF$5#wLhi{-af3 zBiY#oTP`uSqEE1xIpi9c4SJA8YIe1!Mp0@sWu#nfm6?{3nN=1^k_rmx8fQKlRiuO6 z>DHwgWm* Au4myz zten1nYG|raJ;`iJ$3B#-pny)=EQ!y`1+27bF~uvPnqsT&pxlz{ZJ#b;De7PG^hzt7 zoKhPUsgzpVFTBH+OK-Wf*^A_#0JCeWyN;rpt-ueLYVJi7|LZTPbGFK`ly1i8RbkG4 zESRdnGNx_Dcdo2(%xJX>@>x`ci}9vKdb+5n5>BgZ&S;Fh?o5OEOf!NZW9p`!1aDdA z( C&$@J&)9M6uULQL~{Mmw+`X#2hUp@Vm6Ib8*4SPSo`C(+7jcqHb!DMMD}HI zYmzqKb%)(HxNqapcb0q0UGus(53bnZK{}pEw|v_Ee3T9<6zCl0&m}JT)!d<=Idh>m z$NArQe-65-o2w38>0tK 0Ac^z4K0{`=g=FF*G5 z*H8WZ_(QM%{>=C9KjZ;0fW#Xh0fA@01M)6`3d9`)8%VncLJ)QmoFIQHXhHm7FoX2j zAP3>&!4I-0gd#)_2}?+x6Qa;KDqNv(TIfRGz%YionIR2rW5XNDCWkt74G(*$njZqu zG(sGrXo_e=&mb|0npq+fC*#B?HYSQvGz|U~tEiVNV$pS5ES?s-xUlVkv36e^qmkBU z#uTD4jVxRv8(-+gH_9-Ma;za8>xjcU;&F$1+@lZs=*J)eGLS?ZBq5Jz$U`bIk&0|0 zBO3|DM?!LnlANR!D{09rVltCl B%sjFO+i>BPn-N##4?Xm8wLHDO))kR>D#~ zpqypBUTMqK$TFAK*d;HCQ_Eih4wu42Br%J*$YUbYk;+_VB%A3>N xy5i*us$7V2DQE!yc$d}K48mGLG$Nkh(iVgsJ~)J8u0 zX`g=rG#dOIsOGrb1%vEV{Ms>6!HlhBeJo@1x~#%Z_FbRl>|j|2R- 1@qLj3iqptN*T0dR@PVHMipbbo7Hclv@_ZM)^{O`?sSn;-QG&~x;@<~cj-3L z?>5xC;*A`6%PZ2MqL-lOT`x+-1K;?{cfRzkuYK=}-~8%#zx?g5fBy^M01J4)DJTE{ EJ7XHfG5`Po literal 0 HcmV?d00001 diff --git a/out/production/classes1/awt/doc-files/FocusCycle.gif b/out/production/classes1/awt/doc-files/FocusCycle.gif new file mode 100644 index 0000000000000000000000000000000000000000..4777e217368b543b9594ef239dc441a48ce33f18 GIT binary patch literal 6933 zcmV+w8|vgoNk%v~VF3ba0rCI<000000Du4h{{a60+#vww=Kucy0RR90EC2ui009DO z0RRL3c)HyFFv>}*y*TU5yZ>M)j$~<`XsWJk>%MR-&vb3yc&_h!@BhG{a7Zi~kI1BQ z$!t2G(5Q4uty-_xtai)odcQM)cuX#v&jPS|&2F2>fw+85uiFD=w|>ue!|#BBfn|M# zhKEgmf^%qNi* OuFJ^+T zvb(%{w5n+~xOc0)#>ZZ%jJ7?kz{t?iQ@^0aLW;}5(%alc)XYiPsNmh@<~Y=NPnp^0 z?(etXQtWcp@b~y2%H&bX_5Aq)3Y_pwTa|SG3=Uk#FrC7K{>D9INb#M+F7zZ;-01#p z-xqP!IEvg>umpgUC{qH+0n*;cm$6EQNLiq!&6@>M-e@@yrcX&1KcK`(v}n$g!ZL#T z$rPwO4=0UEHHx$b&!$*?E$a| 4T~qN+%%xAuj+c7FWY(2kzjhdVwr>=jZQ~xU`!${3zmtbR%XK*J;=8vhpZ?}} zbLY>S@utpwd1T3-v9GplJYo0qrnX-f&l);Q_2}bwf-jss@gIYc%U2#8D*kQ)00wv; zehBHe-)sef5MF2jHt3vtIuvN&fsZjZ(|-*Lm|YP0QOI3~7qXV2hV2c(*n}Qt1)_o& zj!3|RCa##GY4ouuqKg0y7-Ks#YF49-tKpdAhD4m$qhmh;37U{3h6W)J5*|61j3O+! zq=O^s2-$HcN*Pd4CRmABmIY*}C1go@$x)h0Qf6jNWRAClk!p%WB?)34_9mPTmN;jA zUDiobZ7JlLSDa<`DQ6;43OZ1Kg$Ai8pOaGdq!F+=DiE6^7}^$-h+5iDqncVo=n9^G z1!|~>T^bH=ftET7r+6~B>Yk$3#igv>Fy}(5Ufqgos}Rx3D=c9C{(5DTI1O9b6&4EYw!(W~I%N+ZMO$82hau;fkxLx!J<|6}st4x9+T`#$YW` z+Q!T5xye{}Zzajju&;dpe^l_mg)A(?!3fW*2BZx0(XPP}pNWyf6|dou4iIMyRvUMA z490ghge)>n^g_$A$y}g(gUT!C`Hww$Tw_ z-YRsE>*06jE1YgH1)^{JWa)k!jyh_832wnqqjL*88x+rORpnsch5OGaVX!;zpZo5D z%t0J~fJ)GNwu|b@d%!&CX-}Vg^(SzCwGhq+y*>9MSlz(@=%=s#`qBpv?)cgPT5F@CLBQgMgPBfegE4D-)D&YQOMR<}G-6zGO4Xujxa{v}CCqVXb z5n1rlR17sRzaAvberF^_?~YYK5irn=8h~T-fS5#C`OuD2#3Kjvn7tA9u})Czp3}(q z0YZL{kAZVkA^~{FLWUrWahu*94>U RRe}d| zIuVTQsKd-=R`Qyb;u{EGP)(4jrFDrBXVtd(n{K9Vk)9!3YhD+Fa`Nne@;u5s*m)XW zzLS<*$){ULHv@al3 +8^n1=KhnZYMbIl2Or(qN_I zG3hPR=#z&o)r)tbsatYjRDDTRH0xmMNPHU8ZyxZfQ?;o9c?MRj?i8SA;c8c#IMTA} zQ>^I20aCF;RLY?hD^*>dOc#(-CsFmLM|CU9h^EV?0u~*2y`5mg3fKGvcCoE#DLi4K z*2{Pmp^# 6krwlqlet`8TpH5`Qk%A-tmGp!Io5O@ zH5MXTiCg2^cx#pluchp3V>1BQqUM*RsWNP0Pr}*F*z@y}jbvH(8VMzacC_0(ZWUKs z+lat+wiW$sZf`l*8&v{_buF(H+c=r8J$0UyP-`&1OU%orw!EE9Z+HcKWLmIxA=JHY zRj>Nr@TQcvnZ1PH797O~CvL*~O$k&Zmfh`Ub*nGz1l7vzzvVXfS@y~YhBtgd;^uVW zn!wrm8kpo5LHGV1Tz)rn$Gp)I9{7Z_%;=0GJZ3;OH5ho#V4eH-=AEYbzJ=Q&qaQuz zAnyayBjohx+E(gQ|FGASdqamyV(Z*BJJrWd>Y|2S&R%c($JKraw9maux^=Y_E}i$F z->}kJfBQPK9&+nep{jk4I@akP_@Pr;HOQ4aH3eVz+Dbm{O6P*z?;g+L))m~82Vvqj zdil|?c;}(lGvOC)`79vb^QP0e8aD5_)w3S5rFQ|}J)3*XkAn8J3-ahy?)uaZ|K7-B zJn9{PR=`VCu%BlF;*SrO-gDjdOHaM(mH+UoTA!SVrhZ}?Ci^b{|Hat9y;Q#sgWZFb z{l4$G_WqB+@n;Sd{@~X>0I0wJzNNnl=U02&7dqP}Hf@ks{D*(s<$P-pfWZe9e3f|p zr+~V5Yx_r1gTprew*?M}egjBB8O2)tH%@F|aw1q96qst6cLg1&g8hY1eKmr7Re}T; zgO@{o8>j^>sDhGVTEqb%DL72?7lA)WfPIh(D`*8fNMvOOg6DKJ`{yb_XiE$ih2f+- zIGBWoH-v*XfLarUzygN)(|}wUf*0sxQD{6zSbiK>hL}=+Bp6R%IEU?Hes(v9c*qqN z!-hKOhT9h#DL92E;BhJ-h%EqzG{}6qQe;zTh$XOu3KDxchy{@7f(Qjl#pj3B5<8Q~ z{(_pgCGF*ijyM8@h$ CP1K9I*oVRBN*}?8o_LIcArHh@jFh;G{4+7isD#pJiyw%Lhqwvc*o|ngJ`9*r z)YyqsP>B#=0O**G=$Ha?6h$P!jh_&YkDxvpu}8^Bj#E&H>bQ^mxQ@NVa=63+XCRLR zS&(r+k35n|Ta%5Nca0Cwj}Qrw|5%SokTe5nkQfOG-MBs)i9J}Sg;8*R5!sIqxsN7+ z2`+V11OXDR;EgVs2Lz!$2+@S%_>t-6kRxf55g?H>u>gQlkr2R=z;FgOKunqb5{tuD zjpewDIhl?az>|8&04D;Hxh0hmF_bP*T#na9HMw&57?PjZlm_4d5m|>;sgYU98A2%$ z;aHT1)s6?{l?-W&j&%WINdjf5hCw-#+3=FOa7BJe4xRuAk&pzq#g!_Va7vkv+IN>J zke94O0auxkZ0Q&AXqmZ?mY}DIB4tfk@QYq>W;q!HP kG!gU?w3$a$hg${sQrN-YYIL`sC>F{R5vqfMZs zOS(5IwE<7sqZD+4gD9k2dXiWwr6z@>RltuG8lo6@JlF{ZgCl_ 2E z8Q^kDtE~{XwsOlxW$OZNi?&lMa$C!`EYP>D3b$1oZ+Y~IK1*AM%OnS;w@=HrXG;M* z_j8Vmb1e|H$JMxji@05@xX^01cN@2PORbTcxszK)qWdZ4VsFT&0-8%-6&7)m=AAez zMtiGf?k1%@i;7M_xT*_zq1J5^N3<^xyS1{rS(>=F+W=onVahverjWZ=tB#u5yt+HQ z#G7*8CIi4rUeOC9b6bmbi)`UryPZJ2Gi$y6*NeRumvXM_W4HOeDZ6QP_PN;mnjA}D z=Zn4%u(&Xgy3CucM0dASVRh0qzwEoY_A6}oOTg3$z+yMM+-tR`Ij{J-z@+Gg?|Z=0 zc6CrI!1W8bF5-8#3&Ey~!NSYA@%y?GAi=1s!5iGX9jt60Jbo=J!YfR|EiAte>>WC5 zb9l?O7ks+@s>4ZpyEVMMm}>*{>tGaoxPn_oC>+5oE5xMhxf-OtA@IZl48?=?ZWS!E zHQ>dH6~&j^#8mvLDh$RfjKE*_!WWwaNKCO+tbPV;!^I22PF%-l+`s2Vxeh6vJFLBX zlfwI3#xjfo1P91)jDKdlvkiR6KV1GkXq?7G9K5pxn k8f0nDy+kDR7%((gd$jtjsZM=49nfr z&|)gmHDG}}OuG^71IXLThyG&GQ|v+Qd;x?!%rWi1@_Nk2o6^es$8mSA3q7=CjL{iw zJsU06=De3L?Y&Ihe)>0d30wrb?9eN{Q9E{J%8)lwIxB`25s#Y|m;P$5f47 zN=?>HYs{Q{t8d+(&RW-{D%O9U&XJeIRjm)@E7)N@(_6jNHm#KnE!gVWpoI;0_4>ex zt=Oy#YJ2_BdEK^=Jze^z)&Nl1mOa|% (imDht|u-NlzJ12vb~Pq5p_t;&6YK`{NRTMW|oS= 5fY%6ur* zErW!^?aj8$12reH{- y4-Q9{5-yF`@^}U^& zIoX~~QeME|0&d6J5#Np~;RJ302JV)DO{o~@ie0eYc)F`+{igsf-=kJKFihMeUgA}J zIcA!hT(H|o&f^}g0!0mje%iaVy^|F#1Pk^$OxmPcVBkPrgfq+`1tEM}-m_J1 l_~sKWhn1e*wEX0FO_NW!=?LW9W}E3kSE0^B>8j4@cY*1A zE)=Uy=@sbdmar?U73-}2+h=}`rhe*m8H5U6+r2J*bk2^XLVul2;jixN`6GzIzTkx3 zY_#6o$DTO5UZTtH>!P>?3vJ%T4pB3ynGZhXM81^Y9-Cbr?L&a*z8LOpxjdxK)x%Eg z=iVvluI`>z@7w6^ a?@fKe3;7$yje31-)o+6I~uHjDssoxxbTc1XMld14TjhbB2 z?;-xZ^6sbrPGwF7AM*ze@i9{KHvig6Ve%Ni=TiV7E)VqT?eL%c^VP ~kCv<{%h_H-R7~=MPUA!*>|=k=OT;ddNsut9+g-1X zCk*!oG >NR&D*8F(0H`0AGi>@GZ`LR@`SwHlWk35AQ2Q9g z`*;8PrBC&x-uA#x-pY@OXL|h5PxvU^{L4Sxjvt gX@-#%-`?+Xr4gyKk0_>=YX!D2mrU-{xCK}jl4MP z&Ab0#D2^mql^CD`MeDxBs$?^2-(nrDaPP+|+@)d>8jr}Na>+cLj=Y}~sB=`CSkiT& zntETsB{54bo6qRXSlIo3!;Niv{ AhKEXnijtF* zSdk-*j#EL2m1YW=nvZ)=o~Ea$AeSJaqMMzmO)Rdiup+Cmxw@vf9<#KXw!3V }AX3Dj!-osj)k!!H;z5d{(ru7vvEwd|aWDq+xI<*dg#bya zWCoIp$&o9$AbdGZBL;>sa}H~HKp;&R1tHG-Nf0Fkok(Nx97?o@O?FJ1I!%@`sntL& zqe=y{QtQ?hPbKiYN|s61ulQ7Y?LnYzTPbeeo MGtmf-$Yfpn?5mHkoo^%ctiaZpgW{*{UT!gAN_p zV(Au_*`~(a8Mf=+HaOlc@EAsM!w!e%HoiL>UEjc?--2$%m1DyGeUTef-du2Zg_)^K zAJ0L!_3z%Z^WF|@d3wmIrz0j$Up{Mb=hdUu@BHC#;^+a$Uw^&LSKoo}7>J)H?ol+F zF8|FYp=jYLh~R}oi06_h4JPzpE)hydn|9l1h#`U!-PYiQB+?V2h}YFt;C(07IDv^O ze#c^b{=5idfNxYtqm4GEm>+zmjksPvJ`#W(k_6gE m0iE>6q=aF^_Sm-7~wTY&o zeezhMm4TwDA$M-R>BWa2*4Zd?i(V>bq(mA?D3VHsX`BA0d~T@ Zm{ZsVA!Y z9Xicwtrm%6V?P3U>#2mMDytf-=DHb98vKXbj-CDrES8H}>TC$e8e8VB*uK3zJ%#6<(l-NX5o_cs<((r25-FJwtL~b^8(dXzD3Pw?}_;G3sy|&4zzBu z|0ZUhz%HCiTEXW8_2;+=O9!Y=Qc27v!v|Abv7i?-979qNOM@x9A6r#zvI0BYP07Y| zJZ8${t-Rp8F24+OFfz|fv&9$hoK4Q&2yLprKa1;eb>0&FjnP4VnzYhBPxO`3 yHBddd+v&bNdRr2Zwg>b`9=2@npn~yrjx6Uq NWv1D buy-L$VU + + + + + + The AWT Focus Subsystem + + + +The AWT Focus Subsystem
+ ++ Prior to Java 2 Standard Edition, JDK 1.4, the AWT focus subsystem + was inadequate. It suffered from major design and API problems, + as well as over a hundred open bugs. Many of these bugs were caused by + platform inconsistencies, or incompatibilities between the native + focus system for heavyweights and the Java focus system for + lightweights. +
+ The single worst problem with the AWT focus implementation was the + inability to query for the currently focused Component. Not only was + there no API for such a query, but also, because of an insufficient + architecture, such information was not even maintained by the code. +
+ Almost as bad was the inability of lightweight children of a Window + (not a Frame or a Dialog) to receive keyboard input. This problem + existed because Windows never received
WINDOW_ACTIVATED
+ events and thus could never be activated, and only active Windows + could contain focused Components. ++ In addition, many developers noted that the APIs for FocusEvent and + WindowEvent were insufficient because they did not provide a way for + determining the "opposite" Component involved in the focus or + activation change. For example, when a Component received a FOCUS_LOST + event, it had no way of knowing which Component was gaining + focus. Since Microsoft Windows provides this functionality for free, + developers migrating from Microsoft Windows C/C++ or Visual Basic to + Java had been frustrated by the omission. +
+ To address these and other deficiencies, we have designed a new focus + model for the AWT in JDK 1.4. The primary design changes were the + construction of a new centralized KeyboardFocusManager class, and a + lightweight focus architecture. The amount of focus-related, + platform-dependent code has been minimized and replaced by fully + pluggable and extensible public APIs in the AWT. While we have + attempted to remain backward compatible with the existing + implementation, we were forced to make minor incompatible changes in + order to reach an elegant and workable conclusion. We anticipate that + these incompatibilities will have only a trivial impact on existing + applications. +
+ This document is a formal specification both of the new APIs and of + existing APIs which remain relevant in the new model. Combined with + the javadoc for focus-related classes and methods, this document + should enable developers to create substantial AWT and Swing + applications with a focus behavior that is customized yet consistent + across platforms. This document has the following sections: +
+
+ + +- Overview of KeyboardFocusManager +
- KeyboardFocusManager and Browser Contexts +
- KeyEventDispatcher +
- FocusEvent and WindowEvent +
- Event Delivery +
- Opposite Components and Windows +
- Temporary FocusEvents +
- Focus Traversal +
- Focus Traversal Policy +
- Focus Traversal Policy Providers +
- Programmatic Traversal +
- Focusability +
- Focusable Windows +
- Requesting Focus +
- Focus and PropertyChangeListener +
- Focus and VetoableChangeListener +
- Z-Order +
- Replacing DefaultKeyboardFocusManager +
- Incompatibilities with Previous Releases +
Overview of KeyboardFocusManager
++ The focus model is centralized around a single class, + KeyboardFocusManager, that provides a set of APIs for client code to + inquire about the current focus state, initiate focus changes, and + replace default focus event dispatching with a custom dispatcher. + Clients can inquire about the focus state directly, or can register a + PropertyChangeListener that will receive PropertyChangeEvents when a + change to the focus state occurs. +
+ KeyboardFocusManager introduces the following main concepts and their + terminology: +
+
+ +- The "focus owner" -- the Component which typically receives + keyboard input. +
- The "permanent focus owner" -- the last Component to receive + focus permanently. The "focus owner" and the "permanent focus + owner" are equivalent unless a temporary focus change is + currently in effect. In such a situation, the "permanent focus + owner" will again be the "focus owner" when the temporary focus + change ends. +
- The "focused Window" -- the Window which contains the "focus + owner". +
- The "active Window" -- the Frame or Dialog that is either the + "focused Window", or the first Frame or Dialog that is an owner + of the "focused Window". +
- "Focus traversal" -- the user's ability to change the "focus + owner" without moving the cursor. Typically, this is done using + the keyboard (for example, by using the TAB key), or an + equivalent device in an accessible environment. Client code can + also initiate traversal programmatically. Normal focus traversal + can be either "forward" to the "next" Component, or "backward" to + the "previous" Component. +
- "Focus traversal cycle" -- a portion of the Component hierarchy, + such that normal focus traversal "forward" (or "backward") will + traverse through all of the Components in the focus cycle, but no + other Components. This cycle provides a mapping from an arbitrary + Component in the cycle to its "next" (forward traversal) and + "previous" (backward traversal) Components. +
- "Traversable Component" -- Component that is in the focus traversal + cycle. +
- "Non-traversable Component" -- Component that is not in the focus + traversal cycle. Note that a non-traversable Component can nevertheless + be focused in other way (e.g. by direct focus request). +
- "Focus cycle root" -- Container that is the root of the Component + hierarchy for a particular "focus traversal cycle". When the + "focus owner" is a Component inside a particular cycle, normal + forward and backward focus traversal cannot move the "focus + owner" above the focus cycle root in the Component hierarchy. + Instead, two additional traversal operations, "up cycle" and + "down cycle", are defined to allow keyboard and programmatic + navigation up and down the focus traversal cycle hierarchy.
+- "Focus traversal policy provider" - Container which has + "FocusTraversalPolicyProvider" property as true. This Container will + be used to acquire focus traversal policy. This container doesn't + define new focus cycle but only modifies the order by which its + children are traversed "forward" and "backward". Focus traversal + policy provider can be set using +
setFocusTraversalPolicyProvider
on the Container. ++ Every Window and JInternalFrame is, by default, a "focus cycle + root". If it's the only focus cycle root, then all of its + focusable descendants should be in its focus cycle, and its focus + traversal policy should enforce that they are by making sure that + all will be reached during normal forward (or backward) + traversal. If, on the other hand, the Window or JInternalFrame + has descendants that are also focus cycle roots, then each such + descendant is a member of two focus cycles: the one that it is + the root of, and the one of its nearest focus-cycle-root + ancestor. In order to traverse the focusable components belonging + to the focus cycle of such a "descendant" focus cycle root, one + first traverses (forward or backward) to reach the descendant, + and then uses the "down cycle" operation to reach, in turn, its + descendants. + +
+ Here is an example:
+ +Assume the following: +
+
+ + There are a total of three focus cycle roots in this example: + +- A is a
Window
, which means that it + must be a focus cycle root. +- B and D are
Container
s that + are focus cycle roots. +- C is a
Container
that is not a focus cycle root. +- G, H, E, and F are all +
Component
s. ++
+ + Windows are the only Containers which, by default, are focus cycle + roots. + + +- A is a root, and A, B, C, + and F are members of A's cycle. +
- B is a root, and B, D, and + E are members of B's cycle. +
- D is a root, and D, G, + and H are members of D's cycle. +
KeyboardFocusManager
is an abstract class. AWT provides a default +implementation in theDefaultKeyboardFocusManager
class. + + + +KeyboardFocusManager and Browser Contexts
++Some browsers partition applets in different code bases into separate +contexts, and establish walls between these contexts. Each thread and +each Component is associated with a particular context and cannot +interfere with threads or access Components in other contexts. In such +a scenario, there will be one KeyboardFocusManager per context. Other +browsers place all applets into the same context, implying that there +will be only a single, global KeyboardFocusManager for all +applets. This behavior is implementation-dependent. Consult your +browser's documentation for more information. No matter how many +contexts there may be, however, there can never be more than one focus +owner, focused Window, or active Window, per ClassLoader. + + + +
KeyEventDispatcher and KeyEventPostProcessor
++While the user's KeyEvents should generally be delivered to the focus +owner, there are rare cases where this is not desirable. An input +method is an example of a specialized Component that should receive +KeyEvents even though its associated text Component is and should +remain the focus owner. +
+A KeyEventDispatcher is a lightweight interface that allows client +code to pre-listen to all KeyEvents in a particular context. Instances +of classes that implement the interface and are registered with the +current KeyboardFocusManager will receive KeyEvents before they are +dispatched to the focus owner, allowing the KeyEventDispatcher to +retarget the event, consume it, dispatch it itself, or make other +changes. +
+For consistency, KeyboardFocusManager itself is a +KeyEventDispatcher. By default, the current KeyboardFocusManager will +be the sink for all KeyEvents not dispatched by the registered +KeyEventDispatchers. The current KeyboardFocusManager cannot be +completely deregistered as a KeyEventDispatcher. However, if a +KeyEventDispatcher reports that it dispatched the KeyEvent, regardless +of whether it actually did so, the KeyboardFocusManager will take no +further action with regard to the KeyEvent. (While it is possible for +client code to register the current KeyboardFocusManager as a +KeyEventDispatcher one or more times, there is no obvious reason why +this would be necessary, and therefore it is not recommended.) +
+Client-code may also post-listen to KeyEvents in a particular context +using the KeyEventPostProcessor interface. KeyEventPostProcessors +registered with the current KeyboardFocusManager will receive +KeyEvents after the KeyEvents have been dispatched to and handled by +the focus owner. The KeyEventPostProcessors will also receive +KeyEvents that would have been otherwise discarded because no +Component in the application currently owns the focus. This will allow +applications to implement features that require global KeyEvent post- +handling, such as menu shortcuts. +
+Like KeyEventDispatcher, KeyboardFocusManager also implements +KeyEventPostProcessor, and similar restrictions apply to its use in +that capacity. + + +
FocusEvent and WindowEvent
++The AWT defines the following six event types central to the focus +model in two different
java.awt.event
classes: ++
+ + +WindowEvent.WINDOW_ACTIVATED
: This event is + dispatched to a Frame or Dialog (but never a Window which + is not a Frame or Dialog) when it becomes the active Window. +WindowEvent.WINDOW_GAINED_FOCUS
: This event is + dispatched to a Window when it becomes the focused Window. + Only focusable Windows can receive this event. +FocusEvent.FOCUS_GAINED
: This event is dispatched + to a Component when it becomes the focus owner. Only focusable + Components can receive this event. +FocusEvent.FOCUS_LOST
: This event is dispatched + to a Component when it is no longer the focus owner. +WindowEvent.WINDOW_LOST_FOCUS
: This event is + dispatched to a Window when it is no longer the focused Window. +WindowEvent.WINDOW_DEACTIVATED
: This event is + dispatched to a Frame or Dialog (but never a Window which is + not a Frame or Dialog) when it is no longer the active Window. +Event Delivery
++If the focus is not in java application and the user clicks on a focusable +child Componenta of an inactive Frame b, the following events +will be dispatched and handled in order: + +
+
+ +If the user later clicks on a focusable child Component c of another +Frame d, the following events will be dispatched and handled in +order: +- b will receive a
WINDOW_ACTIVATED
event. +- Next, b will receive a
WINDOW_GAINED_FOCUS
event. +- Finally, a will receive a
FOCUS_GAINED
event. ++
+ +Note that each event will be fully handled before the next event is +dispatched. This restriction will be enforced even if the Components +are in different contexts and are handled on different event +dispatching threads. +- a will receive a
FOCUS_LOST
event. +- b will receive a
WINDOW_LOST_FOCUS
event. +- b will receive a
WINDOW_DEACTIVATED
event. +- d will receive a
WINDOW_ACTIVATED
event. +- d will receive a
WINDOW_GAINED_FOCUS
event. +- c will receive a
FOCUS_GAINED
event. ++In addition, each event type will be dispatched in 1-to-1 +correspondence with its opposite event type. For example, if a +Component receives a
FOCUS_GAINED
event, under no +circumstances can it ever receive anotherFOCUS_GAINED
+event without an interveningFOCUS_LOST
event. ++Finally, it is important to note that these events are delivered for +informational purposes only. It is impossible, for example, to prevent +the delivery of a pending
FOCUS_GAINED
event by requesting +focus back to the Component losing focus while handling the preceding +FOCUS_LOST
event. While client code may make such a request, +the pendingFOCUS_GAINED
will still be delivered, +followed later by the events transferring focus back to the original +focus owner. ++If it is absolutely necessary to suppress the
FOCUS_GAINED
event, +client code can install aVetoableChangeListener
which +rejects the focus change. See Focus +and VetoableChangeListener. + + + +Opposite Components and Windows
++Each event includes information about the "opposite" Component or +Window involved in the focus or activation change. For example, for a +
FOCUS_GAINED
event, the opposite Component is the Component +that lost focus. If the focus or activation change occurs with a native +application, with a Java application in a different VM or context, or +with no other Component, then the opposite Component or Window is +null. This information is accessible using +FocusEvent.getOppositeComponent
or +WindowEvent.getOppositeWindow
. ++On some platforms, it is not possible to discern the opposite +Component or Window when the focus or activation change occurs between +two different heavyweight Components. In these cases, the opposite +Component or Window may be set to null on some platforms, and to a +valid non-null value on other platforms. However, for a focus change +between two lightweight Components which share the same heavyweight +Container, the opposite Component will always be set correctly. Thus, +a pure Swing application can ignore this platform restriction when +using the opposite Component of a focus change that occurred within a +top-level Window. + + +
Temporary FocusEvents
++
FOCUS_GAINED
andFOCUS_LOST
events are +marked as either temporary or permanent. ++Temporary
FOCUS_LOST
events are sent when a Component is +losing the focus, but will regain the focus shortly. These events +can be useful when focus changes are used as triggers for validation +of data. For instance, a text Component may want to commit its +contents when the user begins interacting with another Component, +and can accomplish this by responding toFOCUS_LOST
events. +However, if theFocusEvent
received is temporary, +the commit should not be done, since the text field will be receiving +the focus again shortly. ++A permanent focus transfer typically occurs as the result of a user +clicking on a selectable, heavyweight Component, focus traversal with +the keyboard or an equivalent input device, or from a call to +
requestFocus()
orrequestFocusInWindow()
. ++A temporary focus transfer typically occurs as the result of showing a +Menu or PopupMenu, clicking or dragging a Scrollbar, moving a Window +by dragging the title bar, or making another Window the focused +Window. Note that on some platforms, these actions may not generate +any FocusEvents at all. On others, temporary focus transfers will +occur. +
+When a Component receives a temporary
FOCUS_LOST
event, +the event's opposite Component (if any) may receive a temporary +FOCUS_GAINED
event, but could also receive a permanent +FOCUS_GAINED
event. Showing a Menu or PopupMenu, or +clicking or dragging a Scrollbar, should generate a temporary +FOCUS_GAINED
event. Changing the focused Window, +however, will yield a permanentFOCUS_GAINED
event +for the new focus owner. ++The Component class includes variants of
requestFocus
and +requestFocusInWindow
which take a desired temporary state as a +parameter. However, because specifying an arbitrary temporary state +may not be implementable on all native windowing systems, correct +behavior for this method can be guaranteed only for lightweight +Components. This method is not intended for general use, but exists +instead as a hook for lightweight Component libraries, such as Swing. + + +Focus Traversal
++Each Component defines its own Set of focus traversal keys for a given +focus traversal operation. Components support separate Sets of keys +for forward and backward traversal, and also for traversal up one +focus traversal cycle. Containers which are focus cycle roots also +support a Set of keys for traversal down one focus traversal cycle. If +a Set is not explicitly defined for a Component, that Component +recursively inherits a Set from its parent, and ultimately from a +context-wide default set on the current
KeyboardFocusManager
. ++Using the
AWTKeyStroke
API, client code can specify +on which of two specific KeyEvents,KEY_PRESSED
or +KEY_RELEASED
, the focus traversal operation will occur. +Regardless of which KeyEvent is specified, however, all KeyEvents +related to the focus traversal key, including the associated +KEY_TYPED
event, will be consumed, and will not be +dispatched to any Component. It is a runtime error to specify a +KEY_TYPED
event as mapping to a focus traversal operation, +or to map the same event to multiple focus traversal operations for any +particular Component or for aKeyboardFocusManager
's defaults. ++The default focus traversal keys are implementation-dependent. Sun +recommends that the all implementations for a particular native +platform use the same keys. For Windows and Unix, the recommendations +are: + +
+
+- traverse forward to the next Component: +
TextAreas:CTRL-TAB
onKEY_PRESSED
+
All others:TAB
onKEY_PRESSED
and +CTRL-TAB
onKEY_PRESSED
+- traverse backward to the previous Component: +
TextAreas:CTRL-SHIFT-TAB
on +KEY_PRESSED
+
All others:SHIFT-TAB
onKEY_PRESSED
+ andCTRL-SHIFT-TAB
on +KEY_PRESSED
+- traverse up one focus traversal cycle : <none> +
- traverse down one focus traversal cycle : <none> +
+Components can enable and disable all of their focus traversal keys en +masse using
Component.setFocusTraversalKeysEnabled
. When focus +traversal keys are disabled, the Component receives all KeyEvents for +those keys. When focus traversal keys are enabled, the Component never +receives KeyEvents for traversal keys; instead, the KeyEvents are +automatically mapped to focus traversal operations. ++For normal forward and backward traversal, the AWT focus +implementation determines which Component to focus next based on the +
FocusTraversalPolicy
of +the focus owner's focus cycle root or focus traversal policy provider. If the +focus owner is a focus cycle root, then it may be ambiguous as to which +Components represent the next and previous Components to focus during +normal focus traversal. Thus, the current +KeyboardFocusManager
maintains a reference to the +"current" focus cycle root, which is global across all contexts. The +current focus cycle root is used to resolve the ambiguity. ++For up-cycle traversal, the focus owner is set to the current focus +owner's focus cycle root, and the current focus cycle root is set to +the new focus owner's focus cycle root. If, however, the current focus +owner's focus cycle root is a top-level window, then the focus owner +is set to the focus cycle root's default component to focus, and the +current focus cycle root is unchanged. +
+For down-cycle traversal, if the current focus owner is a focus cycle +root, then the focus owner is set to the current focus owner's default +component to focus, and the current focus cycle root is set to the +current focus owner. If the current focus owner is not a focus cycle +root, then no focus traversal operation occurs. + + + +
FocusTraversalPolicy
++ +A
FocusTraversalPolicy
defines the order in which Components within +a particular focus cycle root or focus traversal policy provider are +traversed. Instances ofFocusTraversalPolicy
can be shared across +Containers, allowing those Containers to implement the same traversal policy. +FocusTraversalPolicies do not need to be reinitialized when the +focus-traversal-cycle hierarchy changes. + ++Each
FocusTraversalPolicy
must define the following +five algorithms: + ++
+ +- Given a focus cycle root and a Component a in that cycle, the + next Component after a. +
- Given a focus cycle root and a Component a in that cycle, the + previous Component before a. +
- Given a focus cycle root, the "first" Component in that cycle. + The "first" Component is the Component to focus when traversal + wraps in the forward direction. +
- Given a focus cycle root, the "last" Component in that cycle. + The "last" Component is the Component to focus when traversal + wraps in the reverse direction. +
- Given a focus cycle root, the "default" Component in that cycle. + The "default" Component will be the first to receive focus when + traversing down into a new focus traversal cycle. This may be the + same as the "first" Component, but need not be. +
+A
FocusTraversalPolicy
may optionally provide an +algorithm for the following: ++ Given a Window, the "initial" Component in that Window. The initial + Component will be the first to receive focus when the Window is + first made visible. By default, this is the same as the "default" + Component. ++ +In addition, Swing provides a subclass ofFocusTraversalPolicy
, +InternalFrameFocusTraversalPolicy
, which allows developers +to provide an algorithm for the following: + ++ Given a+ +AJInternalFrame
, the "initial" Component in that +JInternalFrame
. The initial Component is the first to + receive focus when theJInternalFrame
is first selected. + By default, this is the same as theJInternalFrame
's + default Component to focus. +FocusTraversalPolicy
is installed on a Container using +Container.setFocusTraversalPolicy
. If a policy is not explicitly +set, then a Container inherits its policy from its nearest focus-cycle-root +ancestor. Top-levels initialize their focus traversal policies using the context +default policy. The context default policy is established by using +KeyboardFocusManager.setDefaultFocusTraversalPolicy
. + ++AWT provides two standard
FocusTraversalPolicy
+implementations for use by client code. + ++
+ContainerOrderFocusTraversalPolicy
: Iterates across the + Components in a focus traversal cycle in the order they were added + to their Containers. Each Component is tested for fitness using the + accept(Component) method. By default, a Component is fit only if it + is visible, displayable, enabled, and focusable. +- By default, ContainerOrderFocusTraversalPolicy implicitly transfers + focus down-cycle. That is, during normal forward focus traversal, + the Component traversed after a focus cycle root will be the + focus-cycle-root's default Component to focus, regardless of whether + the focus cycle root is a traversable or non-traversable Container + (see the pic.1,2 below). Such behavior provides backward compatibility + with applications designed without the concepts of up- and down-cycle + traversal. +
DefaultFocusTraversalPolicy
: A subclass of +ContainerOrderFocusTraversalPolicy
which redefines + the fitness test. If client code has explicitly set the + focusability of a Component by either overriding +Component.isFocusTraversable()
or +Component.isFocusable()
, or by calling +Component.setFocusable(boolean)
, then a +DefaultFocusTraversalPolicy
behaves exactly + like aContainerOrderFocusTraversalPolicy
. If, + however, the Component is relying on default focusability, then a +DefaultFocusTraversalPolicy
will reject all + Components with non-focusable peers. +
+ The focusability of a peer is implementation-dependent. Sun + recommends that all implementations for a particular native platform + construct peers with the same focusability. The recommendations for + Windows and Unix are that Canvases, Labels, Panels, Scrollbars, + ScrollPanes, Windows, and lightweight Components have non-focusable + peers, and all other Components have focusable peers. These + recommendations are used in the Sun AWT implementations. Note that + the focusability of a Component's peer is different from, and does + not impact, the focusability of the Component itself. ++Swing provides two additional, standard FocusTraversalPolicy +implementations for use by client code. Each implementation is an +InternalFrameFocusTraversalPolicy. + +
+
+- SortingFocusTraversalPolicy: Determines traversal order by + sorting the Components of a focus traversal cycle based on a given + Comparator. Each Component is tested for fitness using the + accept(Component) method. By default, a Component is fit only if it + is visible, displayable, enabled, and focusable. +
- By default, SortingFocusTraversalPolicy implicitly transfers focus + down-cycle. That is, during normal forward focus traversal, the + Component traversed after a focus cycle root will be the + focus-cycle-root's default Component to focus, regardless of + whether the focus cycle root is a traversable or non-traversable + Container (see the pic.1,2 below). Such behavior provides backward + compatibility with applications designed without the concepts of + up- and down-cycle traversal. +
- LayoutFocusTraversalPolicy: A subclass of + SortingFocusTraversalPolicy which sorts Components based on their + size, position, and orientation. Based on their size and position, + Components are roughly categorized into rows and columns. For a + Container with horizontal orientation, columns run left-to-right or + right-to-left, and rows run top-to-bottom. For a Container with + vertical orientation, columns run top-to-bottom and rows run + left-to-right or right-to-left. All columns in a row are fully + traversed before proceeding to the next row. +
+ In addition, the fitness test is extended to exclude JComponents + that have or inherit empty InputMaps. ++The figure below shows an implicit focus transfer: +
+ +Assume the following: ++
+ +- A, B and C are components in some window (a container) +
- R is a container in the window and it is a parent of B and C. + Besides, R is a focus cycle root. +
- B is the default component in the focul traversal cycle of R +
- R is a traversable Container in the pic.1, and it is a non-traversable + Container in the pic.2. +
- In such a case a forward traversal will look as follows: +
+
+- pic.1 : A -> R -> B -> C +
- pic.2 : A -> B -> C +
+Swing applications, or mixed Swing/AWT applications, that use one of +the standard look and feels, or any other look and feel derived from +BasicLookAndFeel, will use LayoutFocusTraversalPolicy for all +Containers by default. +
+All other applications, including pure AWT applications, will use +
DefaultFocusTraversalPolicy
by default. + + +Focus Traversal Policy Providers
++ A Container that isn't a focus cycle root has an option to provide a + FocusTraversalPolicy of its own. To do so, one needs to set Container's focus + traversal policy provider property to
true
with the call to + +++ + To determine whether a Container is a focus traversal policy provider, the + following method should be used: + +Container.setFocusTraversalPolicyProvider(boolean)
+++ + If focus traversal policy provider property is set on a focus cycle root, it + isn't considered a focus traversal policy provider and behaves just like any + other focus cycle root. + +Container.isFocusTraversalPolicyProvider()
++ The main difference between focus cycle roots and focus traversal policy + providers is that the latter allow focus to enter and leave them just as all other + Containers. However, children inside focus traversal policy provider are + traversed in the order determined by provider's FocusTraversalPolicy. In order + to enable focus traversal policy providers to behave this way, + FocusTraversalPolicies treat them in the following manner: + +
+
+ + +- Focus traversal policy providers can be passed to FocusTraversalPolicy + methods instead of focus cycle roots. +
- When calculating next or previous Component in +
FocusTraversalPolicy.getComponentAfter
or +FocusTraversalPolicy.getComponentBefore
, ++
+- if a Component is a child of a focus traversal policy provider, + the next and previous for this Component are determined using this + focus traversal policy provider's FocusTraversalPolicy. However, + in order for focus to leave the provider, the following rules are + applied: +
+
+- if at some point the
next
found Component is + thefirst
Component of focus traversal policy + provider, the Component after the focus traversal policy + provider is returned +- if at some point the
previous
found Component is + thelast
Component of focus traversal policy + provider, the Component before the focus traversal policy + provider is returned +- When calculating the next Component in +
FocusTraversalPolicy.getComponentAfter
, ++
+- if an obtained Component is a non-traversable Container and + it is a focus traversal policy provider, then the default Component + of that provider is returned +
- if the Component passed to the
FocusTraversalPolicy.getComponentAfter
+ method is a traversable Container and it is a focus + traversal policy provider, then the default Component of this provider + is returned +- When calculating the previous Component in +
FocusTraversalPolicy.getComponentBefore
, ++
+- if an obtained Component is a Container (traversable or + non-traversable) and it is a focus traversal policy provider, then + the last Component of that provider is returned +
- When calculating the first Component in FocusTraversalPolicy.getFirstComponent, +
+
+- if an obtained Component is a non-traversable Container and it is a focus + traversal policy provider, then the default Component of that provider is + returned +
- if an obtained Component is a traversable Container and it is a focus traversal + policy provider, then that Container itself is returned +
- When calculating the last Component in FocusTraversalPolicy.getLastComponent, +
+
+- if an obtained Component is a Container (traversable or non-traversable) + and it is a focus traversal policy provider, then the last Component of + that provider is returned +
Programmatic Traversal
++In addition to user-initiated focus traversal, client code can +initiate a focus traversal operation programmatically. To client code, +programmatic traversals are indistinguishable from user-initiated +traversals. The preferred way to initiate a programmatic traversal is +to use one of the following methods on
KeyboardFocusManager
: + ++
+ +KeyboardFocusManager.focusNextComponent()
+KeyboardFocusManager.focusPreviousComponent()
+KeyboardFocusManager.upFocusCycle()
+KeyboardFocusManager.downFocusCycle()
++Each of these methods initiates the traversal operation with the +current focus owner. If there is currently no focus owner, then no +traversal operation occurs. In addition, if the focus owner is not a +focus cycle root, then downFocusCycle() performs no traversal +operation. +
+
KeyboardFocusManager
also supports the following variants +of these methods: + ++
+ +Each of these methods initiates the traversal operation with the +specified Component rather than the focus owner. That is, the +traversal occurs as though the specified Component is the focus owner, +though it need not be. +KeyboardFocusManager.focusNextComponent(Component)
+KeyboardFocusManager.focusPreviousComponent(Component)
+KeyboardFocusManager.upFocusCycle(Component)
+KeyboardFocusManager.downFocusCycle(Container)
++Alternate, but equivalent, APIs are defined on the Component and +Container classes themselves: + +
+
+ +As with theComponent.transferFocus()
+Component.transferFocusBackward()
+Component.transferFocusUpCycle()
+Container.transferFocusDownCycle()
+KeyboardFocusManager
variants, each of these methods +initiates the traversal operation as though the Component is the focus +owner, though it need not be. ++Also note that hiding or disabling the focus owner, directly or +indirectly via an ancestor, or making the focus owner non-displayable +or non-focusable, initiates an automatic, forward focus traversal. +While hiding any ancestor, lightweight or heavyweight, will always +indirectly hide its children, only disabling a heavyweight ancestor +will disable its children. Thus, disabling a lightweight ancestor of +the focus owner does not automatically initiate a focus traversal. +
+If client code initiates a focus traversal, and there is no other +Component to focus, then the focus owner remains unchanged. If client +code initiates an automatic focus traversal by hiding the focus owner, +directly or indirectly, or by making the focus owner non-displayable or +non-focusable, and there is no other Component to focus, then the +global focus owner is cleared. If client code initiates an automatic +focus traversal by disabling the focus owner, directly or indirectly, +and there is no other Component to focus, then the focus owner remains +unchanged. + + + +
Focusability
++A focusable Component can become the focus owner ("focusability") and +participates in keyboard focus traversal ("focus traversability") with +a FocusTraversalPolicy. There is no separation of these two concepts; +a Component must either be both focusable and focus traversable, or +neither. + +A Component expresses this state via the isFocusable() method. By +default, all Components return true from this method. Client code can +change this default by calling Component.setFocusable(boolean). + + + +
Focusable Windows
++To support palette windows and input methods, client code can prevent +a Window from becoming the focused Window. By transitivity, this +prevents the Window or any of its descendants from becoming the focus +owner. Non-focusable Windows may still own Windows that are +focusable. By default, every Frame and Dialog is focusable. Every +Window which is not a Frame or Dialog, but whose nearest owning Frame +or Dialog is showing on the screen, and which has at least one +Component in its focus traversal cycle, is also focusable by +default. To make a Window non-focusable, use +Window.setFocusableWindowState(false). +
+If a Window is non-focusable, this restriction is enforced when the +
KeyboardFocusManager
sees aWINDOW_GAINED_FOCUS
+event for the Window. At this point, the focus change is rejected and +focus is reset to a different Window. The rejection recovery scheme +is the same as if aVetoableChangeListener
rejected the +focus change. See Focus +and VetoableChangeListener. ++Because the new focus implementation requires that KeyEvents intended +for a Window or its descendants be proxied through a child of the +Window's owner, and because this proxy must be mapped on X11 in order +to receive events, a Window whose nearest owning Frame or Dialog is +not showing could never receive KeyEvents on X11. To support this +restriction, we have made a distinction between a Window's "window +focusability" and its "window focusability state". A Window's +focusability state is combined with the showing state of the Window's +nearest owning Frame or Dialog to determine the Window's focusability. +By default, all Windows have a focusability state of true. Setting a +Window's focusability state to false ensures that it will not become +the focused Window regardless of the showing state of its nearest +owning Frame or Dialog. +
+Swing allows applications to create JWindows with null owners. Swing +constructs all such JWindows so that they are owned by a private, +hidden Frame. Because the showing state of this Frame will always be +false, a JWindow constructed will a null owner can never be the +focused Window, even if it has a Window focusability state of true. +
+If the focused Window is made non-focusable, then the AWT will attempt +to focus the most recently focused Component of the Window's +owner. The Window's owner will thus become the new focused Window. If +the Window's owner is also a non-focusable Window, then the focus +change request will proceed up the ownership hierarchy recursively. +Since not all platforms support cross-Window focus changes (see +Requesting Focus), it is possible that +all such focus change requests will fail. In this case, the global +focus owner will be cleared and the focused Window will remain unchanged. + + +
Requesting Focus
+ ++A Component can request that it become the focus owner by calling +
Component.requestFocus()
. This initiates a permanent +focus transfer to the Component only if the Component is displayable, +focusable, visible and all of its ancestors (with the exception of the +top-level Window) are visible. The request will be immediately denied if +any of these conditions is not met. A disabled Component may be +the focus owner; however, in this case, all KeyEvents will be discarded. ++The request will also be denied if the Component's top-level Window is +not the focused Window and the platform does not support requesting +focus across Windows. If the request is denied for this reason, the +request is remembered and will be granted when the Window is later +focused by the user. Otherwise, the focus change request changes the +focused Window as well. +
+There is no way to determine synchronously whether a focus change +request has been granted. Instead, client code must install a +FocusListener on the Component and watch for the delivery of a +
FOCUS_GAINED
event. Client code must not assume that +the Component is the focus owner until it receives this event. +The event may or may not be delivered beforerequestFocus()
+returns. Developers must not assume one behavior or the other. ++The AWT supports type-ahead if all focus change requests are made on +the EventDispatchThread. If client code requests a focus change, and +the AWT determines that this request might be granted by the native +windowing system, then the AWT will notify the current +KeyboardFocusManager that is should enqueue all KeyEvents with a +timestamp later than the that of the event currently being handled. +These KeyEvents will not be dispatched until the new Component becomes +the focus owner. The AWT will cancel the delayed dispatching request +if the focus change does not succeed at the native level, if the +Component's peer is disposed, or if the focus change is vetoed by a +VetoableChangeListener. KeyboardFocusManagers are not required to +support type-ahead if a focus change request is made from a thread +other than the EventDispatchThread. +
+Because
Component.requestFocus()
cannot be implemented +consistently across platforms, developers are encouraged to use +Component.requestFocusInWindow()
instead. This method +denies cross-Window focus transfers on all platforms automatically. +By eliminating the only platform-specific element of the focus transfer, +this method achieves consistent cross-platform behavior. ++In addition,
requestFocusInWindow()
returns a boolean value. +If 'false' is returned, the request is guaranteed to fail. If 'true' is +returned, the request will succeed unless it is vetoed, or an +extraordinary event, such as disposal of the Component's peer, occurs +before the request can be granted by the native windowing +system. Again, while a return value of 'true' indicates that the +request is likely to succeed, developers must never assume that this +Component is the focus owner until this Component receives a +FOCUS_GAINED
event. ++If client code wants no Component in the application to be the focus +owner, it can call the method
KeyboardFocusManager
. +clearGlobalFocusOwner()
on the current +KeyboardFocusManager
. If there exists a focus owner +when this method is called, the focus owner will receive a permanent +FOCUS_LOST
event. After this point, the AWT +focus implementation will discard all KeyEvents until the user or +client code explicitly sets focus to a Component. ++The Component class also supports variants of
requestFocus
and +requestFocusInWindow
that allow client code to specify +a temporary state. +See Temporary FocusEvents + + +Focus and PropertyChangeListener
++Client code can listen to changes in context-wide focus state, or to +changes in focus-related state in Components, via +PropertyChangeListeners. +
+The
KeyboardFocusManager
supports the following properties: + ++
+focusOwner
: the focus owner +focusedWindow
: the focused Window +activeWindow
: the active Window +defaultFocusTraversalPolicy
: the default focus + traversal policy +forwardDefaultFocusTraversalKeys
: the Set of default +FORWARD_TRAVERSAL_KEYS
+backwardDefaultFocusTraversalKeys
: the Set of default +BACKWARD_TRAVERSAL_KEYS
+upCycleDefaultFocusTraversalKeys
: the Set of default +UP_CYCLE_TRAVERSAL_KEYS
+downCycleDefaultFocusTraversalKeys
: the Set of default +DOWN_CYCLE_TRAVERSAL_KEYS
+currentFocusCycleRoot
: the current focus cycle root ++A
PropertyChangeListener
installed on the current +KeyboardFocusManager
will only see these changes within +theKeyboardFocusManager
's context, even though the +focus owner, focused Window, active Window, and current focus cycle +root comprise the global focus state shared by all contexts. +We believe this is less intrusive than requiring client code to pass +a security check before installing aPropertyChangeListener
. ++Component supports the following focus-related properties: + +
+
+focusable
: the Component's focusability +focusTraversalKeysEnabled
: the Component's + focus traversal keys enabled state +forwardFocusTraversalKeys
: the Component's Set of +FORWARD_TRAVERSAL_KEYS
+backwardFocusTraversalKeys
: the Component's Set of +BACKWARD_TRAVERSAL_KEYS
+upCycleFocusTraversalKeys
: the Component's Set of +UP_CYCLE_TRAVERSAL_KEYS
++In addition to the Component properties, Container supports the +following focus-related properties: + +
+
+downCycleFocusTraversalKeys
: the Container's Set of +DOWN_CYCLE_TRAVERSAL_KEYS
+focusTraversalPolicy
: the Container's focus + traversal policy +focusCycleRoot
: the Container's focus-cycle-root state ++In addition to the Container properties, Window supports the following +focus-related property: + +
+
+focusableWindow
: the Window's focusable Window state ++Also note that a
PropertyChangeListener
installed on a +Window will never see aPropertyChangeEvent
for the +focusCycleRoot
property. +A Window is always a focus cycle root; this property cannot change. +Focus and VetoableChangeListener
++The
KeyboardFocusManager
also supports +VetoableChangeListener
s for the following properties: + ++
+ +If a VetoableChangeListener vetoes a focus or activation change by +throwing a PropertyVetoException, the change is aborted. Any +VetoableChangeListeners which had already approved the change will +asynchronously receive PropertyChangeEvents indicating a reversion of +state to the previous value. +- "focusOwner": the focus owner +
- "focusedWindow": the focused Window +
- "activeWindow": the active Window +
+VetoableChangeListeners are notified of the state change before the +change is reflected in the KeyboardFocusManager. Conversely, +PropertyChangeListeners are notified after the change is reflected. +It follows that all VetoableChangeListeners will be notified before +any PropertyChangeListener. +
+VetoableChangeListeners must be idempotent, and must veto both loss +and gain events for a particular focus change (e.g., both +
FOCUS_LOST
andFOCUS_GAINED
). For example, +if aVetoableChangeListener
vetoes aFOCUS_LOST
+event, aKeyboardFocusManager
is not required to search the +EventQueue
and remove the associated pending +FOCUS_GAINED
event. Instead, the +KeyboardFocusManager
is free to attempt to +dispatch this event and it is the responsibility of the +VetoableChangeListener
to veto it as well. In addition, +during processing of theFOCUS_GAINED
event, the +KeyboardFocusManager
may attempt to resync the global +focus state by synthesizing anotherFOCUS_LOST
event. +This event must be vetoed just as the firstFOCUS_LOST
event was. ++A
KeyboardFocusManager
may not hold any locks while +notifyingPropertyChangeListener
s of a state change. +This requirement is relaxed forVetoableChangeListeners
, +however. Therefore, client-definiedVetoableChangeListener
s +should avoid acquiring additional locks inside +vetoableChange(PropertyChangeEvent)
as this may lead to deadlock. + +If a focus or activation change is rejected, the KeyboardFocusManager +will initiate rejection recovery as follows: + ++
+ +- If a focused or active Window change was rejected, then the + focused or active Window will be reset to the Window which was + previously the focused or active Window. If there is no such + Window, then the
KeyboardFocusManager
will clear + the global focus owner. +- If a focus owner change was rejected, then the focus owner will be + reset to the Component which was previously the focus owner. If + that is not possible, then it will be reset to the next Component + in the focus traversal cycle after the previous focus owner. If + that is also not possible, then the
KeyboardFocusManager
+ will clear the global focus owner. +VetoableChangeListener
s must be careful to avoid vetoing focus +changes initiated as a result of veto rejection recovery. Failure +to anticipate this situation could lead to an infinite cycle of +vetoed focus changes and recovery attempts. + + + +Z-Order
++On some native windowing systems, the Z-order of a Window can affect +its focused or active (if applicable) state. On Microsoft Windows, the +top-most Window is naturally the focused Window as well. However, on +Solaris, many window managers use a point-to-focus model that ignores +Z-order in determining the focused Window. + +When focusing or activating Windows, the AWT adheres to the UI +requirements of the native platform. Therefore, the focus behavior of +Z-order-related methods such as: +
+
+is platform-dependent. In JDK 1.4, the behavior of these methods on +Microsoft Windows and Solaris is as follows: +Window.toFront()
+Window.toBack()
+Window.show()
+Window.hide()
+Window.setVisible(boolean)
+Window.dispose()
+Frame.setState(int)
++
+ + +Window.toFront()
:
+ Microsoft Windows: The Window is moved to front, if possible. + While we will always be able to move this Window in front of other + Windows in the same VM, Windows 98 and Windows 2000 do not allow an + application to bring any of its windows to the front unless one + of that application's windows is already in the foreground. In + this case, Windows will instead flash the Window's icon in the + taskbar. If the Window is moved to the front, it will be made + the focused and (if applicable) active Window. +
+ Solaris: The Window is moved to front. In a point-to-focus + window manager, the Window will become the focused Window if it + is the top-most Window underneath the cursor. In a click-to-focus + window manager, the focused Window will remain unchanged. + +Window.toBack()
:
+ Microsoft Windows: The Window is moved to back. Note however + that Microsoft Windows insists that an owned Window always be in + front of all of its recursive owners. Thus, after the completion of + this operation, the Window may not be the lowest Java Window in the + Z-order. If the Window, or any of its owners, was the focused Window, + then the focused Window is reset to the top-most Window in the VM. +
+ Solaris: The Window is moved to back. Like Microsoft Windows, + some window managers insist than an owned Window always be in front + of all of its recursive owners. Thus, after the completion of this + operation, the Window may not be the lowest Java Window in the + Z-order. If the Window was the focused Window, it will lose + focus in a point-to-focus window manager if it is no longer the + top-most Window under the cursor. In a click-to-focus window + manager, the focused Window will remain unchanged. + +Window.show()/Window.setVisible(true)/Frame.setState(NORMAL)
:
+ Microsoft Windows: The Window is moved to front and becomes the focused + Window. +
+ Solaris: The Window is moved to front. In a point-to-focus focus + window manager, the Window will be focused if it is now the + top-most Window under the cursor. In a click-to-focus window + manager, the Window will become the focused Window. + +Window.hide()/Window.setVisible(false)/Window.dispose()/ + Frame.setState(ICONIFIED)
:
+ Microsoft Windows: If the Window was the focused Window, the focused + Window is reset to a window chosen by the OS, or to no window. The + window may be in a native application, or a Java application in + another VM. +
+ Solaris: If the Window was the focused Window, in a point-to- + focus window manager, the top-most Window under the cursor will + become the focused Window. In a click-to-focus window manager, + the focused Window is reset to a window chosen by the window + manager. The window may be in a native application, or a Java + application in another VM. +Replacing DefaultKeyboardFocusManager
++
KeyboardFocusManager
s are pluggable at the browser context +level. Client code can subclassKeyboardFocusManager
or +DefaultKeyboardFocusManager
to modify the way that WindowEvents +related to focus, FocusEvents, and KeyEvents are handled and +dispatched, and to examine and modify the global focus state. A custom +KeyboardFocusManager
can also reject focus changes at a more +fundamental level then a FocusListener or WindowListener ever could. ++While giving a developer ultimate control over the focus model, +replacing the entire
KeyboardFocusManager
is a difficult process +requiring a thorough understanding of the peer focus layer. +Fortunately, most applications do not need this much control. +Developers are encouraged to use KeyEventDispatchers, +KeyEventPostProcessors, FocusTraversalPolicies, +VetoableChangeListeners, and other concepts discussed in this document +before resorting to a full replacement of theKeyboardFocusManager
. ++First note that, because unhindered access to Components in other +contexts represents a security hole, the SecurityManager must grant a +new permission, "replaceKeyboardFocusManager", before client code is +permitted to replace the
KeyboardFocusManager
with an arbitrary +subclass instance. Because of the security check, replacing the +KeyboardFocusManager
is not an option for applications that will be +deployed in environments with a SecurityManager, such as applets in a +browser. ++Once installed, a
KeyboardFocusManager
instance has +access to the global focus state via a set of protected functions. +TheKeyboardFocusManager
can only call these functions +if it is installed in the calling thread's context. This ensures +that malicious code cannot circumvent the security check in +KeyboardFocusManager.setCurrentFocusManager
. +AKeyboardFocusManager
should always work with +the global focus state instead of the context focus state. +Failure to do this will lead to incorrect behavior of the +KeyboardFocusManager
. ++The primary responsibility of a
KeyboardFocusManager
+is the dispatch of the following events: + ++
+ +The peer layer will provide the- all
KeyEvent
s +- all
FocusEvent
s +WindowEvent.WINDOW_GAINED_FOCUS
+WindowEvent.WINDOW_LOST_FOCUS
+WindowEvent.WINDOW_ACTIVATED
+WindowEvent.WINDOW_DEACTIVATED
+KeyboardFocusManager
+with all of the above events exceptWINDOW_ACTIVATED
+andWINDOW_DEACTIVATED
. TheKeyboardFocusManager
+must synthesizeWINDOW_ACTIVATED
and +WINDOW_DEACTIVATED
events when appropriate and target them +accordingly. ++The
KeyboardFocusManager
may need to retarget the events +provided by the peer layer to its own notion of the focus owner or +focused Window: ++
+- A KeyEvent must be retargeted to the focus owner. Because the peer + layer is unaware of any lightweight Components, KeyEvents will + arrive from the peer layer targeted to the focus owner's + heavyweight Container, not the focus owner. +
- A
FOCUS_LOST
event must be retargeted to the focus + owner. Again, this is necessary because the peer layer is + unaware of lightweight Components. +- A
WINDOW_LOST_FOCUS
event must be retargeted to + the focused Window. The implementation of the Window class + may cause the native focused Window to differ from the Java + focused Window. ++A
KeyboardFocusManager
must ensure proper event ordering, +and a 1-to-1 correspondence between an event and its opposite event type. +The peer layer does not make any of these guarantees. For example, it is +possible for the peer layer to send aFOCUS_GAINED
+event before aWINDOW_GAINED_FOCUS
event. +TheKeyboardFocusManager
is responsible for +ensuring that theWINDOW_GAINED_FOCUS
event is dispatched +before theFOCUS_GAINED
event. ++Before redispatching an event via
KeyboardFocusManager
. +redispatchEvent
, aKeyboardFocusManager
+must attempt to update the global focus state. Typically, this +is done using one of theKeyboardFocusManager.setGlobal*
+methods; however, an implementation is free to implement its own methods. +After attempting an update, theKeyboardFocusManager
+must verify that the global focus state change +was not rejected. A rejection is detected when a call to the +correspondinggetGlobal*
method returns a value different than the +value just set. Rejections occur in three standard cases: ++
+- If the
KeyboardFocusManager
attempts + to set the global focus owner to a non-focusable Component. +- If the
KeyboardFocusManager
attempts + to set the global focused Window to a non-focusable Window. +- If the change is rejected by an installed +
VetoableChangeListener
. ++Client-defined implementations of
KeyboardFocusManager
+can adjust the set of focus transfers which are rejected by overriding the +accessor and mutator methods for the global focus state. ++If a request to change the global focus state is rejected, the +
KeyboardFocusManager
must discard the event which prompted +the focus change request. The Component to which the event was targeted +must not receive the event. ++The
KeyboardFocusManager
is also expected to initiate rejection +recovery as outlined in Focus +and VetoableChangeListener. ++ Finally, a KeyboardFocusManager must handle the following set of + special cases: +
+
+ + +- When handling a
WINDOW_GAINED_FOCUS
event, the +KeyboardFocusManager
must set focus to the + appropriate child Component of the Window. If a child + Component of the Window previously requested focus, + but the focus change was rejected because the platform + does not support cross-Window focus change requests, + then focus should be set to that child Component. + Otherwise, if the Window has never been focused, focus should be + set to the Window's initial Component to focus. If the Window was + previously focused, focus should be set to the Window's most + recent focus owner. +- The
KeyboardFocusManager
must ensure that the + opposite Component or Window are as accurate as the native + windowing platform permits. For example, the +KeyboardFocusManager
may need to + retarget the opposite Component to a lightweight child of the + heavyweight initially specified by the peer layer. +
+ If the peer layer states that the opposite Component or Window is +null
, it is acceptable for the +KeyboardFocusManager
to propagate + this value.null
indicates that it is highly + probably that no other Component or Window was involved + in the focus or activation change. Because of platform + limitations, this computation may be + subject to a heuristic and could be incorrect. Nevertheless, this + heuristic will be the best possible guess which the peer layer + could make. +- Focus and activation changes in which a Component or Window loses + focus or activation to itself must be discarded. +
- Events posted by the peer layer claiming that the active Window + has lost focus to the focused Window must be discarded. The peer + implementation of the Window class may generate these spurious + events. +
Incompatibilities with Previous Releases
+Cross-platform changes: +
+
+- The default focus traversability for all Components is now + 'true'. Previously, some Components (in particular, all + lightweights), had a default focus traversability of 'false'. Note + that despite this change, however, the +
DefaultFocusTraversalPolicy
for all AWT Containers + will preserve the traversal order of previous releases. +- A request to focus a non-focus traversable (i.e., non-focusable) + Component will be denied. Previously, such requests were granted. +
Window.toFront()
andWindow.toBack()
+ now perform no operation if the Window is not visible. + Previously, the behavior was platform-dependent. +- KeyListeners installed on
Component
s + will no longer seeKeyEvent
s that map to focus + traversal operations, and +Component.handleEvent()
will no longer be invoked + for such events. Previously, AWT Components saw these events + and had an opportunity to consume them before AWT + initiated focus traversal. Code that requires this + functionality should instead disable focus traversal keys on + itsComponent
s and handle focus traversal + itself. Alternately, the code can use an +AWTEventListener
or +KeyEventDispatcher
to pre-listen to all +KeyEvent
s. +Changes specific to Microsoft Windows: +
+
+ + + diff --git a/out/production/classes1/awt/doc-files/FontMetrics-1.gif b/out/production/classes1/awt/doc-files/FontMetrics-1.gif new file mode 100644 index 0000000000000000000000000000000000000000..ab2b255e375bdd9375ae800524e07115b93de696 GIT binary patch literal 290 zcmV+-0p0#bNk%w1VJrYU0Du4h00030|NkNR1OWg50RSuj0000i06PEx0{KjUsmtwb zfSGj48XKWindow.toBack()
changes the focused Window to + the top-most Window after the Z-order change. +requestFocus()
now allows cross-Window focus + change requests in all cases. Previously, requests were granted + for heavyweights, but denied for lightweights. ++X_R8ZftKTj{3??7P9yF@VMw`!YV%V*zC*}FIy(;%d=eLKqqPNAjLzrj? zg7~C($QbE30(obd)fN{h*rZh{7J~_>xk+^vxK*ku3E0YMl^DAkS*s}n6e>C-8tbam z3mlwE(h+RKYbqnPV^h2gJxyJ0?II}aX++w%ZDcq1&9a*oJ&rs6BU`ARt`2Ih{rwJK o?@pPCUoH+0&h8D}ng{;kW$U$y4K#WRm2In2&{xB2& ~&wc zMhr7o%1v*1U72!A*?v!d$M60A37_Zr8k-ntX`?O*hY0No{fa;!ba!_P{_8)1|33lc zUkChpK}eJ@bX4>_tfGJwC3+g{+*3j6jFr4(nhUEe?24BV@tE$ZEMmX>-GFp{LQ1GN z_3Hi7^Dh20PA1r?BiH2JB_ZL%YAe)p?eha<$ OB?B=8J;mwg(ycJEyeQ&>agmM&j#IKS~lPzpSZeys&m9A0>|cM zyNb?^7=XMbLk)-M)(^k41_{3Yu`dI3%u=+VdNKMX$m&dZvf9E(zHSr{wvY1aqMt0b zEmza%8Z&w%n>!N%{Sx0Iu44q#(VCg7PrUu!q9O=0FJ%akwI0_-FG `LHPb=96LSoK;bROe@VDuHgdqi z_(Jf i7m^kp&_BoBT!YOMuVEXelEE8G BFQmO#G$ z>to@kbX@Bxw2U9?Fxg$*Q5K!x=g^_4hin8|=>a-{sZJYgMa7(|{KH2+ZgAAt%A5Tf zV?LW)wH(6cfZpzE^}sC=m71YHPhqx(HEz6`9WjUUw%%DAt89 M!tcsds;l0QE8LKeIC zfB=#hWpqkUPdAV*r3cOHIG`bAC$udak)FQDwBoAkz-tlNp_YKw;;%<^DoZ0oeOGQ< zNW8h5An;PAG-Te=jVt*IoFznemy+qNo1?+&ZL0h9>V=EXQdS4ZA*&mGW4|3N2R?ij zOySy+={qUg5)ljE@DSAos;ubuy_5Qb{2#bCrvyJC94o;=1n8xJ?=>|j5G3@9jU0ou zACmhPDQaGDNH$1==Er+3nNV;<5yld8wD#80&N&9{VM&A}D}Xd|_(DXz6#edJm*Kg` z4{LRtS;Iz0c~ituA_koWxR@7Z6c;Sfpndt9Dqj!o#Jfg+6MVrE_T~PZ2XahxeVyyi z?VNs1vTqC5_qz+fJnNs^Q2+kGIAGa~yciT%LPKyg7v+$rs}-TD#bQ>>8y5hmqwIh5 z&0-LYzw!unbd7}}QivOZS!D?AYOD+`*~pOlp~=1}Aq@kFed?1iX}JsR#U-Ah@&X?8 zbl&r~$;q9SDi>{r#*BpIY2?brZ_}p{Rk*BX$*WoQJ%7kmh0W=ZL*9- -Q{Mq78{mAy}>)iZH7I`_Ae_&Fypv;Dw{6zr~)mv$$)?MlgEa- z=tCERSoo&Ryl)9~z4{E6WRk^|9ezLk)^3)SUWR$jj5z@Me2*KsfhibPF413)vGxWB zP)4`VJwUNxA5)EIJ&Y2=9PQzRIt=mNC_)+#d=D3rhOxT~U)I?+PI4VhrnxDq58L-E zFO*Y{7hN@d }%WUeXL~s+$~MPxGi+zU|kfRw$N2uVx^djh1avJ4Qq64KiB7 zdf-Iuz`v}cQx!m6?@Jf9sD?*@5dCG-I`BJ&g<+Yb-$Xj9m}6~3Ep>KiuuHU+Vj_8E z4}B-ilU>!dTURq(M0AHc Zpx^hzxj8tlFZCj6|Uuy!PmAE zWg{$QrOFe$mEftItTeE?Hr0k{_}v>|>WUBGz5W8J7oR)bm-&$FvqsX2n;~kx`ul}< z`4!LJYf9L(c0b{(Zt@H#INtQNMGNkPzTT&45}u_fgPXqFe@?n>{H?G=uC>9>k74D~ zDb#QU5}os@c1TN|)lWkVj-z0tU92vilQP43batwO4WFe%OyszW%L4rD*QyN48UL!r pXMyi&`k#L_sQfRkv@UWvtU7nm9DS&7t1f7uI)7JhFj7cJ_kST@p}YV9 literal 0 HcmV?d00001 diff --git a/out/production/classes1/awt/doc-files/GridBagLayout-2.gif b/out/production/classes1/awt/doc-files/GridBagLayout-2.gif new file mode 100644 index 0000000000000000000000000000000000000000..c947c6c24f8d9d63ed340a2a67d8bb5d0cd2f30f GIT binary patch literal 2592 zcmeH`2R9oE13=@o_Fm6y%^ERUqo_VzR#a_`B0&`qyRF@NpAcfxTD1v@8I5S|(OQv^ zP}- lDh_qh z9*;01`9RmcVv9)y0Lz(6YgOWJzEaBsp3u+U4y_nRg9P^m3SOzct+Xz=m0lPM{D8JZ zakY`c>Zck#dQ*5U!yBdvP@EfUT{wf<5~SrL8mZH0-4?F)nR4~v#f7BDr!HNqPWb-5 zL f<~B3~8MZlf#HVwsL!O2)lF_+33k>P@ffci`V=VPBYCW+infaJV z?bLxzK`6ocK`!+N4C1r=m#MBjM+XP|)+n2vUx&x5CqB?y$5B%85 l&5a-g*oQHWL4L((SruVQUyJucxgBOLWDILf?`)l(fB;NREI0hx`Qu`nrL{O
JIbl`0~`3_Q#}uAaJ}-gH6_kM)m{luJAaMW0W@d$3wtxz`7{=# zHq{n#qaFjc=;kVepQH|Jw3wlf%Q{xzoxqo`d}y{$j?DIgdi$B&+mBv-s^9WFqrijj zJ4w{XC-TVrTJAsKDh_!I^G?efk`9J|2Su(*Y8NUvMZ-uKm#*yre)D2yFw21Y&ZzEG zzz)S=xnXBiiLtRWc7uKX@wkZ?ba&iL8MjMep)T)E+L~+peDCNK`18X(815$x5}|R~ z`f`HC-bb(ez`beTY9sp|l~%^yY(Nw5{#@u($vi218K=*j=i6fJFNo~(9xNhtlp>ds zlzV7PDZ&Yh)ojETk1uygR#A3i9THa}@*M^vm&HrSu ^!5-jRFr$%~ z_l@AbYk-Hw8NwLNUns{OIDIMQ qM9pq;PBcq-6ll$%;mzq z_0opD{G0sOj9Xoc8vQWUZJP(rlE;|G(J=ngUx6bwrzeQXj8o=?*|F2pEX4E#8|cj+ zlH0Kycgp_|d+`bz#Xtz8m7i4xz2$Pr^7n8kV!JG#%^STPFUuo0y*qV1k3}Ginf-!n z9oa6@Gm2CXkmEF`6U61I33;^@yqu_h(n<)58S4N&q`qpO8PN1jmqOEHA5=+E1#Gjp zONNE=uTVv`B9evCKj;dY$A8sA9OvX$*X~{%hilo~6R}V862&V5gYC}8o#QHt?DVi8 zyDcK*=GT&dbEdwJ60TP6hvce$ex{!0EA7}wHLjDL_@0iOn_r!&X 7PEy9VD+IlhB5UAuy_6km`rd^p3cI%;fSMenkozFnVMzKjrERH|-b z;D)Z3CZh`RwT+yb@gB=IU-^9Fp3x?pfaT(?Q zW9ki~Du$NCu zW;1E#CYg `0Yt=9t?X9Hwd?fXY_B3FeG);}(Yc_D*knJ|a5c$?I z-|yi3oVdp#zCW}wWiZDfHuYmOGkYzb!Wya;{@u=|V1i1ey3*E)k?6^vZNyLw2hn8k zkkCfkus59`A4YRTh&H{O$NI aa3b7 zf`qS)LL_vBst%D1|>WdHjolH!9LU@c(26U5@$$3jn|;52qR&9(62 z3kSa@!EaJDf!V>{RYq_|Zr2w@fBk;zO|_iLG*1O0E6LGq?)gsKH}xk$Bj#8^U*a9Q awoXW~&oxONKj#s;UgsetfR6(JxcUznqnvO6 literal 0 HcmV?d00001 diff --git a/out/production/classes1/awt/doc-files/GridBagLayout-baseline.png b/out/production/classes1/awt/doc-files/GridBagLayout-baseline.png new file mode 100644 index 0000000000000000000000000000000000000000..73c329ef9896e967d9b065adc8b95c871aa85bdd GIT binary patch literal 722 zcmeAS@N?(olHy`uVBq!ia0vp^TY=bwgAGWY* veWwy@IJW5dP`Ue&x43*z?q%UB$jZ*^g)K zT3T-J73h>}Se*Ra^VO9 N5iJyJ@ee})Pn#aj?hr^RIWWKMIR@(YyWt3*u z`m=BQ-*(S^{abJQybBWZG|W7*UjAdh@Adjy_}t|^zH_6)U*Gyxr!a$e67mXgG0h@UtJ401l*@9gF~S9MlB>r7Ko%ZU-9U@l2A5Xj?>rU?vB4#R7@02Iek@3 z7~#ak-;Q ZGa)lCZ1G$ RdpQZ;m^f>R>e3dq4a%mT-d>!(3GP{wrcDu=b)fHxims-rNu%sa z&!`};3?}QK$y=68xxiAkL@m=(b0Oy&4_>1>Mw3f?%QOuh?*gV(22WQ%mvv4FO#ll@ BPH_ML literal 0 HcmV?d00001 diff --git a/out/production/classes1/awt/doc-files/GridLayout-1.gif b/out/production/classes1/awt/doc-files/GridLayout-1.gif new file mode 100644 index 0000000000000000000000000000000000000000..e48d75f6478d845f48f49f57d73057df0baf5c96 GIT binary patch literal 1764 zcmd^;`#;oa6vsc`kx?qy(lo|(RU{ n%mYpt}Yc--W zJ7SixE>YjqMAl}a?V?y@%rHt9i=vv@nb+=rvFEqvoaemH`Fx(& zM~nG0CkIs1Sx~u9KBAU1R=8x*MZsUiWsB_QXzV&P_Z@OzQcG! z!m%GNU04b*L1~!g1ElC2==i9a%@m_S1PDRVS?Kc-3=%9U!O;gCL9svRbD63FTaD?5 zJ{>d% z-=*nc4GB8L*fI+BLY1L9eWz*SUVRqo*DyZ^+3@zx1Q7TfY@z5wE z2taE #26T1Pd}A6kH6V))k_D+B`~Ynrh(N=9 zO SO2In zCg9AuDJM|Am7D_FBr+~ix@JLVq1If80TDq61LQz6v`C2M5Z!^01YHiY;gB&j+i7@# z$X4574t)YfnsxrKVXG0Y`3sn;g!WWpukwqxj!&JlIH k!kY5m^(_;g+R#e_LKI(ie0s`&+p^fb#tjzRd~^Yjl{ zUPWnh(*~b%>`UnLGYso$4Ktm21`XVm uesKybL1DgY$sXmE==jJZmCK(DdB16V^3ea RZw zyBY1Cjqc+^9>2@SZG@CHFWSoQKa01kphTR@D{P2AW?NPhx5Ccjdj7e{fW95ow&jm> z=U(-GyX1~t$UBki>x-|8Y7g!HblY24I`B+TQmGWKUn-`m>i0Dyn$8%i5xJIbyLEi# zb%#49J6|5UeQHVO+eSubqr*)LPoI%1mN#Eo7aPo5Tp?JN(b6wj=@_^7zMIa>1;6d2 z9f)b4Vp2Bx!2gV5^iMxeyRnD7s)(^ik-=qSd3Nau(PF2b^M^aE@5?G$%qwlj8=3Xq zv6sVcR*i_GP6mB<$)TrAaj( 9@-L? v(_g4k&h2u8$u&<1uQ= zs tak+%~_ibyH>nN%1yW(}~>Ur^FY13aO^gcM2m=G__=t*oW zi83W+1Dz|CtQYp(tGd%|Oy7Ta8TRY9pJbK3Oyy91Pq$LXnV@mmiH;#Zr8c=ym8Hr0 VU54$sYroR9EK8vW>~I5C`~yt@kY4}* literal 0 HcmV?d00001 diff --git a/out/production/classes1/awt/doc-files/GridLayout-2.gif b/out/production/classes1/awt/doc-files/GridLayout-2.gif new file mode 100644 index 0000000000000000000000000000000000000000..24a2999519a740c9195d052416f0f0fcd9f162f2 GIT binary patch literal 1776 zcmd^;`&*1@7{|ZwJ33h%R*dPSNT{^YM0Fu8HesxkL#}d23?f2rD#>(^R9H)AQaX%7 z&30}o-rAj18%DcXJ6lxSG*fBEvXQjR?98?MU+n$c^L+37bKl?lxt=v^Jzd=bGmwt= z&_qI9LW`(HrBY!MFaZc7U mhz;AX$ ztO^7TLJD-K!AuoWVWG~^G>V40L`8#^L2iXUXOIC%?Z7=?s#+0&u7Fg4K5eLY8gTzH zyr#h(fa`NC1PMJ35T_F&`KW2^CPGsMAONXj!}$nP8kCesG6L8j9glDdwN>D$83Qn4 zfw>5oQq)TrKn# bl?9|QU?4(Cg-VTw#uh;U zj6sdtLmksJHkwH=Off_;k%WI&G6l#yhGk%>E3D0#& p3p53(H@pEYAV57gfhKE> zq jL)7a;)yEA3W19N+A0>0O_Q$Xv!7Ccx1Rcu;HEp-D8d{c z;F8oRCs4MPo&@FuQu4^>hS0HLOos@lAPB)`InV|M4Urrb%@ELF$w4 UCJbh=7@9od0nw(0JGU1?VcFrEBh0miK+UuCZM}TUoy7oY5?UOt12r4^mj{;OA{` zW+TpGRkHco =01se(s0_+wCZ_3$Hn)|5h?aNI9_uFw6FR2AS<=j*08_dG({i`>Y(~r-G3&g@* zisF*HCmnlerw?R|FuZJ6U7|JfYmUT0+G1r{8MYv6sJC5TE2ua!vU26)Tz #N|#3RPM5kbL~mgVashdO@?@qHMh-yP=rJd|Q<<>pj}6sPPv^sdxA@^E2uyxE^7 z*I$iF@AIW4M|MP<7<}Zf+_u5sbX|Cspfi5ZB<*ibN8yimnOIR3{mZ-My(_Mt8C8x~ zKVH*Ijcd8~o*6Uo%R5PqoimA>ux+!9HBPLxIz=XP1JAO!u6>DcipWct6`q+NpZ4XD z<$1kiVPB+uz2B@ A7sp9%p4X>MtaGiq z^yb}g6dw#qaV~b9f9>o#Pkw&PE4{Rg`F2qUQqQ~B+$y~AOm8SPu4U~3eonjIa3Qs| zT~d_(^7e4S4$tg6d}Y#BS (IEbIm$ylBeGt@fcdkEGg@}_}TU92eEcX zbF-Yf9E!%|DZ>r%`B8W3zI){#+z3WuX&^bTCba1#ogKPMpUrvQBvz(`@{LEfENWIV zqmSOO=zdrJ!;Gcoi&|`+P)-kQ{jZfbuX}d5^4qU^N=C)*F;%iB9*mHE9jj+p*kpOl zD}DPj$3?L{$9qjF_vz*vChRtCcGqA2j;Ep*x3eqny}30j=vsBl-Wv{YB&9L>CnR c5Q;VstlrGX2n^`V!Q$u3#TydGG!Kd$ z4uwrIQ9T^!%-5+k45=Or;QHC-9Tvjp(&Y#T-{0WK9x+-}Hm4#) =+xIV59c2+(B0j+Dht^X5#iswZzUbM9u0>< zDB|Gs=FRlq@ABpoD%l(xxHSyY`qjw Gz~KrHz2_0rz+l{P*g z0tlx~DRERis6adT5e;`pMg0By?BCzHD G8)ZAo|qW?C N8FN#r>^$=bv$C@_=;Jm|!{x%>1~ zUPQ9s@|0R6rYt}EvAO%*zt=<}abR3bG8~u_43Ae=92O*88a({4)we+#mp~4 ^mfLNG^9vS xVd359K`(9d?g(uASm=GG}PI}yx;4>^3~JS z;M3LZhBPUM9wn(YBj*PqhB!^CKOw3VA&Eavi7Y9%G$WTQC741|n>8q;KvaelBAFi} zm_a7|sl@!a(d_8Zd^a)lG8}wTH0=4>WK=Zl-oAV)G5n{l#QXJRVljMXT*f;Q((u*U zJQexx&e8DpEC2ui0Js4M0ssjA0M7^ (@D~J;-R&2Pj w26I VmIZ%g!5nVC~ts$pQe-@b($sxr2k pgy}Rn_nh|RMAGjU6`JLk#PNxoDV*2y&XO>^M{(Jk1_2cUo`MzO(`-nN$ z97X@_XCOueDm33^16t?Mf(J&3Q*91PXyHc?f@Iu)7bSS1g&ua~TZIp0_@RU*hBP9H z52kqHiyCq$AY(Ar7}Rm4*{I`#VTHIOYd&J-;*X{c$(4~rCaL6-Og7mSlEXP^8I(Or z`52W|TG<$uS!(I!O axnTh6_7O7d%5OBsR=bUubY3H4I-U&dSeD>+* zpMVA`=%9oaYUrGCx%uXyi~_o6qmV`_>7 v!lp&+NXZ^6Q?vR( z3#ORT!dGog%NlsCdE3fIt+8xnD^j=KdP%NwKb;$sxbdlbWV+xwTa&xe!5gQ%Hqk4b zzA0tM?sfd;7BEWN6>R0evmtDf!DsvnaJ* 8w#Boctcjbv+&T-}* zQ_gwcH~X~t=%l|?I7_Faj=1L>72dk*sVgTs?Ut8*(CRAPj(g-%gKqQhmFsSk@5Iw> zJVCq@oP6;uO^y8Xf=fqz=PNZI`t^{*ev#6%bFcjJE`=|C+RJM{()8z7pAypSw;wk7 zE5$Fr-6*L){QcPHFZ@RK g)-j{-&v zM231uv|>ccc*G)hafM=Zq8pQk88m89j$FhYc&?DV2rBV;ndxIll87KcO2&>=9Aid| zxJShN&W{eHBX}M;NHwCzkY{`z$!f;PM)Hw%kX$73Jc&Dr5wcB~JftQQiN{F(&XbM= zWl^RGOG Kt+ znqS)`>WYaUJ!&(VpOob-t9e05D)XD-jN=e6G|FItQ<>=$iVx8lwr~ +{_vx!aOnKGdYGN(bK+0cFx^qB4pW9%S`Es2IxpqzWC zFA3yP&+zi1t^+9|5jxVJ02G@l9Vjzf>YkDY(xJJ;XhqxiuTzq=od%7m7d7Itmy)uS zIZbIs54usBIt{3?Wav(}NzHZs)27uysyw|pRq^$dqcoxAQI|PWavGDX6ZP6KN5{>Y z>NKr99j8^1BGyKpw5)UeV?m?(PQHdTsi+ewPVt)0z3y?aa`lK&;Yv})4)v06b?o)N z>Qr1Ac9LXesad-TRlllrsej!nT0L7Q%aC=KjX1*<$(=2fqewWm}i+qYT&j+V5a z&Fn^e`cu_PmbGbfEjtZc&$U9YoVWFBS7mzI*Ge(6bp!7Fgsa%j9@e6wP3}$O+1waH zmu}K^8+EUGS(9=XD2vUiRtf9f(Sa6i;T78*o$Jcjniso(wQqd!=g-2v5sv*OuYUK- zU)$=Ew#Q9ud;eS8@d}v1t$i+pEmu_%PB^&p-QR`9OV H1)Ew)5M+H_YY^lneR##D>Cey&y>t5L1V6KikJY<+e4%BX6h&f2B8 zCS9HN2e^>-nt;L1ovnY}!(t0=aCl=jft-!LV+)De^MiKur2R##S)0UR^|r2o?QNYH zdM@W?Q@Z1_ZZx&~E$=2%yxTJGZ)sX!++Nzz@=Y{;>zir*PFleKosfF3#o*=|IAIVT zGKCL@;TXF&ZXhltikrpaO~N=?G`=K`i^bzf0y$Vj{v(om#pE&nbGTqoZX=dpN)9 zc~)e8BAQ>t=Br9Fc5rSXo>Rr=5dykYgsv@>2ZreTLHbja-Y%m9MpjUdy40sGsGL*% z>R8V@tgNo}u6zCKlj1tq$4>UL^GWPxPrKU5PVlz7{q1m%yWHna_qyBt?s(6;-uKS; zzWe>}fDgRj2T%CI8~*T!PrTw6&-lhW{_&8HyyPcO`N~`V@|e%O<~Psz&U^mzpbx$1 zM^F0Fn_fw^8u#gWrTWzm>te1a%*WQVAZ>H!_OX|Jd3H|_-uox_vM&h3U{5vR52p6G zCw_^HFBs&*-b}4${so1feCSIbFwXb=8n6GC>1hA?JmP-;UuHj_+S6V^;vawdp%eY} zqs#s9kH7rqPyhPc|Ni*Tzy9~n|Ni^`{{R?(0yuyKSbzq2fC!j?3b=p_*nkfBfDjmg z5;%brSb-LJff$&98n}TR*nuASfgl)yA~=F1Sb`>af+(1RD!76y*n%$jf-o3^GB|@Y zSc5irgE*LjI=F*8*n>X!gFqOBLO6s(ScFD+gh-f#O1Oj@(MU`f6R`AzE&)pcB84hJ zg;!vOS12PnqJ<{0A~fQKB>{%vA%-MDhE-^WBY}olsD^9Eg)-uX9zh{2B8L<~g?9Lc zPMC)xv4?!vhkp2nAMqMpD2O7`AaQ7j7(s_&sE8W>u_2A X*kIimRvcQUAY<9255oVJIOXa zi#cjGbeLPhYma#{l&LY72^x)=Yq}9@VzHUVHYKE1mJ{)55LB5yd73RTmvdxkUWt@; z##C8BY9p2stVu?WMmP>fn;$ltxoMkK$wIt|KCd}ygNB-|cAUUjhEOq_6qaUj`5<&w z70wx9Ul^P+hGtI*o3N#wBjaXch@JlbHJ#hJFyPso=c$Kjm}TiHWjfZL*%@co$($^< zWG4YM)%jQwW}jy$p8I)ZZx)+cR-XXMEJHbEQRbe*m7uLzpy1YFEq0Xexntu=p&%BY z3~H7{7NHQDVjClJ`m|hZbwb?9SsvP;L3W`is$V#!q4lLy>ZMy}rd_gyU)_bFzV%+` zrCB995uJ2hI|^jhWn3c~U>#asEy`YpHef`WV8}(I1SV2n8EHd`U{0!}8w#U#6{Js9 zUdY6y-; V&IjUTBs-KXhrH*B# z4Thz-*;$Q+TSaQ5FY2eV6{Sl5mZxPZOmKRpVv1rORj7|jRft+h)>T|03ScfpTpG1% z(Rr2&^;v+*r_NMTeRZj9+NFw$X*^n?-({)OlwDA|r&oGKu?4GlI;eX!TZS51w#uZq z+NxCQsJuEXm1?S|N nXicRuXhEn z#EP)&8moBfuAJJez1gl13tpymt)ta8;`*VphOK29UzIse0u`*=s<7#5sEn$j-C41g zO0w4Zteo?u%o?d-I;y1q>Zj3lulVYsntH1YyR!zXuVW>xl4`SNGphqDu@ft(iR!4) zdZ;javQG=Oy?UgOQ>-AXpeq}*Lrb+$%e7N`t_~}!9ICQg8?HcVrqilj);hK;nxbag zv~c^RDJEZ;`k!-qw_}>Obj!C@Yqb^{w{q*CcpJD(3%LBLwOLBIzG}FKi@0PKpktPy zjhncFTe$;Dq8#M7m >0Td`kk(OpZ=DgFN>h^ zDY>odowzHYsS9VMtGT{=XDTsgx7%jL`?{J#yQNl~Cjpw1g`8BQyrc P_I zd&!p{To-+5mn2-mCVavssFSUs!ac#lr{Tgo0mGpo!&-B{dPl=Jfy0}j!(?N_dB?-^ za=`Ke#56&~k72}c |^}WIVh=>?~(2zG4iMX-pSu>=$t?yHZ?tb1Y>3*pKh1$MML=*yzW7td4ms$n6No z<#-^}XvqBkNXUQ8j^~Ju>j=q@d ED)9K$(@YJ zkxa^|Ov#g+$)*gDmfR=#c*&f+%1yV*u3XEXtjdKP%d#Ahc{0ne{K~tG!p3~e$ehf| zyv)qp%+CDG&>YRuJk8Wx&DMO)*qqJUyv^L)&EEXY;2h54JkI1yf^I^X$^3oI?0ln0 zelOX3l4HRe=zZkz&dNt0rI>y7?4zcr&&jua`AmJ_=N_l%&-bhzsA$k!BF`R3&;P8> z2Eot`-7x0|&*c} oJ<=py(k6Y }*y*TU5yZ_)Ogk))+XsWKPG`4Uo&vf0sz@YDZ@BhG{ za7Zi~kI1BQ$!t2G!v+pYty-_xtai)QNg3U+cuX#vuiwRa&2GEj)pQO{uiNiuIeyRY z`;&Tqf`f#3frW^PieZO~j*pN^jggd 1vzrn |zaEP%vV@ zc}Bpg(HH)X;~aerdLUfKO=J#^7fpsNiPAwzl>LCLjESkC7nma@5rmmh;kTX&an6ia zGulw1WQ+#2X|E&5o7P;8<5^N3(~nniP6SX9kk6`7et=X;vuMhuIp6(M*|g@(vlq!C ztxC0Q+lEiy-rd?2S_Hec#LkmT_p4j5_twHaJeTgnvQgUx@rPIBU5s1ciBlZbFu%x% z88c4%kF(y>k3}OUjFhQZB9$Qz28@nk-Oh^ q?am&k}hn6f8 zzWV9pfn~Oybl=6+o`3ok=pBJNU3b}8-5Dp|c>o=h8-Ai0$jX2cIk?|z2o|MbT%g?( zm3>(?$J$^XRXE&A$sHx4gji7L;dlLo=v+BRF$l d6rFbF z+2odb_W2K 7^>Y$tR|buE}Ygo_-o< xsG_n-YN=?-VZ*Adw(9DuDc}I>thCl@>#MTfs_U-2_S%60z6LAou)-z)06SAbtIGfY literal 0 HcmV?d00001 diff --git a/out/production/classes1/awt/doc-files/LinearGradientPaint.png b/out/production/classes1/awt/doc-files/LinearGradientPaint.png new file mode 100644 index 0000000000000000000000000000000000000000..ef83194fe7ab82ae864f78b6694f2c90ae00de07 GIT binary patch literal 3347 zcmZ8kc{rQ-7B;<1M~dEBx?n6tD-Fg@w31O&rNLCj-r7m*OVm y|;% zV@*{t_inqmHQ0*Yj=%hGc>@FC+k7>u; xCxYSvA7 k{8;nm%v(7*xdNMF7?z0~!1wg@ zw70jXztoFdWD~V~WZJ(>b_T^MD=YW+_uJxzX?&7}?ixyYa2(8IHJyQKZ_&2{z{3KE zUcI>^@owpoH0{b#a%v!Niv8$~(S{U33GH+NbZ61ksi~>u6DX0Z&elI3Jb36|hzB)I z4^5IzO&*qp^>uV)2HSK=^~zJtk;stHP-fQB%;4aM4>5deuY((>nm?Tr3sOqVmH!HT z^PdjNU-IWB1?9%YhM{is)av!8KAoyUFM`LKfL=-^!*UnUeDEc9_q*O+hxEDxF-VbP z711|d(#PA|avFrI(=Ole^7i|N7 W#c7NP8B zAIrLA 4cy(WW5yCIh?%vYXW$WiRH8doXIVaML z$pVLI>FFhSnd5NqOtn;B4CWP5YfSf%uk?DQm}X0LHO$AlN&n !;Gv=9_<+Uud0wXQ2*L zfv?H9xv8tGW8ckGrv*?m0;*G@epvYgnV8A?g_=I#xUz;_VQZ{>My-sBtc=S|Or#u! zr%(GwY~Gysl)5yK7B-mid@%F*K&sAQy3Rmyr(>FpQ-+OWN|saRF{kunj>)XNELLtB zIydF6kXJxncl6`j)YEzCr*o4#ti8Na>ZQ_5q%)YF5z8(S ja6qxiLrz=(`x4 zOLS!@xOy_ApjpeS6tZ(1rU{p1Fg_W5sJ(-rfn{7|Jo3-+2hsAuI!Oi?EZU)SOj7TR zJA)X6xW)Eu0I^_tsPlHi_pYEpnS}B<@N8$Y7~^IL`F0s?Gfxjy5(|yIhc6Vgiw~NP z{@Fed@O5$MB&1$ _oVhG@fgL3EyhiIL85o>NFCgH8 z2~WXYF98bO>s}N_GJU;4xu%)eyF)h+>K2;rF(X_omx;oQ_dPTp{n;9$>K;R0E;)}% zClA@Fp$~F76{_bsD-i{bqP)&oI6%a+GUrGmTO{7Fy$?p9W(CSgSWWI6!v*gj28N($ z#=ko1Nwj d4Dn+v$m}wZicb2OJ0cDz+|IB}wlio=>pO}SjV% d4K$kD@lGxK z80cy?XTb6EXS*~S5DLuyDU$O=tc(~L{(EAJ%k!|jTn4@k(+jkyKLV|H+3h3~1&H?! z7gz4XFD@}GOa?h$$I6hAxF?s)opCG!zXv|@BLgb;J-b4`=xDMIU!xHT8@j70PZHie z*@6N^H*p3JGMjUWAuF00ATBdWT6@}3d7Xv*(Tty7X%vtT2$!Rms7+(9gbi{39Z4aE zNO|P(;$dxf1)M-hSjtVO;11iy_e+-O?(|nSikN-QtKj{Xm+<`wpPtb)#tA-`g>2EQ zFxzBLd_axuO%~e{gzz#{X1@=rc`Nhs1|SmP^$0v3lyMJRN7!CGF8;iqEKr|210{CU zc7RHa{no&?qIqxiN}07g)%xvl!@uV5ycYr9@%JN8n-^eR{I^Bri1PCzHcK)Jtb2Et z>A!!nB;&xk#9gKW?sRp@yG%uNreqpew``ZG)R!qq0P9xoGCdJsO6Gxen_?+OD?hVO z0NMwphHJKG02`wJeIfHZJ }*H=jK^u#A7(W{yG#c? d8_g%*X(eQhgDWUZQ{Y0!@Ho-jp>!wkp>0ZC?t{mbm( y!Y-2QQF);`a2l6xg-Cdlce>=vqo@ z- w0<;~vs2`us5@9PcttH|CqG|ntvZ^RN*DQd zI=6`yg2U}Sq3^yQ!k7dAYG5|W3(>yfyHfzsb*zh{sGn-LsA&gI$L I=9>%LtQPC~YB4M*)< nN_YP1)a{r#mx+H$Hh%c$4+PCpSBC&xc6dyU&5erAJLCTkF;Hqk literal 0 HcmV?d00001 diff --git a/out/production/classes1/awt/doc-files/List-1.gif b/out/production/classes1/awt/doc-files/List-1.gif new file mode 100644 index 0000000000000000000000000000000000000000..94b914685a844ff43424ff29d0b49304c22045a3 GIT binary patch literal 4193 zcmc(i`9IYA +R9>HZAKyRXdwx1Uo#zkdaeg?a<|aD2r>cQJm U405F-POjACR0BSVY|Fe-{s35*Ic2EZ67#vm{T#8?1hp%{z6SP nU05AcH2?$I8F$ge-VvxWf!~wtoiUR@%5GMhggyJLuCqbMHa59RM37iaZ zD!{2IP9< +B)LB0U+1t?!Y@CA?$0Ux4#Nbn*2uR4H2K>XVxBmqc5A&Gz_ z2+07FQAj2r8A2+6R1{JPNQICAAOnRA0x}?E0mwoji-0T$c>wZI$Ri*RLIHpR6bc9^ z_zwUf3L){I`+w4&)eS!ZFa-Ah$Nz5=KxiE_2uqtaUbz!5v_r-1eq(u8(l&XE60@d? zd#O7Sy$!dU*u5DfBc`-@Gp8>{*@19#$tFE0Q1|RFF%PMHP^1$wH&(Nx$WS52Z f1!g|0cDy-u)gRb3kCea&LEgI8lZgD0iL-w$2$yl%0#w$;z2$+h1# zt2n>@L_78jt9waNb8YavcR`F_@ZP=tDMhkbuhBEFhOnx$H+IRay NYwq>3ZGeNR23L=V|ngz&3Z6*G^X?OyEiwhv@_PfM|^tyG9>9%+4`5&p^vr~ z!X6%6@=LcCW5o>RNeEQ3>ylnathg7vj%dvC_PF$`{e3)P`e;)5rHzT&q@>|fg=4|e z?s*9j^OL>Q@O>3#q;QqEYE~RF9zjhT8!>y6w(!E|N^GKA&hY8IT0KuZd1+I-&URL6 z6$RQV_DKafaKA{Mxgl0i8RWPrqB5sCOnCB458A<@$x~2Ti1ZPqvb4psJIlNd+**}S z4Q)2Pl2l^XCZDM~;WQl^ULiD{`bi`5p=!<#32OQLk@oV$h1jXGxSb~Vl`e_Z3(28H zajvt>e1jQkShZB4G@9NTRS~r=JtE8~3!0Pg4v*P1H_Huv+W#hf%X+lW<#Vk*vT5H} z+Y}k5hMS~JJAWcgc~PF4pD6GSj2go{=_8{-)RQ-g3hMhdxwTmbi!8J}JDp!btNZyi z7TPqSr+QOnHAM!{Kb?~?oi$f2GgXf+WHT>Lr6_SkR7+}`M0iQ1aleIp*~})oQ)yw3 z?<%RsZD`Q;Gu;}j@am>QFpcOEF|;bL7In}otGdCYU%gx2dbmn+h~r-o(KMx7d-12= z>s)T8-r0Qn{B9AqtKG ij_P(qc zzII_$y)J%DD&&R1l&;U+aGTcZX7IJ;>~nDV8`bPj!2^2anQuxReQIhu_j9*5xE<=s zm(p2E*!c4MGRLuQ^uwcGim_Vn9oauaBcwIvCnoOlrcW(J1a9$JD)0JorknG~*S)#^ z(w0CknbHTX%>?eA=R3P}L+h1GbAVT?pjCC@^|Wh&K 0}q}wiycgs=AB#Z-`-9%U~_7AewDhJH|`eU2WONl)h zi+w%=J6x__#*ALC)H|%JKO3pBcSK$ZYoN0IE(=ul;qIf4;}yoFR}Z|nUh9?Nyx8 @YB^-C!w)FZlchg;0$%7`U=V_%TNroB+`xA(qQy(+GD!!FGn|v?YRXA FpCz+@6*6o%Fog`FawrcDdNTTwTMdRAc*Wf
(9nzB+>l^DH0qiI*t%#qSd z6*7K5a &qJ{XvT2Tz uG-$P9| zI_;^}ytq!-YLIz}u+l;Nkj*!%t*0a>+}4&o?ZRc7%O^#}?HkO@qYMw#6dSSDbg(D( zX@t>d{gFgjNx8&N+4e=LvPXaE*Wb1=Nc(r0xnE*iTR7YKdPc=#rk`I_Hx4vMP9K~3 zYee^+z}T+b?qS~0ZABY}rXHGw$_e_|V8d8@C?X@w*;ONI9YComQu%?={yO0hCaK=y z9KD@XAYmE&xmG^KcwMsJrpIwD^lBq*uZ%`)80F*24nK# <{ z9u1$?l~1pfieL7RxB3@!<<)b7Yj2Y3E#mnPY*r4hWX+DLhS0tZ^d^TMuL*Z-^ia4e zbkn;rEiRYr8gO-Z&h%NwkHqHOA0H$?YU>)bW?kg2_>Tv>wjGR}x-1kfe|BK+^Tli* z)4Vt3i*svgFYAYH%})lL>8Mh#Og~ddO5^PPrZR-}F+IfN4tT`u8jO8)Ao +Vntk>hjx)dr<@kvByPGFrG&ucLWz zx!Bn_KlSl%C2gD5J-&G)8~F)-?z-NG#YkrGO)gf>>fBPQmmX9MIiP4;pX7A%XvX&k zZ{=nk?kl&c<3qc~8+3H+Vt?MXS8Z&f?%f`mF!$~80*RU5lRBTgvVI#9-*#Q;nO;tm ztY#Liq*mre=dgDB3Y(>-v34v{tZX^-$BXEIUA9sE(LNpd8KvX9k4C*5`oS?S-BJ-F zq(36WRm(V@G;bgwWma)nuUbTQG2Xi^bhFHtN~iK!+QrD=U6o5uQWY{y*?J?eG%6fv z^43yPp@@Dkd{$dZtB?>*)nI+Q*?Mv*$f?tFYQP}9D?g?%OwTOv+SlAi_=nwn(Y*)Y zxpPiEiypkFiI3| DX{f`LW6?El zQk*w0A@-B8oy-coAT(gV)9ESgDDtxZF9!pj<@w(Vp;var$ZOD;Uo3X$*p#-a_Hpef zzv@>~{PsMtWP1DAUh})VH|EKZT*IaaujPNAf$Q;MYt4Hu&)&Mk zHYB=zJ)m2tb7AVl#W1u8iI-h*L^qhPO~|9+iJ?9kJFlViNLzWD^XST+gNW}&u|Pro zG4@12x>n%&D23*gOnY#aH2e#_qg(Eby?K~&+zG7|$FNuwRq9#3 WvcB-ok{MP+2GWP14= zdTtkOlQnCbO7<5GOg%NaAqblQON{*_=| z%e{8D3)8cl(|I$QqJ8Q4ccLPN qGK1TpE}nQ>fM`;B2PdS};{`z9MdC%7h)tA=w= z@60=nC-|ErZuC96V^VWGSq(8aXuFrFDVc9Dl3pxiyCcOr^|X(Y*JYziM%--&mm>95 z9FlXwllS=+$VH{SZY}uyQ>u1v@_BLF-0s-hEjiwOIq$wEqAyZTCYlN> gL6l$0ogh#9XE(KODo?WA+|dEMj|^T39v zY?T_{(c$cy%7ywho=N8URW3zL-I6_y_D5^1(mSlQyzp^_%&YAg{;hbSZr(Fr?F;+P z)vu#wM@EY8=oSflOMcfab98X)>$ANXe9S|%STU-gZMJMqm=!HaGtQ40#V_$zPkIWM zRhyS_QwrC0_mgK+-m$4C3h~FQxkEMhi;gS8QoAU9#qxW7_KBB)PS!+9xdgG kn+wv{W#&Vpk^aBM6pE!Q|U$~Gx&%0s~Bd(-B_D%?|@ zY+BLIlbg97dR$*R*WZ Fl*9XYw)$|(*BxaI;WgoV`o8RcXAf1FA}5C V22DggJ+y9(Xx2M3v~3&E{~yF9>CXTF literal 0 HcmV?d00001 diff --git a/out/production/classes1/awt/doc-files/MenuBar-1.gif b/out/production/classes1/awt/doc-files/MenuBar-1.gif new file mode 100644 index 0000000000000000000000000000000000000000..af974f11b8d0793df1f14ee23b6911ef43f5fb3c GIT binary patch literal 2268 zcmV<22qX7LNk%w1VI2YM0HFW?0002Mz`+0i{{R30A^8LW00062EC2ui038AA00091 zgpaAq?GK}zwAzca-n{z{hT=$;=82~2%BsQ($MQ_q_KoNI&iDQg3<`(D*P@6_DwoWr z^O-zCr_`$TibYCafv)!p4vWX+viXcotJmzd`wfq~8!@^4j?e4&{QjN}<0m*sSZH{d z2grrU*y#8O8K)@lm1U_DnW `vh8ewN%NHQoLj@&0QbcKvqCb=CSWZmfQWr{qFFA%(Gty-^o-tF_tT~Zn(vCEZ zdW0vlrPG2ZB`!62ljqT=Ki>qU36rS2t*pdiWqS6e)21;$&QwcvrPY)TRc>Y5726hX zysRnJsk2>Kq;%0<&AKyc;4={ib1nS#aN)))73WR!RWd)yPaT_;{L!t{v7(ha## feYrThGcan)RV!ccS+RzWQEI `6&|{ zH;)83)_??x#~&pB)$*Qz3I ce4&(sa{8i42Gs5{V|R7$S-b z?uQDCGDhg)hz!c2N{%`{(P1|`{s`m{J>J+?kVYPv1C1#XNgk3;K52xK7WoKel|Z%# zqId{c$>okSehER8Tgp(QjbNTBg#t5_`3#zFCeUAz%CVV?O+&&d#+r1B#2$u6 2=sh8W@%v8tQ1E(8x6^r|x;0C7z)o znyF@{Nv3t>dC#|kh6~=fa%O8QsnY%RUA?@ lLC=&dd!I #9^X#3+x+8J0ueJj5WgR#B@hBnZ zH8R2_JBV+)`o0_I%9@ K zDo#)RCe+I|_%kgVk27-CT1$!SmWO(s(1R#P9W&YgfITJJYJ<$Sg>JuXa@?O@jU(N4 zn_ctVde3Zks$#GDH#331(={>~%W=5KjdSg{B*G#7!|B%IB+mHccJR&U dX2K7E{Ap868M{n}Gy&9Kn+$ls>CF!j2oxIm?$$l5iK2myd!XRX=e@d-t#z=A zVBQM1HVYySbRYzp2suW=5;Bm2d{W^5RLBh$4l0E(CjR-a zOGE?(4|(T7m=$q}Ryg7`Os7M7+)z ^qu1H_(na#@fLQp!CXF5DpTz-fqk4) z4b}q^#;vh@bxh$S=b|ZLNotW7vE(c`QW~uk@KkIW 9rbS zdW$gNGG*Bsxxn5qWnlw^i&nZRO+F^`gKq@nxiBW5#;nVmuCSxC+-W;_o V<(*EM-#fGYbn(UP5?-cqXfLe4?82zU~{kYLTQuLr9 zZRbcqT2febbcPH~>8MtU! zaRRqG)P;w%t~ 4SU~XB92j1$5SGwDzPBUlQoZ=3qea9^=u*m0Kq7oJ}B>4^g zPHPj}rU#ax%%5Zv`qoVfR;3Z{<|(-v-!kEqrWpPxS)a;Rvt}5?xD>I6lM3PhOLf2` zZmx+Tn#vZtwZky>rHo4q-xIeNh&-0jTYC&-6V)`xL~g-JZ;Ug8Az5ZhUUJEr>|{aq zF3KN+GL @mI@cMkHLsr-=U>wj z*TUwluZ!JlStEPZ%3gM?`Rwdl?>gGwJT|ojJnd_f0@T{Zwza!m&tQYw+sz)gvCD04 qazi`am;E-o0Y~h2=d8%|uD8AKjqiNxd*A%-x4-`l@PJpK002AneSoU~ literal 0 HcmV?d00001 diff --git a/out/production/classes1/awt/doc-files/Modality.html b/out/production/classes1/awt/doc-files/Modality.html new file mode 100644 index 0000000..19695f0 --- /dev/null +++ b/out/production/classes1/awt/doc-files/Modality.html @@ -0,0 +1,471 @@ + + + + + + + + + The AWT Modality + + + + + +The AWT Modality
+ ++ This document, together with the API documentation for modality-related + classes (such as
java.awt.Dialog
), briefly describes the new + modality features and how to use them. It contains the following sections: ++
+ + +- Definitions
+- Modality types
+- Show/hide blocking
+- Modal exclusion
+- Related AWT features
+- Security
+- Platform support
+- Compatibility
+- Examples
+Definitions
+ ++ Document - a window without an owner that, together with + all its child hierarchy, may be operated on as a single self-contained + document. + Every window belongs to some document — its root can be found as + the closest ancestor window without an owner. +
+ + Modal blocked window - a window, that: +
+
+- doesn't receive any user input events +
- doesn't receive input focus +
- keeps its Z-order below the modal dialog that blocks it +
++
+ Warning! Some window managers allow users to change the window + Z-order in an arbitrary way — in that case the last requirement + may not be met. +
++ Modal dialog - a dialog that blocks some windows while it is + visible. The blocked windows are determined according to the dialog's + scope of blocking. +
+ Modal excluded window - a window that stays unblocked + while the modal dialog is visible. If a window is modal excluded + then all its owned windows and child components are also excluded. +
+ Scope of blocking (SB) - the set of windows (instances of +
java.awt.Window
and all derived classes) that are blocked by + the modal dialog while it is visible. ++
+ + +
+ Note: Everywhere in this document the notion of "window" is equal + to a top-level window in the Java programming language — in other words + an instance ofjava.awt.Window
or any descendant class. +Modality types
+ ++ There are four supported modality types : +
+
+ A dialog is, by default, modeless. A modal dialog is, by default, + application-modal. +- toolkit +
- application +
- document +
- modeless +
+
+
+- Modeless dialogs
+ A modeless dialog doesn't block any windows while visible. +- Document-modal dialogs
+ A document-modal dialog blocks all windows from the same + document except those from its child hierarchy. The document root + is determined as the closest ancestor window without an + owner. +- Application-modal dialogs
+ An application-modal dialog blocks all windows from the same + application except for those from its child hierarchy. + If there are several applets launched in a browser, they can be + treated either as separate applications or a single application. + This behavior is implementation-dependent. +- Toolkit-modal dialogs
+ A toolkit-modal dialog blocks all windows that run in the same + toolkit except those from its child hierarchy. If there + are several applets launched all of them run with the same toolkit, + so a toolkit-modal dialog shown from an applet may affect other + applets and all windows of the browser instance which embeds the + Java runtime environment for this toolkit. + See the security section below. ++ Modality priority is arranged by the strength of blocking: modeless, + document-modal, application-modal and toolkit-modal. This arrangement + is used when determining what dialog should remain unblocked if two + are visible and block each other. It naturally reflects the nesting + of a dialog's scope of blocking (SB): a modeless dialog has an empty SB, + a document-modal dialog's SB is complete in some applications, + and all the applications are run in one toolkit.
+ Notes about owners: +
+
+- Creating a document-modal dialog without an owner:
+ SinceDialog
is a class derived from +Window
, aDialog
instance automatically + becomes the root of the document if it has no owner. Thus, if + such a dialog is document-modal, its scope of blocking is empty + and it behaves the same way as a modeless dialog. +- Creating an application-modal or toolkit-modal dialog with an + owner:
+ The scope of blocking for an application- or toolkit-modal + dialog, as opposed to a document-modal dialog, doesn't depend on + its owner. Thus, in this case the only thing that the owner + affects is the Z-order: the dialog always stays on top of its owner. ++
+ + +
+ Implementation note: Changing the modality type for a visible + dialog may have no effect until it is hidden and then shown again. +Show/hide blocking
+ ++ Showing the window or modeless dialog: "F"
+ All the visible modal dialogs are looked through — if F is from the SB + of one of them, it becomes blocked by it. If there are several such + dialogs, the first shown is used. If no such dialogs exist, F remains + unblocked. ++ Showing the modal dialog: "M"
+ When modal dialog M is shown, all the visible windows fall into one of + three distinct groups: ++
+- Blockers of M (modal dialogs that block M and + either are in M's child hierarchy, or are not blocked by M, or have + a greater mode of modality, or block some other blocker of M) +
- Blocked by M (windows from M's SB that are not blockers and are + not in child hierarchy of any blocker) +
- All other windows (windows or modeless + dialogs outside M's SB and modal dialogs outside M's SB that do not + block M). +
+ After the modal dialog M is shown, it becomes blocked by the first shown + dialog from the first group (if there are any), all the windows from the + second one become blocked by M, and all the windows from the third group + remain untouched. +
+ In typical cases, when no child dialogs are shown before their owners, + this rule can be simplified. (The following, simplified case, may + leave out some details). +
+ Showing the document-modal dialog: "M"
+ All the visible application- and toolkit-modal dialogs are looked + through — if M is from the SB of one of them, + it becomes blocked by it. If there are several such dialogs, + the first shown is used. If no such dialogs exist, M remains unblocked. ++ Showing the application-modal dialog: "M"
+ All the visible toolkit-modal dialogs are looked through — + if M is from the SB of one of them, it becomes blocked by it. + If there are several such dialogs, the first shown is used. + If no such dialogs exist, M remains unblocked. ++ Showing the toolkit-modal dialog: "M"
+ M remains unblocked. ++ +
++
+ +The Standard Blocking Matrix ++ +current/shown +frame & modeless +document +application +toolkit ++ +- +- +- +- +- ++ +document +blocked +- +- +- ++ +application +blocked +blocked +- +- ++ +toolkit +blocked +blocked +blocked +- ++ After the modal dialog is shown, all the windows from its SB are blocked, + except those that block this modal dialog. +
+ Hiding the window or modeless dialog: "F"
+ If F was blocked by any modal dialog M, it becomes unblocked and is + removed from M's blocked windows list. ++ Hiding the modal dialog: "M"
+ If M was blocked by any other modal dialog, for example, "N", + it becomes unblocked and + is removed from N's blocked windows list. Then, all the windows and dialogs + blocked by M become unblocked, and after that the same checks + (as in Showing the modal dialog: "M") + are performed for each of them in the order they were initially shown. + + +Modal exclusion
+ ++ There are two modal exclusion types introduced as of JDK 6 +
+
+ By default, a window's modal exclusion property is turned off. +- Exclusion from blocking of toolkit-modal dialogs +
- Exclusion from blocking of application-modal dialogs +
+
+
+- Application-modal exclusion
+ If a window is application-modal excluded, it is not blocked by any + application-modal dialogs. Also, it is not blocked by document-modal + dialogs from outside of its child hierarchy. +- Toolkit-modal exclusion
+ If a window is toolkit-modal excluded, it is not blocked + by any application- or toolkit-modal dialogs. Also, it is not + blocked by document-modal dialogs from outside of their child hierarchy. ++
++ + +
+ Implementation note: Changing the modal exclusion type for a visible window + may have no effect until it is hidden and then shown again. +Related AWT features
+ ++ Always-On-Top
+
+ When a modal dialog that is not always-on-top blocks an always-on-top window, + their relative Z-order is unspecified and platform-dependent. ++ The
+toFront()
andtoBack()
methods
+ A modal dialog should always be above all its blocked windows. Thus, if a blocked + window is brought to the front, its blocking dialog, if any, is also brought to the + front and remains above the blocked window. Likewise, if a modal dialog is sent to + the back, all of its blocked windows are sent to the back to keep them below the + blocking dialog. ++ Minimizing, maximizing and closing blocked windows
+
+ When a modal dialog blocks a window, the user may not be able to maximize or + minimize the blocked window— however, the actual behavior is unspecified + and platform-dependent. In any case, the user can't close the blocked window + interactively— but it can be closed programmatically by calling the +setVisible(false)
ordispose()
methods on the blocked + window. ++ Blocked windows activations
+
+ When the user selects a blocked window, it may be brought to the front, along + with the blocking modal dialog which would then become the active window— + however, the actual behavior is unspecified and platform-dependent. ++ Hiding a modal dialog
+ When the modal dialog that currently has focus is hidden, it is unspecified + and platform-dependent, which other window will become the active window. + Any of the following may become the active window: ++
+ If the modal dialog to be hidden does not have focus, the active window remains + unchanged. + + +- The owner of the modal dialog - if the owner is unblocked. +
- The
Window
, which was active before this modal dialog gained + focus - if the owner of the modal dialog is absent or is blocked. +Security
+ ++ A special
AWTPermission
,"toolkitModality"
, + is required to show toolkit-modal + dialogs. This would prevent, for example, blocking a browser or + Java Web Start (JWS) by modal dialogs shown from applets. ++ The same permission is required to exclude a window from toolkit modality. + This would prevent, for example, a dialog shown from an applet not to be + blocked by a browser's or JWS's modal dialog. + + +
Platform support
+ ++ Two
java.awt.Toolkit
methods allow you to check whether + the current platform supports specific modality features: ++
+ + +- +
isModalityTypeSupported(modalityType)
+ Returns whether the specified modality type is supported on + the current platform. + If mode "M" is not supported and a dialog is set to M-modal, + it behaves as modeless. +isModalExclusionTypeSupported(modalExclusionType)
+ Returns whether the given modal exclusion type is supported on + the current platform. If exclusion type "E" is not supported + and a window is marked as E-excluded, this has no effect. +Compatibility
+ ++ The default modality type is application-modal. It is used by the API + calls:
Dialog.setModal(true)
, +Dialog(owner, true)
, etc. Prior to JDK 6 + the default type was toolkit-modal, + but the only distinction between application- and toolkit-modality is for + applets and applications launched from Java Web Start. + + +Examples
+ ++
+ + diff --git a/out/production/classes1/awt/doc-files/MultiScreen.gif b/out/production/classes1/awt/doc-files/MultiScreen.gif new file mode 100644 index 0000000000000000000000000000000000000000..ff85859453fcbaa2564ddcf6ebc3c9d2fe2b7215 GIT binary patch literal 3131 zcmV-B48-$CNk%v~VUz(F0g(Uz|Ns90006(gzW@LLEC2ui0F(h30RRI3gpaAq?GK}z zwAzca-n{z{hT?bx=82~2%C_zc$MQ_q_Dkma&R4d73krwCqVX8$DVNM#()nyk5z%QU zAjoRBT!G074vQ02(Ra)&qkY}B_PmbENoo*$?!>d*?YsUDI8pcEH)wD|+ ++ ++
+- Frame "F" is shown
+- Document-modal dialog "Di" is shown
+- F becomes blocked by Di — it's in the same document
+- Document-modal dialog "Dii" is shown
+- Di becomes blocked by Dii — it's in the + same document
+
++ ++
++ ++ ++
+- Frame "F" is shown
+- Document-modal dialog "Di" is shown
+- F becomes blocked by Di — it's in the same document
+- Document-modal dialog "Dii" is shown
+- Di becomes blocked by Dii — + it's in the same document
+- Di is hidden
+- F becomes blocked by Dii — it's in the same document
+
++ ++
++ ++ ++
+- Frame "F" is shown
+- Toolkit-modal dialog "Di" is created, but not shown
+- Document-modal dialog "Dii" is shown
+- F becomes blocked by Dii — it's in the same document
+- Application-modal dialog "Diii" is shown
+- Dii becomes blocked by Diii — + it's in the same application
+- Di is shown
+- Di becomes blocked by Dii — it's its owner
+- Diii remains unblocked — it blocks Dii and + Dii blocks Di
+
++ ++
++ ++ ++
+- Frame "F" is shown
+- Toolkit-modal dialog "Di" is created, but not shown
+- Document-modal dialog "Dii" is shown
+- F becomes blocked by Dii — it's in the same document
+- Application-modal dialog "Diii" is shown
+- Dii becomes blocked by Diii — it's in the + same application
+- Di is shown
+- Diii becomes blocked by Di — Di + is not blocked
+- Di remains unblocked
+
++ ++
+zHhE34p(hsC<( z3Tr$Eyoj3$x4fu(y331^EGImiReZcXRvqd5+bit@J&o(_y>^YQ&Fwyw4$ 8`tpNx?$}KTBM_6UM+F|44*li2GZZZiL5GK zJV_{HLVPSCK48>|7Bzw-E15)zlatDFIy3f^7% HDBQP7oVqa!_bgq!7U}k|Ybmeb zjZg&p &T}!d`z$(`T(qc1B<7+y zb>G!`O;c HhuQUAq&|PO-K)c z#F0G Qy5?nk7T$)TAnEzGWKnU70v~!)-HB(3 %0 zXqT7Gc^snD _DQA)@cB-nQK3Zy+ zt$vj%t+7rz>uj$wxhia!<~mEQC;ci&pTNeoE2o72YI-b9!d^sdB*r$ojgGJ`dm**R zD!LuEbZYC4wY=WSD!AN;t8BQ_n%mg3x_a9vyT_m_D!ib|YYe@plIttJ`MO(Bv{S9? zuXq4E%P(*RzoM_J_L{ozi3g9=tHKd0nQXo47JBiUYAyP(tQ~7I@wOW?JF*@P+Zr;i zDI-&IxD`Y9vT7Oc+j6-zlgKTI4xgOu&N)seu#+=GDfG~<7ClqKG$)OQwM+-=G}2Ia zLv*_55`1-gS!=vC$6bdZwbs>gJ@%JNn>{buY5Uo8kvIeW?c4CElw#g`@6ERn47gyo zb6-o0C|^@kT6VjI`*OIWi4zW};irCRWaTgaaqu|C5ngg5XN*rSx6gkXG`Qv)TK-Yv z@_Y_Di#BG-W{eTR`8UHHB9;1AtcQAzfk$RJQ083rp2|mk?Y=4T#8*xv)o~+f@b84V zNfYwPGYGqV1(LqD;z@S6W%aXPPp0%*qVCc2xZC{w^f=~g{q?uA2t4Mc4{v-``HP=^ z>pwPwCVKE9c=sb2L-LWP@CGAFnW;#Vd2>KK+zenhc>*^7igqB z0V?q)K@6S8u=7IsZSQnaq9XTXI6 =At+5*$vf(%lqNhSDjn&>Ax83$AIyg; zA~KVQy5+@k3CUf)vVZ&t-~bOe4`XIgHo&~(7Ke$-Kbiwg#&l5lj7Ufz3bU27Xd{)b z)V>>XQkPKt WWdkz$u6ve1L1-i|Ay0V}W-6JbSI@02e zGnh{5TM(|mI2}&UqM;nkN40pxRT{*cz4VC-Z>rOrc66r?EnYI0Hzr1=sZG^Xs*EBC z%bJ4JjW}&-QU7+JD$4VVr)yAzxGGJiWpt`B460RWszEERaef*MQY@2rJ~(EOlAUzm zP&vWVeWKHM8p22Oo(e_--Ka+IyK7VxdeJLr^sF2eWA*~uJUbT2t>E0JT FIDY=4$#q@=1TfJ 4)DYuMiARw>JEY)^^%OQ1# IRjwdh3q$cjRI%k%&U?XoO8J_Xy%ROmd99n$?*2EHEah%{y>?&p=2yM* zCGR8myE^=WQor_fFo7ZbK?!S;!nze)eLI|B00+3g-E?kU^_g4*4;ZB*zOX1wOilxn zSWYXxZi^rM;t!M6t^&qLh~If*7sC|B1?KUA(@ s5ZZw)bjO9B|TEP>xG@Kh5XgiSE z#$0x^GJgA8QK~4>RUz~R9dnnhctO^*ehPJ2%|=QWS|zbAORawmn_I70(VX5eulpeD zCjt8|!agpWi|yuPw<6igUbbJxyk}B#8P>@5b+vzeZ8;-E*RPf~Y^eS1T8A6gWN>u@ zxjk)fr#sor-tM#MoKkq7Ti)}QOug6JWPFcQ-^4(7zx|CjRL@}4TP`)h-(c{Av!kK{ zPcIaDEg6X;9G}`Yv$+e-Z;ji8;!583#~~haku&?G9q;qWvk`HXubkrzH~Gc8opG6u zoaHt5_|4=0opYVfe4{1zd6zJr8KK*n=h(IR(Q%%1rS}2Tm%Vq _|)X%QjaYLKYSqJ&nxt 34!m@5zn3uPpM7}j%x zVSyL;X)Omb9QaS8S0Nx6f*#l{B ^PlM2JR4Sb#`aghCiFOxT1r2sTi-85D?iR7e?C7 *+W1+(~JD% zO)qkax 6A|i Vl~E~`Q%RLoX_Z%rl`UBS06S0o6F2|> literal 0 HcmV?d00001 diff --git a/out/production/classes1/awt/doc-files/RadialGradientPaint-1.png b/out/production/classes1/awt/doc-files/RadialGradientPaint-1.png new file mode 100644 index 0000000000000000000000000000000000000000..8003b3a24fab3831753d3b9a44a74d4731aa5931 GIT binary patch literal 21911 zcmZ_01yodR*FLTyp|mv8NSCz4&`3#l3rKf~GYBXt4NAw*T~gAZAR$AiwB*n|ApJjs zKF{~Q-~aoqbr!Ogdd|7;eeb=meeG+XP&E}f?1$tJ@7%eAtspO>ap%rmH{f@FjC;V( zv7E7^J9o5A6l5f|-c0YzVa~!WlEq!DMcA}n;nA^$=v3v($BpObni+<8M${TU{&L+{ zoNqiMyz|6OrRa%zoKAa~fq9X-fr6V|3?pwOH~MJA=;2jc1^m3xZvlQPdV~dqC!a;O zwoMK$i=3XeR&2Q&w_UXEZZ$?LY3~$V)nuITW@qFX5COl8`WjS^_)e={*!C-4*oyBI z@U#8-7o#chz+X-eKC;nCFt95+8WeA1%M&&AL5!z5x1JrsxY|024UN3!JTdbGY)5kI z+OBpix+2bc k{Ohv zGPKh4V-+vvp %SUP(HtT2pn4CY| zU>qdHX+9@Y);CwDr>A*ZvT{F5XFW!hl~IYt<(v20F_q52@btR9)(ad-MPG2QI5lKF zOBzS$Ne0u4B$u^hYsmiOk>Y$Wr8tHt-IJSo78w(K2e)*i4rBGt <#6dSTm(YgmYP>F$e_Y)m*16s8 zY(s_L)mB4Js#9YTJZR0&)|<^XM<_JMQ73q4pE{uKPzuq9mJYl FC^4_lOj$_e; z-u&zhAMG1z>romnZMFfy+JMbo@SHT3hLc=>h##>6JN5Uf5rt!mEq$PGY$h7E{qe({ zY}!yCI4I#v8ev#j$FzrSfi3YR<&BER^Mr4Yo8w8&!<*xp srFLqOP8tNZQN0(8&`So7edgaTE(~M0{Wbp6w;GUZi9RJ4WMb8II zn} Ms<%MD^GwgG47^*k7UIGFx=TETBNB|ghT&~cjYy^TV{a+Jt~iT4h$SwE`V zpyM!F`8nT C2imn2Rfq{QKmW6%YRQbVK5OE05f0{? zOtT%l%7aI`bHK@ z#%`Ta9Au%RL$N)|+5&j%MCq-gPOIAMARSe_Odsi}SC^GZ@p%b$ZG)#GX@jW?MlDx6 z<4p_3JC$;^d#&ROSH_+{&BoQ`v~Lc%#t*u6nKF#hJ#`RyT-v4=28c3e?S(5R&z;(F zY(cG0jM_IBZR6=)I&IgUh#~3m8r$){ |LrQ*^!NTx|Th=*vRud3al)z*Me*-<4fIe~E5u6=VulEPnRMu3@# r=B_aC zPuaesvI$VJ3HG%q8h78@YT#!BndwxO-ylqNFLp@Ub{9i*Z!QPN+pg_BmqN#_#SMLS z-N(UjZPObFBI8Ei*i##^a6{?2Q6OICdl0?}^)5!IF3nddqw=Xq5jkxLD>nc$Ep(FT zT4xwjdOM7D2H+IWpSId{Q N1c_DZzHfF)Ik2PXsIo)ET zBAzgC75z{_IhJ_rA;o(vt)x^49knU_EcG)|{AyI*0`ykbq~Ur^JkOggI?eWVf()q6 zDvzm8v1luV%7D^U=CZ4sLi4KIPbTB|Y*4N)ckL})Wc;*M*VxYou}rO7H>Y#8sXM;% zV?2&!SiL`46LcVh*sj**_kn29QH} 9wbORQstPcaHkA&%Iy&B=uupE$&1HQ~m5FMYwKB1`x^;liv?p7Z)& z45?N19d{mxswrpS(54NwV+md6(qM-6$O`j(jBCzi6u}-saU6Qk|0>ed|G0U(YCMcB zIQb=)jxm4ffnAAq1w=dPL#0IrrCD~WDa%MpyqwBeyaq9 2>UcXp}DNW61jrUu; zUn#xj^5@h4bE!e}t@Rx=yrOE~&=$9+ZkIZh{_%rRu994Ob8Z)fDkL-VRT6(|H=>j= zPA!;G58cZD#~VaR2l@WVx <`y7b^Hqook6AWiPGah z{U6WT^e0utTZB(%H~lf`NL!b}Hqpf~m`)}POH8kM%-0sK1%$J^skV-~G9bl}U+>?P zr4-Uo-@MV{$*TWtneLfQ?v^#K#^G0xp8a?UvY#Q;nsMz>KV*8QSP %_LlF z==7jXs12GYfBNOv<3EjgyF#Qfzo7xP6hjcM?0@oSe?mvH(fou3tf2gwJTt^9vLFvS z&g)E9_F$`b?iWPfx8J^avQ=QalQC6>;tcL*5|U)pg2i1oU5q@%) qYj6>$Yd-dU2?HNQG&q z>EM5DcQ9k``m#Ss)bAx6lqdTVsE-3(q%e;n$S`sgi66y=d%OY`YDp`C&1e6%>jqS4 ztr4bqpS`4lio