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

[Sergey Bylokhov]

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

Right(but it is unclear how the user will get the correct "name" if the 
list in getLAFState() was changed by app or by conf/swing.properties, 
hardcore it?) and I am still not sure about other points, but since 
there are no other objections, then ok +1.

>> 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.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.