<Swing Dev> When running with the Nimbus look and feel, the JFileChooser does not display mnemonics for its controls.
Charles Lee
littlee at linux.vnet.ibm.com
Mon Aug 8 07:54:55 UTC 2011
On 08/05/2011 05:00 PM, Pavel Porvatov wrote:
> Hi Charles,
>> On 08/03/2011 08:49 PM, Pavel Porvatov wrote:
>>> Hi Charles,
>>>>
>>> Yes, that's what I meant...
>>>
>>>> 2. I do not think we should use VK_XXXX code. CR7024118 recommends
>>>> to remove the VK_XXX code right?
>>> I don't see such recommendations. Anyway we cannot use chars now
>>> because of backward compatibility requirement.
>> CR7024118 says:
>>
>> "As seen in following, 3 mnemonic keys seems to be hardcoded and
>> making them unable to localize. Please consider externalizing them to
>> src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal.properties"
>> and
>> "Since following keys in
>> src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_xx.properties
>> being translated, in some languages mnemonic character is not in
>> label string and won't show up in gui. "
>>
>> It means the hardcoded VK_XXX codes can not be localized and in some
>> situation the mnemonic character is not shown in the label. So we
>> should use localized character as mnemonic. right?
> The last your sentence is incorrect. Hardcoded mnemonics cannot be
> localized via properties files and therefore they works only for for
> English, but not for other supported languages. So we should use
> localized VK_XXX as mnemonics... Because, as I said before, we MUST
> keep backward compatibility.
>
> Regards, Pavel
>
>>
>>>> 3. If the patch is ok, I would like to fix CR7024118 also.
>>>>
>>> So, there are two comments about the patch:
>>> 1. We must use VK_XXX codes for backward compatibility in WindowsLAF
>>> and MetalLAFs . Therefore NimbusLAF should use VK_XXX codes as well
>>> to be consistent with other LAFs
>>>
>>> 2. Could you please put mnemonics near labels? E.g.
>>> FileChooser.lookInLabelText=Look In:
>>> FileChooser.lookInLabelMnemonic=<VK_CODE>
>>>
>>> It looks much more convenient I believe
>>>
>>> Regards, Pavel
>>
>>
>
Hi Pavel,
I do not quite understand why we should keep VK_CODE, so I make two
patches for first review, I will modify other properties if one of the
patches is ok :-)
[1] is the patch which is not use VK_CODE. (attached)
[2] is the patch which is use VK_CODE, I have to use reflect in that
patch. Maybe I miss something. (attached)
--
Yours Charles
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.review1
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20110808/5af4a3c4/patch.review1>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.review2
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20110808/5af4a3c4/patch.review2>
More information about the swing-dev
mailing list