jdk-sandbox: comparison src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html

equal deleted inserted replaced

-:2e0c4b2d567b
+:1ba28f0dbc33
 <head>
 <meta charset="utf-8"/>
 <title>The AWT Focus Subsystem</title>
 </head>
 <!--
-Copyright (c) 2001, 2017, Oracle and/or its affiliates. All rights reserved.
+Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
 DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 This code is free software; you can redistribute it and/or modify it
 under the terms of the GNU General Public License version 2 only, as
 published by the Free Software Foundation.  Oracle designates this
 or visit www.oracle.com if you need additional information or have any
 questions.
 -->
 <body>
+<main role="main">
 <h1>The AWT Focus Subsystem</h1>
 <p>
 Prior to Java 2 Standard Edition, JDK 1.4, the AWT focus subsystem
 was inadequate. It suffered from major design and API problems,
 <li><a href=#ReplacingDefaultKeyboardFocusManager>Replacing DefaultKeyboardFocusManager</a>
 <li><a href=#Incompatibilities>Incompatibilities with Previous Releases</a>
 </ul>
 <a id="Overview"></a>
-<h3>Overview of KeyboardFocusManager</h3>
+<h2>Overview of KeyboardFocusManager</h2>
 <p>
 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.
 <code>KeyboardFocusManager</code> is an abstract class. AWT provides a default
 implementation in the <code>DefaultKeyboardFocusManager</code> class.
 <a id="BrowserContexts"></a>
-<h3>KeyboardFocusManager and Browser Contexts</h3>
+<h2>KeyboardFocusManager and Browser Contexts</h2>
 <p>
 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
 contexts there may be, however, there can never be more than one focus
 owner, focused Window, or active Window, per ClassLoader.
 <a id="KeyEventDispatcher"></a>
-<h3>KeyEventDispatcher and KeyEventPostProcessor</h3>
+<h2>KeyEventDispatcher and KeyEventPostProcessor</h2>
 <p>
 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
 Like KeyEventDispatcher, KeyboardFocusManager also implements
 KeyEventPostProcessor, and similar restrictions apply to its use in
 that capacity.
 <a id="FocusEventAndWindowEvent"></a>
-<h3>FocusEvent and WindowEvent</h3>
+<h2>FocusEvent and WindowEvent</h2>
 <p>
 The AWT defines the following six event types central to the focus
 model in two different <code>java.awt.event</code> classes:
 <ol>
 <li><code>WindowEvent.WINDOW_ACTIVATED</code>: 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.
 </ol>
 <a id="EventDelivery"></a>
-<h3>Event Delivery</h3>
+<h2>Event Delivery</h2>
 <p>
 If the focus is not in java application and the user clicks on a focusable
 child Component<b>a</b> of an inactive Frame <b>b</b>, the following events
 will be dispatched and handled in order:
 rejects the focus change. See <a href="#FocusAndVetoableChangeListener">Focus
 and VetoableChangeListener</a>.
 <a id="OppositeComponents"></a>
-<h3>Opposite Components and Windows</h3>
+<h2>Opposite Components and Windows</h2>
 <p>
 Each event includes information about the "opposite" Component or
 Window involved in the focus or activation change. For example, for a
 <code>FOCUS_GAINED</code> event, the opposite Component is the Component
 that lost focus. If the focus or activation change occurs with a native
 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.
 <a id="TemporaryFocusEvents"></a>
-<h3>Temporary FocusEvents</h3>
+<h2>Temporary FocusEvents</h2>
 <p>
 <code>FOCUS_GAINED</code> and <code>FOCUS_LOST</code> events are
 marked as either temporary or permanent.
 <p>
 Temporary <code>FOCUS_LOST</code> events are sent when a Component is
 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.
 <a id="FocusTraversal"></a>
-<h3>Focus Traversal</h3>
+<h2>Focus Traversal</h2>
 <p>
 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
 current focus owner. If the current focus owner is not a focus cycle
 root, then no focus traversal operation occurs.
 <a id="FocusTraversalPolicy"></a>
