<Swing Dev> [9] Review request for 8136366 Add a public API to create a L&F without installation
Phil Race
philip.race at oracle.com
Tue May 17 16:10:41 UTC 2016
+1
-phil.
On 05/17/2016 08:13 AM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the updated fix:
> http://cr.openjdk.java.net/~alexsch/8136366/webrev.04
>
> The proposed UIManager.createLookAndFeel(name) method allows to
> create only Java built-in L&Fs by the given L&F name.
>
> Thanks,
> Alexandr.
>
> On 4/4/2016 11:17 PM, Phil Race wrote:
>> +1
>>
>> -phil.
>>
>> On 04/01/2016 08:19 AM, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the updated fix:
>>> http://cr.openjdk.java.net/~alexsch/8136366/webrev.01
>>>
>>> The UnsupportedLookAndFeelException is thrown from the
>>> UIManager.createLookAndFeel(className) method for unsupported L&Fs.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 01/04/16 18:14, Sergey Bylokhov wrote:
>>>> On 01.04.16 16:02, Alexander Scherbatiy wrote:
>>>>> I see the point that creating non installed system L&F may not
>>>>> have
>>>>> many sense.
>>>>
>>>> I guess we should thinking about supported/unsupported instead of
>>>> installed/non-installed.
>>>>
>>>>>
>>>>> One more use case that should be considered is using the
>>>>> createLookAndFeel(className) method with custom L&Fs.
>>>>>
>>>>> For example someone can have a list with L&F class names which
>>>>> includes both system and custom L&F.
>>>>> Using a class name he wants to check if the given L&F is
>>>>> supported.
>>>>> Does he need to install the custom L&F first?
>>>>> If no, he will need to handle L&Fs differently using
>>>>> UIManager.createLookAndFeel(className) for system L&Fs and reflection
>>>>> for custom.
>>>>
>>>> Is the new method a "shortcut" for:
>>>> - UIManager.setLookAndFeel("com.foo")
>>>> - laf = UIManager.getLookAndFeel();
>>>> - laf is used...
>>>> Then probably the new method should work symmetrically to
>>>> setLookAndFeel() and throw UnsupportedLookAndFeelException()? And
>>>> if the Laf will be created will means that its state is valid(like
>>>> uidefaults etc)
>>>>
>>>> Small notes:
>>>> - Should we specify the null behavior?
>>>> - It is unrelated to current fix, but I wonder why we call
>>>> newInstance for all incoming classes(we initialize the class and
>>>> create the instance), and then we cast this new object to LookAndFeel.
>>>>
>>>
>>
>
More information about the swing-dev
mailing list