javax.swing.plaf.synth.SynthUI Java Examples
The following examples show how to use
javax.swing.plaf.synth.SynthUI.
You can vote up the ones you like or vote down the ones you don't like,
and go to the original project or source file by following the links above each example. You may check out the related API usage on the sidebar.
Example #1
| Source File: ThemeValue.java From netbeans with Apache License 2.0 | 6 votes |
|
private static SynthContext getSynthContext () {
try {
JButton dummyButton = getDummyButton();
ButtonUI bui = dummyButton.getUI();
if (bui instanceof SynthUI) {
return ((SynthUI) bui).getContext(dummyButton);
} else {
throw new IllegalStateException ("I don't have a SynthButtonUI to play with"); //NOI18N
}
} catch (Exception e) {
functioning = Boolean.FALSE;
if (log) {
e.printStackTrace();
}
return null;
}
}
Example #2
| Source File: BasicTextUI.java From openjdk-jdk9 with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #3
| Source File: BasicTextUI.java From jdk8u-dev-jdk with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #4
| Source File: BasicTextUI.java From jdk8u-jdk with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #5
| Source File: BasicTextUI.java From jdk8u_jdk with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #6
| Source File: BasicTextUI.java From openjdk-8 with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #7
| Source File: BasicTextUI.java From openjdk-8-source with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #8
| Source File: BasicTextUI.java From hottub with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #9
| Source File: BasicTextUI.java From Java8CN with Apache License 2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #10
| Source File: BasicTextUI.java From jdk8u-jdk with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #11
| Source File: BasicTextUI.java From jdk1.8-source-analysis with Apache License 2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #12
| Source File: BasicTextUI.java From Bytecoder with Apache License 2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #13
| Source File: BasicTextUI.java From openjdk-jdk8u-backup with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #14
| Source File: BasicTextUI.java From openjdk-jdk8u with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #15
| Source File: BasicTextUI.java From JDKSourceCode1.8 with MIT License | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #16
| Source File: BasicTextUI.java From jdk8u60 with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #17
| Source File: BasicTextUI.java From TencentKona-8 with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
Example #18
| Source File: BasicTextUI.java From dragonwell8_jdk with GNU General Public License v2.0 | 4 votes |
|
/**
* Updates the background of the text component based on whether the
* text component is editable and/or enabled.
*
* @param c the JTextComponent that needs its background color updated
*/
private void updateBackground(JTextComponent c) {
// This is a temporary workaround.
// This code does not correctly deal with Synth (Synth doesn't use
// properties like this), nor does it deal with the situation where
// the developer grabs the color from a JLabel and sets it as
// the background for a JTextArea in all look and feels. The problem
// scenario results if the Color obtained for the Label and TextArea
// is ==, which is the case for the windows look and feel.
// Until an appropriate solution is found, the code is being
// reverted to what it was before the original fix.
if (this instanceof SynthUI || (c instanceof JTextArea)) {
return;
}
Color background = c.getBackground();
if (background instanceof UIResource) {
String prefix = getPropertyPrefix();
Color disabledBG =
DefaultLookup.getColor(c, this, prefix + ".disabledBackground", null);
Color inactiveBG =
DefaultLookup.getColor(c, this, prefix + ".inactiveBackground", null);
Color bg =
DefaultLookup.getColor(c, this, prefix + ".background", null);
/* In an ideal situation, the following check would not be necessary
* and we would replace the color any time the previous color was a
* UIResouce. However, it turns out that there is existing code that
* uses the following inadvisable pattern to turn a text area into
* what appears to be a multi-line label:
*
* JLabel label = new JLabel();
* JTextArea area = new JTextArea();
* area.setBackground(label.getBackground());
* area.setEditable(false);
*
* JLabel's default background is a UIResource. As such, just
* checking for UIResource would have us always changing the
* background away from what the developer wanted.
*
* Therefore, for JTextArea/JEditorPane, we'll additionally check
* that the color we're about to replace matches one that was
* installed by us from the UIDefaults.
*/
if ((c instanceof JTextArea || c instanceof JEditorPane)
&& background != disabledBG
&& background != inactiveBG
&& background != bg) {
return;
}
Color newColor = null;
if (!c.isEnabled()) {
newColor = disabledBG;
}
if (newColor == null && !c.isEditable()) {
newColor = inactiveBG;
}
if (newColor == null) {
newColor = bg;
}
if (newColor != null && newColor != background) {
c.setBackground(newColor);
}
}
}
