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.