-<h3>FocusTraversalPolicy</h3>
+<h2>FocusTraversalPolicy</h2>
 <p>
 A <code>FocusTraversalPolicy</code> defines the order in which Components within
 a particular focus cycle root or focus traversal policy provider are
 traversed. Instances of <code>FocusTraversalPolicy</code> can be shared across
 <p>
 All other applications, including pure AWT applications, will use
 <code>DefaultFocusTraversalPolicy</code> by default.
 <a id="FocusTraversalPolicyProviders"></a>
-<h3>Focus Traversal Policy Providers</h3>
+<h2>Focus Traversal Policy Providers</h2>
 <p>
 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 <code>true</code> with the call to
 that provider is returned
 </ul>
 </ul>
 <a id="ProgrammaticTraversal"></a>
-<h3>Programmatic Traversal</h3>
+<h2>Programmatic Traversal</h2>
 <p>
 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
 and there is no other Component to focus, then the focus owner remains
 unchanged.
 <a id="Focusability"></a>
-<h3>Focusability</h3>
+<h2>Focusability</h2>
 <p>
 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
 default, all Components return true from this method. Client code can
 change this default by calling Component.setFocusable(boolean).
 <a id="FocusableWindows"></a>
-<h3>Focusable Windows</h3>
+<h2>Focusable Windows</h2>
 <p>
 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
 <a href=#RequestingFocus>Requesting Focus</a>), 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.
 <a id="RequestingFocus"></a>
-<h3>Requesting Focus</h3>
+<h2>Requesting Focus</h2>
 <p>
 A Component can request that it become the focus owner by calling
 <code>Component.requestFocus()</code>. This initiates a permanent
 focus transfer to the Component only if the Component is displayable,
 <code>requestFocusInWindow</code> that allow client code to specify
 a temporary state.
 See <a href="#TemporaryFocusEvents">Temporary FocusEvents</a>
 <a id="FocusAndPropertyChangeListener"></a>
-<h3>Focus and PropertyChangeListener</h3>
+<h2>Focus and PropertyChangeListener</h2>
 <p>
 Client code can listen to changes in context-wide focus state, or to
 changes in focus-related state in Components, via
 PropertyChangeListeners.
 <p>
 Window will never see a <code>PropertyChangeEvent</code> for the
 <code>focusCycleRoot</code> property.
 A Window is always a focus cycle root; this property cannot change.
 <p>
 <a id="FocusAndVetoableChangeListener"></a>
-<h3>Focus and VetoableChangeListener</h3>
+<h2>Focus and VetoableChangeListener</h2>
 <p>
 The <code>KeyboardFocusManager</code> also supports
 <code>VetoableChangeListener</code>s for the following properties:
 <ol>
 to anticipate this situation could lead to an infinite cycle of
 vetoed focus changes and recovery attempts.
 <a id="ZOrder"></a>
-<h3>Z-Order</h3>
+<h2>Z-Order</h2>
 <p>
 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
 manager. The window may be in a native application, or a Java
 application in another VM.
 </ul>
 <a id="ReplacingDefaultKeyboardFocusManager"></a>
-<h3>Replacing DefaultKeyboardFocusManager</h3>
+<h2>Replacing DefaultKeyboardFocusManager</h2>
 <p>
 <code>KeyboardFocusManager</code>s are pluggable at the browser context
 level. Client code can subclass <code>KeyboardFocusManager</code> or
 <code>DefaultKeyboardFocusManager</code> to modify the way that WindowEvents
 related to focus, FocusEvents, and KeyEvents are handled and
 implementation of the Window class may generate these spurious
 events.
 </ul>
 <a id="Incompatibilities"></a>
-<h3>Incompatibilities with Previous Releases</h3>
+<h2>Incompatibilities with Previous Releases</h2>
 <p><b>Cross-platform changes:</b>
 <ol>
 <li>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
 the top-most Window after the Z-order change.
 <li><code>requestFocus()</code> now allows cross-Window focus
 change requests in all cases. Previously, requests were granted
 for heavyweights, but denied for lightweights.
 </ol>
+</main>
 </body>
 </html>

changeset 50358	1ba28f0dbc33
parent 48264	efda6932a433
child 58595	fa9f28a0e175