<Swing Dev> [9] Review request for 8136366 Add a public API to create a L&F without installation

[Phil Race]

On 05/17/2016 09:21 AM, Sergey Bylokhov wrote:
> I do not really think this new API is a good candidate to be public. 
> The method which gets some unspecified name, then change it to some 
> other, and at the end support only bundled L&F... The user was not 
> able to get the list of built-in L&F. And at the same time the method 
> iterates over the list of the installed L&F which can be changed by 
> the user.

No it does not. The user can only change the list returned
by getLAFState() .. this is iterating over the immutable initial list.
That is how I read it.

-phil.

>
> On 17.05.16 19:10, Phil Race wrote:
>> +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.
>>>>>>
>>>>>
>>>>
>>>
>>
>
>