 | |
JButtonNeed more control of highlighted character than
|
|
The bugtraq report that corresponds to this change is: 4287690.
Many developers have requested support for listeners to be notified when a combo box's drop down menu is popped up, dismissed, or canceled. Applications could use these listeners to lazily populate the combo box's model with items.
This feature wasn't provided in earlier versions of Swing because there was some, probably academic, concern about supporting a listener for a feature (the drop down menu) that some look and feel implementations might not provide. All of the look and feels that are shipped with Java and all of the ones we've come across do use a drop down menu to show all of the combo box items and some developers have resorted to non-portable hacks to get the menu state change notifications.
For the Java 2 SDK, Standard
Edition, v. 1.4 release we will add a PopupMenuListener
to JComboBox. So long as the underlying Look and Feel
supports an item menu, this listener can be used to perform actions
before and after the combo box menu appears.
See the related javadoc here.
Print-friendly VersionJComboBox needs prototype cell for listsThe bugtraq report that corresponds to this change is: 4231298.
JComboBox currently configures a renderer for every
item it will display. For large lists this can take quite a while.
Instead developers need the ability to specify a prototype that
all cells will match, so that the prototype is only checked once
instead of every cell.
See the related javadoc here.
JComboBox and related classes needs
better documentationThe bugtraq report that corresponds to this change is 4394300.
Currently, public API for JComboBox and its UI
delegates contains javadoc which describe the details of its implementation.
Refactoring and bug fixing over the course of its history has
made this javadoc out of date. The javadoc should be checked and
revised so that it describes the behavior of the method rather
than the implementation details. Also, some of the javadoc for
"protected" methods and fields which should really have been private
should be removed so that overriding or calling these methods
are not encouraged.
See the related javadoc here.
|
The bugtraq report that corresponds to this change is 4290709.
Although Swing's JFileChooser closely resembles
the Windows common file dialog under the Windows look and feel,
there are several deficiencies for which we have received complaints.
In particular, the Microsoft Windows aesthetics guide mentions
the following:
If you cannot use the [common] Open and Save As dialog boxes, you should incorporate the following features into your open and save dialog boxes to ensure that they are consistent with the shell, the Windows accessories, and other applications:
The first four points are not possible in Swing without additional API support from the AWT. The AWT common file dialog is also currently an unacceptable solution for the following reasons:
The new functionality is accomplished by adding public methods
to the FileSystemView class, providing file and directory
information beyond the scope of the File class. The default implementation
of these methods use the new ShellFolder classes
in AWT to obtain platform specific information.
The isTraversable method has been removed from
javax.swing.plaf.basic.BasicFileChooserUI$BasicFileView
so that the superclass's implementation will be used.
See the related javadoc here.
The bugtraq report that corresponds to this change is 4318785.
Look and Feels need the ability to specify the text, tooltip text, and mnemonic for the button used to open a directory in JFileChooser.
See the related javadoc here.
|
The bugtraq report that corresponds to this change is 4134077.
Previously, the title of an internal frame would not be clipped
if it was too short. This would lead to the title displaying over
parts of the icons, as well no visual feedback to the user that
the title had been clipped. To solve this, BasicInternalFrameTitlePane.getTitle
will be added.
See the related javadoc here.
JInternalFrame Titles in Windows Look and Feel
should be rendered with a gradientThe bugtraq report that corresponds to this change is: 4389209.
To implement this correctly, we need to create a class, com.sun.java.swing.plaf.windows.WindowsInternalFrameTitlePane,
which extends javax.swing.plaf.basic.BasicInternalFrameTitlePane,
but overrides the paint routine to render the gradient when appropriate.
The best way to get code-reuse is to break out the portion of
the paint method which paints just the background and override
just that in WindowsInternalFrameTitlePane. This
would add an additional method to javax.swing.plaf.basic.BasicInternalFrameTitlePane:
See the related javadoc here.
|
JEditorPaneThe bugtraq report that corresponds to this change is: 4252169.
In previous releases it was not possible for ImageView
(the View responsible for rendering images in a JEditorPane)
to show tooltip text because there was no way for a View to influence
the tooltip text that is displayed for a JTextComponent.
In release Java 2 SDK, Standard
Edition, v. 1.4, if the the JTextComponent doesn't
have a tooltip, then the view under the mouse will be asked to provide
one. If that View corresponds to an HTML element with an ALT attribute,
then the tooltip text will be the value of that attribute.
See the related javadoc here.
text.html.ImageView should be publicThe bugtraq report that corresponds to this change is: 4233811.
The package private class javax.swing.text.html.ImageView
is now public so that it can be extended.
See the related javadoc here.
elementOffset PropertyThe bugtraq report that corresponds to this change is: 4182124.
The HTML package exposes a way for developers to determine when
the mouse moves over a link via the HyperlinkEvent
and HyperlinkListener classes. Often times developers
need a way to extract information from the document when the HyperlinkListener
is notified. There is currently no way for a developer to determine
the position in the document a HyperlinkEvent represents.
To aid this the following API will be added. Note:
the first revision of this document had the methods returning an
int offset, they will now return an Element.
See the related javadoc here.
The bugtraq report that corresponds to this change is: 4241788.
The semantics of the HTML parser (javax.swing.text.html.parser.Parser)
have slightly changed to better match that of the browser (NS and
IE). While no API was changed, those using the parser may notice
a slight difference in the reporting of whitespace. Here is how
things have changed: if strict (an instance variable of javax.swing.text.html.parser.Parser)
== false (the default) an instance variable is used to try and mimic
the behavior of IE and NS.
The problematic scenarios are:
'<b>blah <i> <strike> foo'
which can be treated as:
'<b>blah <i><strike>foo'
as well as:
'<p><a href="xx"> <em>Using</em></a></p>'
which appears to be treated as:
'<p><a href="xx"><em>Using</em></a></p>'
When a tag that breaks flow, or trailing whitespace is encountered an instance variable is set to true. From then on, all whitespace will be ignored. The instance variable will be set back to false the first time a non whitespace character is encountered.
The bugtraq report that corresponds to this change is: 4200439.
The html support provided in the J2SE has never correctly supported
writing out form elements. This was due in large part to the way
that forms were modeled. To better match the DOM we have changed
the forms are modeled internally. Previously any attributes of a
form would be stored in the attributeSet of all of
the children character elements. In Java
2 SDK, Standard Edition, v. 1.4, an element will be created to represent
the form, better matching that of the HTML file itself. This allows
for better modeling of the form, as well as consistent writing of
the form.
This will affect developers that relied on forms being handled loosely. As an example, we would previously treat the following invalid HTML:
<table>
<form>
</table>
</form>
as:
<form>
<table>
</table>
</form>
With Java 2 SDK, Standard Edition, v. 1.4 we will instead treat it as:
<table>
<form>
</form>
</table>
DefaultPainter in javax.swing.text.DefaultHighlighter
now FinalThe bugtraq report that corresponds to this change is: 4328938.
Prior to release Java 2 SDK,
Standard Edition, v. 1.4, the static field DefaultPainter
of javax.swing.text.DefaultHighlighter is not final.
This is a potential security problem. For release Java
2 SDK, Standard Edition, v. 1.4, it is now Final.
See the related javadoc here.
PlainDocument(Content) should be protectedThe bugtraq report that corresponds to this change is: 4220001.
The PlainDocument(Content) constructor is protected.
This means that developers wishing to use the constructor have to
subclass. This constructor was intended to be public, and will be
made public for Java 2 SDK, Standard
Edition, v. 1.4.
JEditorPane.scrollToReference should be publicThe bugtraq report that corresponds to this change is: 4304676.
JEditorPane.scrollToReference is protected for no
good reason. This method is intended to be useful without having
to subclass, as such it will be made public in Java
2 SDK, Standard Edition, v. 1.4.
Document.getText should allow for partial returnsThe bugtraq report that corresponds to this change is: 4156650.
For efficiently accessing the content of a text document, Document
defines the method getText(int, int, Segment). Unfortunately
there is no way for the caller to determine if the receiver can
efficiently satisfy the request. For example, GapContent
can efficiently implement the request as long as the request doesn't
span the last edited spot of the document (the gap). To facilitate
efficient access of the content, the methods setPartialReturn
and isPartialReturn will be added to Segment.
The current semantics of Document.getText will still
hold, but for more efficent use callers should invoke segment.setPartialReturn(true)
and be prepared to get back a portion of the document at a time.
See the related javadoc here.
The bugtraq report that corresponds to this change is: 4303259.
Assistive technologies for people with disabilities require programmatic access to the contents of JEditorPane using the Accessibility API. Currently, the only access is to hypertext links. This API change provides accessibility to all HTML component using the Accessibility API.
javax.swing.text.html.HTMLEditorKit will now implement
javax.accessibility.Accessible.
See the related javadoc here.
|
showInputDialog methodsThe bugtraq report that corresponds to this change is: 4226644.
Prior to this addition, if programs wished to display a simple
input dialog containing a textfield with a default string, they
had to invoke the complex JOptionPane.showInputDialog
method which requires seven parameters. Two new methods showInputDialog
methods make it more convenient to create and display simple input
dialogs.
See the related javadoc here.
ComponentOrientationThe bugtraq report that corresponds to this change is: 4265463.
JOptionPane needs to support right-to-left layout.
This is a bug fix and no actual API is required, however, two
javadoc updates must be made.
See the related javadoc here.
|
JPopupMenu doesn't support key bindingsThe bugtraq report that corresponds to this change is: 4212563.
JPopupMenu doesn't support key bindings. The arrow
keys, mnemonics, the enter key, and escape do not work with a
JPopupMenu unless it is used as part of a compound
component (like JMenu and JComboBox).
This behavior can be traced to the fact that JPopupMenu
does not always gain focus, and can therefore not get KeyEvents.
It was previously not possible for light weight toolkits, such
as Swing, to request focus and indicate the focus change will
be temporary. The new focus architecture solved this problem,
and Swing can now request a temporary focus change. Fixing this
bug required making the JPopupMenu get focus so that
the key bindings can be processed. Consumers that had previously
not expected focus changes will have to update their code to check
the temporary property of the FocusEvents.
|
setUI, getUI MethodsThe bugtraq report that corresponds to this change is: 4226238.
The setUI/getUI methods were not implemented for
JPanel, even though its look and feel is defined by
pluggable look and feel (plaf). See javax.swing.plaf.basic.BasicPanelUI.java
for example.
See the related javadoc here.
|
indexAtLocation Method to JTabbedPaneThe bugtraq report that corresponds to this change is: 4241787.
Prior to this change, there was no way for client programs to
convert a coordinate location to a particular tab in a tabbedpane.
This made it difficult to implement special event handling on a
JTabbedPane (like popping up a menu over a tab).
See the related javadoc here.
The bugtraq report that corresponds to this change is: 4284674.
The panes of a JTabbedPane do not currently allow
for mnemonics. To facilitate this, the following API will be added.
See the related javadoc here.
JTabbedPane are inconsistent.The bugtraq report that corresponds to this change is: 4287053.
The JTabbedPane class is a container that has many
methods which take an integer index as a parameter. Unfortunately,
these methods are inconsistent with their approach to throwing
exceptions (some methods check/throw, some don't). Additionally,
the javadoc is currently in error - it states that an IllegalParameterException
is thrown when in fact an ArrayIndexOutOfBoundsException
is thrown (by the underlying Vector).
Any method which takes an index that must be in the valid range
from 0 to tabCount-1 will now document that it throws an IndexOutOfBoundsException
(note: the underlying code will continue to throw ArrayIndexOutOfBoundsException
for compatibility reasons).
See the related javadoc here.
|
DefaultTableModel.moveRow Specification ClarifiedThe bugtraq report that corresponds to this change is: 4144295.
In 1.3, the moveRow method in DefaultTableModel
was documented in such a way that it did not clearly define whether
the row at startIndex or the row at endIndex
row would end up at toIndex. By inference from the
examples, it appears that the startIndex should end
up at toIndex when moving rows downward and the endIndex
should end up at toIndex when moving rows upward.
That said, the implementation of moveRow had a bug
such that whenever the number of rows being moved was more than
one - the rows would end up in somewhat arbitrary positions and
would not even be contiguous after the move. Bug 4144295 noted that
the implementation did not even perform the example in its specification:
the moveRow(1, 3, 5) example in practice left the vector
in the following state:
a|C|e|B|D|f|g|h|i|j|k
The new implementation makes the observation that this operation is
a simple rotation of elements between bounds that can be calculated
from the inputs.
Since the previous implementation did not work we have taken the
opportunity to simplify the definition to one where the startIndex
is always moved to the toIndex, with all other elements
appearing after toIndex in the same order that they
were originally. Note that this performs the same operation as the
previous implementation in the only case where it worked - when
a single row was being moved.
The new implementation does not throw an exception when endIndex
is less than startIndex - it does nothing instead having
satisfied the implied contract to move all rows, r,
where startIndex <= r <= endIndex.
See the related javadoc here.
The bugtraq report that corresponds to this change is: 4274963.
The Excel application automatically
gives focus to underlying editors when a user presses an alphanumeric
key. We have received 153 JDC votes requesting that we offer this
behavior in JTable. While we can't change the default behavior
for reasons of backwards compatibility, we have added a new property
in release Java 2 SDK, Standard
Edition, v. 1.4 to address this request. The surrenderFocusOnKeystroke
property allows enabling of this behavior. The default behavior
remains unchanged.
See the related javadoc here.
|
DefaultTreeModel Now Allows a Null RootThe bugtraq report that corresponds to this change is: 4264897.
DefaultTreeModel now allows a null root
node . The javadoc for TreeModel specified a null
root was valid, but DefaultTreeModel would previously
not allow one. DefaultTreeModel now allows setting
a null root, as well as a null root in
the constructor. The javadoc for DefaultTreeModel.setRoot()
has been revised to reflect the change.
See the related javadoc here.
JTreeThe bugtraq report that corresponds to this change is: 4284709.
Often times users wish to navigate to cells in a JTree
using alphanumeric keys. To facilitate this, a method named getNextMatch
will be added to JTree. BasicTreeUI
will install a KeyListener that invokes this method
as keys are typed on the keyboard.
See the related javadoc here.
|
ListDataEvent.toString does not provide any useful
informationThe bugtraq report that corresponds to this change is: 4134085.
Developers often rely on the toString method for
useful debugging information. Unfortunately ListDataEvent's
toString method does not really provide anything useful.
For Java 2 SDK, Standard Edition,
v. 1.4 it will be changed to return something useful.
See the related javadoc here.
JList should support first letter key navigationThe bugtraq report that corresponds to this change is: 4284709.
Often times users wish to navigate to cells in a JList
using alphanumeric keys. To facilitate this, getNextMatch
will be added to JList:
See the related javadoc here.
The bugtraq report that corresponds to this change is: 4308384.
JList currently only allows laying out of the items
it contains vertically, that is:
1
2
3
4
Numerous users have asked for the ability to lay out the list horizontally, that is, something like:
1 3
2 4
To achieve this, some constants and methods relating to orientation have been added.
See the related javadoc here.
|
SwingConstants should define next and
previousThe bugtraq report that corresponds to this change is: 4175466.
SwingConstants defines constants that are used throughout
Swing. A common UI operation is to locate the next/previous item
in a sequence, as such, SwingConstants will define
constants for NEXT and PREVIOUS.
See the related javadoc here.
Components from
a non-Swing ComponentThe bugtraq report that corresponds to this change is: 4344900.
Swing has an elaborate infrastructure to support associating actions
with particular key strokes. This means that when the user types
a character the action will execute. The processing of these events
is triggered from within JComponent.processKeyEvent
(processKeyEvent is overridden from java.awt.Component).
As the processing of these actions occurs within JComponent,
there is currently no way for developers to process bindings from
within non-JComponent subclasses that get focus. To
facilitate this a processKeyBindings method will be
added to SwingUtilities:
See the related javadoc here.
The bugtraq report that corresponds to this change is: 4290988.
Currently, the Swing components do not provide the same auditory feedback as the native components on many platforms. MALF2, a set of modifications to Swing's PLAFs, is primarily intended for use as an output-only, non-speech audio user feedback mechanism. The MALF2 project is important from the perspective of Swing/JFC and the Java platform's goal of tight user interface integration with the underlying platform. The MALF2 project ensures that a user's experience with a native application and a Swing/JFC application will be identical with regard to the auditory user feedback.
The implementation centers around adding API to BasicLookAndFeel
to support loading an ActionMap containing Actions
that will play sounds. Various BasicComponentUI implementations
then invoke actionPerformed on the Action
at the appropriate time to play the sound. While BasicLookAndFeel
plays sounds using the Java Sound API, subclasses can use an alternative
method. For example, WindowsLookAndFeel maps the
Strings to Runnables by way of Toolkit.getDefaultToolkit().getDesktopProperty(),
to provide integration with the sounds provided by Windows.
The ActionMap containing the sounds can be accessed
via BasicLookAndFeel.getAudioActionMap. When getAudioActionMap
is first invoked, it performs the following:
auditoryCues.cueList (an Object[])
is used to determine a list of sounds to load.
createAudioAction
to obtain the Action responsible for playing the
sound.
Object passed into BasicLookAndFeel.createAudioAction
is used to look up a path to a sound file from the defaults
table that can be loaded by Java Sound.
BasicComponentUIs classes wishes
to play a sound, it invokes BasicLookAndFeel.playSound,
passing in the Action.
BasicLookAndFeel.playSound invokes actionPerformed
on the Action if the name of the Action
is contained in the defaults entry AuditoryCues.playList.
This architecture allows the developer numerous ways to customize the sounds that are played:
JComponent
can be manipulated by changing the Action in the
ActionMap associated with the JComponent,
eg:
ActionMap map = menuItem.getActionMap();
map.put("MenuItem.commandSound", differentActionToPlaySound);
Components of a particular
type can be changed by manipulating the defaults table, eg:
UIManager.put("MenuItem.commandSound", "pathToNewSoundFild");
BasicLookAndFeel methods to load the
sounds in an alternative manner, or perhaps play the sounds
in a different way.
Alternatively, the set of sounds to be played can be manipulated
by way of the defaults entry AuditoryCues.playList.
This Object array contains the keys in the defaults
table indicating which sounds to play. MetalLookAndFeel
will define this to be:
new Object[] {"OptionPane.errorSound",
"OptionPane.informationSound",
"OptionPane.questionSound",
"OptionPane.warningSound" }
This has the effect of turning on only the sounds that JOptionPane
will support.
See the related javadoc here.
The bugtraq report that corresponds to this change is: 4371580.
The new focus architecture introduced via RFE 4290675
allows for developers to request a temporary focus change. The
request is done through the protected Component methods
requestFocus(boolean) or requestFocusInWindow(boolean).
These two methods are protected as they are not meant for general
use, but only for implementors of lightweight toolkits, such as
Swing. Swing is architected in such a way that code in different
packages needs to temporarily request focus, as such the parent
class of all Swing Components, JComponent, needs
to expose these two methods as public.
See the related javadoc here.
The bugtraq report that corresponds to this change is: 4337186.
With the bulk of the Swing components paying attention to their
ComponentOrientation property, we now need two features
to make it easier to manage the ComponentOrientation
settings of an entire hierarchy of components. It should be easy
to set entire hierarchies of components to a consistent ComponentOrientation
setting.
See the related javadoc here.
The bugtraq report that corresponds to this change is: 4290973.
As part of the Windows look and feel update, a method will be
added to LookAndFeel, getDestopPropertyValue, to
facilitate accessing desktop properties.
See the related javadoc here.
Rectangle by Component
insets This was actually added as part of the update to JProgressBar
to support an indeterminate state. The bugtraq report that corresponds
to this change is:
4290717.
See the related javadoc here.
The bugtraq report that corresponds to this change is: 4356268.
Wheel mice, with a scroll wheel as a middle mouse button, are increasingly popular. This proposal provides for built-in Java support for scrolling via the mouse wheel, as well as a new wheel event listener so developers can customize mouse wheel behavior.
See the related javadoc here.
|
RootPaneUIThe bugtraq report that corresponds to this change is: 4338458.
The classes in javax.swing.plaf.multi are used to
multiplex between multiple look and feels. This is typically used
by assistive technologies that use an auxiliary look and feel to
provide additional information, such as auditory information. There
is currently no implementation in multi for RootPaneUI
which makes using an auxiliary look and feel problematic.
The bugtraq report that corresponds to this change is: 4290471.
AWT recently provided api such that Windows could
be undecorated. That is, the Window would not render
any widgets for closing/moving/resizing... it. As such, Swing
should make it possible for the look and feel to render decorations
for Windows.
The thrust of this will be in javax.swing.JRootPane,
but we will encourage developers to use the switches provided
in javax.swing.JFrame and javax.swing.JDialog
to enable this.
See the related javadoc here.
|
JScrollBar does not override setUI
as other JComponent subclasses do.The bugtraq report that corresponds to this change is: 4213298.
JScrollBar did not previously override the setUI
method. For this release, it has been changed to conform to this
behavior.
See the related javadoc here.
|
JScrollPane should support the
new MouseWheelListenerThis was implemented as part of the mouse wheel support. This
section only documents the changes to JScrollPane,
for details of the other changes refer to this section.
The bugtraq report that corresponds to this change is: 4356268.
See the related javadoc here.
|
VolatileImage supportThe bugtraq report that corresponds to this change is: 4363288.
The Java 2D team has implemented a new VolatileImage
mechanism which enables them to take advantage of hardware acceleration
for Image graphics and blit-to-screen operations.
Swing uses double-buffering by default to paint the contents of
GUI components (by rendering into an offscreen image and then copying
that image to the screen) and should therefore be changed to take
advantage of the new VolatileImage support.
The double buffer that Swing uses to do painting is obtained from
the RepaintManager by using the method getOffscreenBuffer.
Since a VolatileImage object requires special handling
(to test for failure conditions), we cannot simply change this method
to return a VolatileImage since there may be existing
code out there that invokes this method and does not implement this
additional handling. Therefore, we will add an additional method
to javax.swing.RepaintManager to specifically return
a VolatileImage object:
See the related javadoc here.
|
| ||||||||||||
