EVALUATION
This webrev fixes both the font and the echo character for JPasswordFields when running the Windows Look and Feel. The font is now set to the ControlFont instead of the FixedControlFont, making it match other text fields. The echo char has been turned into a UI property that is set by LookAndFeel.installProperty during the UI delegate setup. installProperty includes a hack to get around the fact that JPasswordField cannot call super.setUIProperty(). This is because setUIProperty is a package private method and part of JPasswordField's inheritance heirarchy is outside of the javax.swing package.
With this new UI property both the Windows Look and Feel and basic derived Look and Feels can set a default echo char. In the case of Windows it is now set to 0x25CF, the bullet character in the standard Windows system fonts.
|
EVALUATION
Based on a submission from Karsten I have prepared a patch that avoids the font issue by just drawing actual circles instead of characters. This seems to be a superior solution when the goal is Windows Look and Feel fidelity. It does not allow, however, a general purpose property to control the password character.
|
EVALUATION
Name: anR10225 Date: 01/30/2004
We should add a new LAF default : 'PasswordField.echoChar'.
For XP theme it should have value '\u2022' (which is the symbol
used in Win XP). BasicPasswordFieldUI and BasicPasswordFieldUI
should override installDefaults() method to set the appropriate
echo character. If the character was set by a client it should
remain the same independent of LAF defaults. For this purpose
JTextField should override setUIProperty().
======================================================================
Two comments on the note above:
1) Although '\u2022' is the right character, keep in mind that the appearance is sensitive to the font that is used.
2) We must take care with how we set this property from the UI. First, we need to ensure that we don't clobber what the developer sets. This can be done by going through a "setUIProperty" method (which will need to be changed to deal with this property. Second, we probably want to ensure that whatever we set is unset when the UI is installed so that we don't affect other UIs that don't set it. - On this note, I've been considering ways to deal with this for other properties. That is, I'm trying to figure out a way to restore properties set by a UI. Perhaps this bug can benefit from whatever I decide there.
###@###.### 2004-02-18
Name: anR10225 Date: 02/19/2004
1) I've find out that the symbol '\u2022' is not the same as WinXP
uses for password field. Also the font which is currently used for
PasswordField differs from font of TextField. The proper symbol
for XP password field is '\u25CF' of 'Microsoft Sans Serif' font.
The problem is that this symbol is painted well only for this specified
font, other fonts paint it larger than required. The symbol I've used
earlier is a little smaller than required, but is displayed almost
identical with other fonts.
I think the password field will look fine if system fonts are used and
may look a little homely otherwise (dots will be larger than
required).
2) Overriding setUIProperty() is not possible for JTextComponent and
its successors. There is a problem with calling super.setUIProperty()
of JComponent since this method is package private and JTextComponent
is in the text package. So I think we should make the method
JComponent.setUIProperty() protected. If it is not possible for Tiger
we may temporary create a workaround.
======================================================================
Name: anR10225 Date: 02/20/2004
I've just noticed that in MS Internet Explorer password fields use
other font than system and the '\u25CF' symbol looks nice enough. So
I'm sure there shouldn't be any problems when using non system fonts in
Win XP.
======================================================================
|
Java