Is it possible to set different L&F to specific component (in my case JTable) than is already used? If so, how to do it?
Edit: I wrote this piece of code according to this tutorial. Why is this code not working? No fails or exceptions, but JTable is still the same.
NimbusLookAndFeel nb = new NimbusLookAndFeel();
jTable1.putClientProperty("Windows.Overrides",nb.getDefaults());
jTable1.putClientProperty("Windows.Overrides.InheritDefaults",false);
You can refer the below URL for all UI default values for nimbus look and feel
http://jasperpotts.com/blogfiles/nimbusdefaults/nimbus.html
Go to Table section and use all the those Table component specific UI default values in your application. That should do the trick for you.
If you would like to apply the Nimbus L&F to a button, then you simply need to figure out which class that is responsible for rendering Nimbus buttons. The process is just the same as if you want to apply your very own custom L&F, where you set your own UI class on the button.
One trick you could do is create a dummy application that uses the Nimbus look and feel, create a JTable, and do something like
System.out.println (myTable.getUI ().getClass ().getName ());
At that point you will know which UI object is used to render the JTable when using the Nimbus LAF. You can use this class name when calling setUI (TableUI) on your JTable:
myTable.setUI (new ui_manager_class_name ());
As others have said, this is hardly something we recommend though. LAF's are usually meant to be used as a whole package rather than a mix of 2-3 LAF's. Your other way out could be to use the MultiLookAndFeel, but I have never used it, so I'm not sure it does fulfill your needs. You should read the associated tutorial if you want to use it correctly.
Related
At 70 years of age I have decided to learn Java, a task that I must say has given me sometimes a lot of frustration. For the purpose of displaying a list of items for selection, I decided to make use of the showInputDialog option of the JOptionFrame class, which I found to work with a perfect alignment whenever the fault font is changed to monospaced by making a call to the UIManager like this: UIManager.put("List.font", new Font( "monospaced",Font.PLAIN,14));
The problem is that this ceases to work with the font returning to whatever its default value is whenever I insert a list in what I suppose to be called the parent frame. I can insert other objects without any problem, but not a list. My question is: what am I doing wrong? Relevant code bellow.
UIManager.put("List.font", new Font( "monospaced",Font.PLAIN,14));
String input = (String) JOptionPane.showInputDialog(null,
"World Exchanges",
"Please select one", JOptionPane.QUESTION_MESSAGE, null,
choices, choices[0]); // Initial choice
I have a suspicion that this is a consequence of inconsistent look-and-feel caching behavior. The javadocs for UIManager say this:
The set of defaults a particular look and feel supports is defined and documented by that look and feel. In addition, each look and feel, or ComponentUI provided by a look and feel, may access the defaults at different times in their life cycle. Some look and feels may aggressively look up defaults, so that changing a default may not have an effect after installing the look and feel. Other look and feels may lazily access defaults so that a change to the defaults may effect an existing look and feel. Finally, other look and feels might not configure themselves from the defaults table in any way. None-the-less it is usually the case that a look and feel expects certain defaults, so that in general a ComponentUI provided by one look and feel will not work with another look and feel.
My recommendation (based on this) would be to make this call:
UIManager.put("List.font", new Font("monospaced", Font.PLAIN,14));
after selecting the look-and-feel (if you do that), and before instantiating any Swing components.
I want to change tabs location from left to center. How can I do this? I think I must change Look&Feel, but I don't know how.
From this:
To this:
As you already pointed out, you have to use an LookAndFeel which supports this design (centered Tab-Button).
When your selected LaF does not support this, you have to write your own TabbedPaneUI.
(But this may not be very easy.)
If you do not want to create your own TabbedPaneUI, you have to look for an existing custom TabbedPaneUI or TabbedPane-Component, which support this kind of layout.
You can take a look at this article, to get started:
http://www.javaworld.com/article/2072927/swing-gui-programmingloseandmaxtabbedpane--an-enha/swing-gui-programming/closeandmaxtabbedpane--an-enhanced-jtabbedpane.html
The placement of tabs is determined by the JTabbedPane UI delegate, typically based on BasicTabbedPaneUI. Not every Look & Feel implementation supports centered tabs, so there's no property that will work by default across platforms.
As a concrete example, com.apple.laf.AquaLookAndFeel supports centered tabs, as shown below. The class com.apple.laf.AquaTabbedPaneUI, which implements the effect, is shown here.
Because the implementation is non-trivial, a better choice is to support the user's Look & Feel choice using Preferences. A suitable Look & Feel selection control is shown here and here.
The source for the example above is seen here.
I'm using a JInternalFrame and I want to remove the dropdown in the upper left of the frame, as it serves no purpose (I've disabled resizeable, closable, etc.)
I don't see a property for this, and I don't want to remove the entire title bar, as the title is necessary. I've looked around online, and basically come up empty here. I'm hoping it's something simple that I've just overlooked, as this is my first time using JInternalFrame, and I'm not exactly a GUI kind of guy to begin with.
internalframe.setFrameIcon(null);
Edit: hack to remove system menu in Windows:
BasicInternalFrameUI ui = (BasicInternalFrameUI)internalFrame.getUI();
Container north = (Container)ui.getNorthPane();
north.remove(0);
north.validate();
north.repaint();
The relevant Icon in The Synth Look and Feel, among the Nimbus Defaults, appears to have this key:
InternalFrame:InternalFrameTitlePane:"InternalFrameTitlePane.menuButton".icon
You may be able to use the approach shown in A Synth Example to replace the Icon.
setFrameIcon(anyBigImageThatCantBeDisplayed);
I´ve tried null parameter and got some visual issues...
So i added a big image(no background) that was already on my resource folder and the icon was no longer displayed as the menu...
I am currently working on a set of custom controls for a product of the company I'm working in. For this, I am extending a lot of Swing controls and also overriding a lot of paint methods.
In order to maintain a consistent color scheme, I receive the colors for my paint, setBackground etc. methods using UIManager.getColor.
This was perfectly fine until we noticed that the Nimbus LookAndFeel, which is shipped with current JRE versions, uses totally different color keys, thus many things looks totally out of place.
For instance, while all other stock LookAndFeels (Metal, Windows Classic, Windows, CDE/Motif, GTK) have defined the key "text" as a bright background for texts and "textText" as the corresponding foreground color, "text" in Nimbus is actually a black foreground color, and a standard text background color does not seem to exist.
"TextField.background" would work, but that, for instance, doesn't exist for the Windows LookAndFeels.
I suppose you get the problem by now. I don't want to have to maintain a set of color keys for each LAF, who knows what LAFs will be added in the future and which my company may decide to use.
A simple solution would be getting rid of Nimbus, of course, but understandably my boss doesn't like this idea at all, besides Nimbus is part of the JRE these days and should be supported.
So I wonder whether there is any standardized way to get LAF-dependent colors like, say, "text background / foreground", "selected text bg/ fg", etc.?
I'm not sure that there is a "standardized" way of getting these values.
As you noticed, Nimbus uses its own names for colors. Specifically, the properties textForeground and textBackground.
This oddness is likely because Nimbus uses a small selection of basic colors (listed as Primary in the chart), which have Secondary colors calculated from them, which in turn are used as the basis for all the remaining colors.
Yea, as #josefx implied, unfortunately this isn't how the UIs work. They're not a pool of generic portable properties, rather they're a set of actual components and specific implementations for each of those components. It's not really an extensible system that's friendly to custom components.
The level of abstraction IS the component, not something finer grained. If you try to ask for a ComponentUI for a component that the L&F does not know about, you're out of luck. And the ComponentUI is little more than a wrapper for a paint method, so it's not obligated to expose any meta data at all.
Simply put, you're stuck basically doing the JTextField (or some other appropriate component) "color scrape" technique that josefx suggests, or adding specific support in your code to handle the eccentricities of the property names of the L&F's that you wish to support well.
Another suggestion is to "pre-empt" the L&F change, and subclass the L&Fs you wish to support to make your components more of a first class citizen within those L&Fs. When the L&F changes to a L&F that you support, silently switch out their class name with your subclasses class name, and then implement ComponentUIs for your custom components, and extend the parent LookAndFeel.createUI method so that it "knows" about your new components.
None of these are pretty, but the Swing component system isn't designed to be extensible at run time to handle custom components. The entire component suite is done all at once when the L&F is created.
There is no way around it - you have to create your own abstraction layer for color names (and possibly other property names).
Basically you have stock LookAndFeels (Metal, Windows Classic, Windows, CDE/Motif, GTK) that use their own color names and Nimbus that uses different names.
Create a class e.g. LafProperties so that for each property/color you have method (e.g. "getTextColor"). This class returns properties for classic Laf styles. Then extend this class for Nimbus, and change only methods that differ in Nimbus.
If stock Lafs and Nimbus have most of the properties differently named, than use you might use an interface and two implementing classes.
Not a nice way but it should work for the basics:
Create a JTextField
call getForeground,getBackground,getSelectionColor to get the laf dependent values
Update:
The ComponentUI class and its subclasses which are the base classes for all look and feels only provide a method to initialise the laf dependent default values, they provide no direct way to access these values.
The java.awt.SystemColor class provides variables for a lot of the common attributes.
For text foreground/background use the member fields text/textText; for selected text, use textHighlight/textHighlightText.
Few things ppop into my mind reading your question, which is a tad spiced with underbelly frustration if I have sensed well:
dependancy on JRE standards/support versus independancy/freedom solutions
standards & conformity versus creativity & customisation
And thus ultimately:
practical approach of your boss versus programmers far future insights
I would like to make use in a normal JDialog of the information icon provided by the JOptionPane.INFORMATION_MESSAGE. Is it possible?
Currently in the JOptionPane source code (rather in its UI, actually), this is done by retrieving this property:
return (Icon)DefaultLookup.get(optionPane, this, "OptionPane.informationIcon");
Outside of a UI code, though, you simply need to call:
UIManager.getIcon("OptionPane.informationIcon")
Note however that the icon returned depends on the current Look & Feel.
Out of curiosity, the other resources are:
"OptionPane.errorIcon"
"OptionPane.warningIcon"
"OptionPane.questionIcon"