A lot of web sites these days have an option to let the user increase or decrease the size of the font that appears on the site. I'd like to add similar functionality to my Java Swing app, with an option to change the font to either a larger size or revert to standard size. The user would be able to do this at runtime, via a menu item.
The current version of my code isn't working very well - the code iterates over the keys stored in UIManager/UIDefaults, and for each key that's a Font, my code derives a new font with the target point size (e.g., if it's larger, then the new point size is usually 16; otherwise, if going to regular size, it's usually 11), and then puts that key and new font in UIManager. Afterwards, the code calls SwingUtilities.updateComponentTreeUI() on the frame, and then packs the frame.
The code will increase the font once, but switching back to regular size has no effect. This is especially noticeable with the menu bar.
Am I going about this the right way? Should I instead create a new look and feel with the larger point size, or use some other method entirely?
Thanks in advance for any help.
The code will increase the font once,
but switching back to regular size has
no effect
I believe you need to update the UIManager with a FontUIResource, not just a Font.
Edit:
You should be able to use:
SwingUtilities.updateComponentTreeUI(frame);
Check out the section from the Swing tutorial on Changing the LAF After Startup;
Related
I want to change the color of the title bar and also the Java icon on the upper left of the frame, so I can make my program (GUI) look better. Is there a simple way to change it?
I'm not sure how useful this observation is, but under the X Window System (e.g. on Linux), the titlebar and the icons in it aren't usually under the control of the application, they're “decorations” under the control of the window manager (WM). I'm not sure exactly how this might impact a Java program — they might be able to use undecorated windows and add their own equivalent — but it's equally possible that what you want to do simply isn't possible (without an inordinate amount of effort) on any platform.
I have a number of various components in a very large JavaEE application. As such, debugging is a pain, and sadly I cannot provide an SSCCE that accurately depicts the problem I'm having.
In a nutshell, somehow my fonts change by themselves for things like JLabels and JTabbedPanes. Without ever touching them, they're being repainted as bold, italicized, dramatically changed in size, or any combination thereof.
Simple question: why?
If I step through the Eclipse debugger, no changes are made, ever. So time is somehow a factor.
I'm still a Java grasshopper (working by myself), and haven't built this program in such a way that the EDT is a sacred object. I'm worried that because I'm potentially not making all repaint() calls on the EDT that the JTabbedPane, JLabel and other font properties are being reset and repainted.
EDIT:
Forgot to say that I'm constrained to Java 1.5.
I think I've narrowed it down to an issue with using HTML in JLabels and JTabbedPane tab titles...but past that I've got no idea. With regards to the JTabbedPane, it's going into the drawing methods with the right Font/FontMetrics objects, but for whatever reason it will very rarely (sometimes more often; still haven't figured out the timing trigger) switch up what font, style, and even size at which it's painting the text.
I'm new in Java/SWT. I'm experiencing some troubles using a SWT label.
When I update the text on the label, its size is not correctly updated (the label is cut, respecting the original size). However, if I perform a very small resize in my dialog, the size is updated correctly.
Basically, I create the label with a default text and then, when I load data I update the label with the real text, that is bigger than the original one.
I tried calling label.update() and label.redraw() without luck.
Try to call parent.layout(), where parent is the Composite which contains your label. Also see Understanding Layouts in SWT.
I know this is old, but in order to not lose any LayoutData settings that may be set on the controls. You should call getParent().requestLayout(). The documentation specifically discourages the user of getParent().layout() which loses all the cached Data settings on the controls.
Use of this method is discouraged since it is the least-efficient way to trigger a layout. The use of layout(true) discards all cached layout information, even from controls which have not changed. It is much more efficient to invoke Control.requestLayout() on every control which has changed in the layout than it is to invoke this method on the layout itself.
Based on the documentation of getParent().layout(), you should call requestLayout() on the control itself not its parent as #kingargyle said.
What I always did was label.requestLayout() and it worked flawlessly.
Sorry for the odd choice of words for the title, however, "border" seems to be the inappropriate term. While it is true that the visible line surrounding an icon in a JToggleButton can be made invisible by using setBorderPainted(false), the same is not true for JCheckBox and JRadioButton.
I can not use the JToggleButton and therefore need to use either the JCheckBox or JRadioButton (or some derivative of JToggleButton I am not aware of), but need the square or circle, respectively, to be non-visible when there is no icon on the button. Also, using setVisible(false) eliminates the button from the layout, however, I need the space to be reserved and not have the component layout change (using GroupLayout).
Any suggestions? Am I going to have to create a custom renderer? I will be looking at that in the mean time.
The route into this would be through customising the look at feel by changing some of the UI properties in the UImanager (the sort of thing that allows you to make simple tweaks with fonts and colours and presumably the images used for the checkboxes or radiobuttons) -- but it's many years since I last did that sort of thing and can't remember the details.
A little Googling turned up this project to inspect current property values, so might at least help with indicating the right part of the APIs to be looking at.
You have to choices here:
1) Customize Look and Feel as described in previous entry.
2) Create your own custom controls by inheriting from existing ones and overriding component painting.
I found a cheap and easy (read hack) for this. I created an empty transparent icon and used it when I didn't want any item to be displayed.
I've created a small gui app in Netbeans. As I was adding in some buttons and text areas the mainPanel resized itself. Now it is really wide [probably 4x as wide as I want] but when I try to drag the edge in it won't resize back down. If I drag it out, making it bigger, it takes that change. I would just like to return the mainPanel back to a reasonable size. Not sure what I'm doing wrong here. I've tried to change the min size, max size, and preferred size settings for the mainPanel with no success. I've even tried to change the menuBar & statusPanel settings at the same time as the mainPanel [thinking that one of them was making the others too big] without success.
Any ideas?
Netbeans does do really stupid things like that sometimes, and I generally get around them using either of these two methods:
First thing to try is to change the layout used. Try the Grid Bag Layout, or any of the others and see if you get better results.
If that doesn't work, then probably the easiest thing to do is to change stuff in the code. You will notice that Netbeans automatically adds a call to initComponents(); in the constructor (you have to switch to Code view from Design view). And if you look at initComponents, it will have a whole heap of auto-generated code to create the GUI. Do NOT edit this, because it's just a matter of time before Netbeans overwrites your changes. What I do is to create a new method initComponentsFix, and call that immeidtaely after initComponents in the constructor. In initComponentsFix, I would add the code to resize the component to the preferred size, and any other things you you want to fix.
BTW I empathise with you - Netbeans' GUI editor is still in need of much work. However, it's code auto-generation is still very useful, so I wouldn't recommend coding the GUI the good ol' fashioned way. That's why I'm advocating using it up until you start felling its limitations, after which you "take control".
There is also a third way, which I would not recommend, is to edit the file that Netbeans stores the Design view in, which is basically shares the same file name as your frame's class' source code, except with a .form extension.
This file is XML, and is pretty easy to edit. I don't recommend this because it is sorta going around the back door, but as a last resort, you can still try it.