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.
