I created a program that deals with combo boxes, and I ran across a problem a Mac user showed me. Mac apparrently resizes JComboBox's and JButton's even if I set the width. The width of all the combo boxes on Windows are different since they are supposed to, but on OSX it's all the same width and size making it impossible to read half the entries of in the combo-box because it's all cut off when you try to select a selection. How can I fix or prevent this?
So my question is, how do you stop an operating system from auto-resizing the swing tools, or how do I make the selections in the JCombBox's readable and not cut off to like "Boxes" instead of "Bo...?"
As shown here, don't set the width; that is the purview of the UI delegate, com.apple.laf.AquaComboBoxUI. Instead, let the JComboBox calculate it's own preferred size based on the font metrics that inevitably vary from one platform to another.
If you still have problems, this example may form the basis for your sscce.
Related
Specifically on a Windows XP machine, The width of the SWT ScrollBar Slider becomes incredibly thin when the internal scroll composite is very large. Is there a way to set the minimum width of the thumb slider to like 10-15px so that it doesn't get that thin? My specific case with this is when using NatTables with large amounts of data.
The scrollbar in NatTable is managed by the ViewportLayer. It internally uses instances of ScrollBarScroller for this, which are wrappers around a ScrollBar. To support custom scrollbars like the one posted in the other answer, the ViewportLayer supports that you set a custom ScrollBarScroller. This is explained in one of my blog posts here: NatTable with custom scrollbars.
You could for example set a customized instance of ScrollBarScroller where you override #setThumb(int) and there you ensure that the value of the thumb never gets below a certain minimum. Not sure if that would have any side effects on scrolling. But it should be worth a try.
Hi I don't think you can do that, because the Scrollbar it's drawn by the OS.
I think you have two options here, if you really need this feature:
1) implement you custom Scrollbar.
2) try to use/modify an existing custom Scrollbar, for instance this one: http://www.codeaffine.com/2014/12/17/sacrilege-custom-swt-scrollbar/
Why Stage icon so low quality? The original image is much better.
How to fix it?
I used this code to setting image as stage icon:
stage.getIcons().add(new Image("/res/app_icon.png"));
Screenshot:
Original icon:
Update
Unfortunately the implementation of the icon chooser in JavaFX 8 does not always choose the best icon size for the application from the list of available icons.
See:
JDK-8091186 Windows 7 taskbar icon is blurry.
JDK-8087459 Ugly icon in Windows task bar.
The issues are (currently) scheduled to be addressed in Java 9.
Some comments on those issues are:
Indeed, Glass currently supports assigning only one icon for a window, it won't allow one to assign a set of differently sized icons. This feature needs to be implemented in Glass.
--
I have noticed that when setting multiple icons, only the last one in the list returned by getIcons() is used. It doesn't matter if other icons, with better resolutions are in the list.
If you provide a list of icons of different sizes, try putting the size you expect to be used most last in the list (perhaps order the list from smallest to largest or place a 48x48 icon, which is the size used in the quick launch area on Windows 7, as the last or only element in the list). Unfortunately, I do not have access to a Windows machine to test the best icon size for that platform.
Icon Guidelines (but be aware of the information in the update above):
Provide a set of high quality icons of different sizes to the list
returned from
stage.getIcons().
The best fit size will be chosen by the runtime.
Use standard icon
sizes which most operating systems can work with without further scaling (for
instance item size is a power of two or 48x48).
Use high quality source images (the original source image in your question seems a bit blurry to me).
For very small icons, sometimes a pure scale of a larger icon to a smaller size is not best. Sometimes it is best for the icon designer to clean up and remove intricate details from the small icon, which might be OK in a larger icon - see the discussion on icon size on Pushing Pixels to help understand why.
Info on what icon sizes are used by what OSes is in this icon handbook.
stage.getIcons().addAll(
new Image("/res/app_icon64x64.png"),
new Image("/res/app_icon32x32.png"),
new Image("/res/app_icon16x16.png")
);
A great source of high quality icons in a variety of sizes is http://www.iconarchive.com, for example this refresh icon.
Hi everyone I've recently come across the problem that now days some monitors have different DPI settings, some monitors are much more dense such as, for example, Apple's Retina displays.
How would one compensate for the different DPI settings and densities on various monitors with Java? Is it possible to scale the controls to be the same size on any monitor. I know when programming for Android all measurements are in "DP" and you can specify different images for three different display densities.
Is there a way I could choose different images using Java / Swing for different display densities so my application doesn't look blurry on higher density monitors? Or is this not that important or possible? I know Chrome currently doesn't take into account DPI but Internet Explorer and other apps do.
Thank you for your help, I'm a long time Java developer I've just never thought about DPI before and was wondering how I might go about it :)
First, trust the platform's Look & Feel designers to choose sensible default sizes for text and controls. Then, avoid the temptation to frustrate those defaults. Here are some heuristics:
Use layouts; when contemplating absolute positioning, consider a custom layout.
Respect the preferred size of components.
Avoid non-resizable components.
In animation, scale graphics to the size of the enclosing Window.
Test across a range of platforms, using emulation as required.
First thanks trashgod for the useful links you provided for they were very helpful.
Below I have listed some specifics on how to deal with issues concerning DPI changes that I have run into.
Font Issues:
If the font is not fitting in the component then look at Component Sizing Issues below for often the component is not sizing to what is inside. Otherwise in a JLabel you can apply HTML tags to automatically line wrap the text (there are other solutions but this works for me).
If the component's text is naturally the default font, size, and style (Tahoma 11 plain) then everything is automatically done for you. Know that user574171 gave pictures showing different font and layout managers issues and strengths in his link to http://kynosarges.org/GuiDpiScaling.html in his answer to How to set the DPI of Java Swing apps on Windows/Linux?. This question here is asking about the "Swing" issues but his link is useful in also comparing WPF, JavaFX, and Swing layouts with a basic components and different fonts. You can see there the "Swing a" font is the best, that is Tahoma 11 Plain. However it only works if the component is naturally the default font, size, and style (Tahoma 11 Plain). This means bolding, underlining, sizing, and a different font for the text will throw off the auto sizing for different DPI.
If the text is the default font (Tahoma) but bolded, underlined, or a different size then the text does not scale for different DPI's. To fix the scaling for different DPI's then check the box labeled "Derive the font from the default font." The "Relative" option will take the default DPI scaling font and apply your relative changes such as bigger or smaller, bold, and underlined. Also know that if the component is a JLabel then DPI scaling is automatic using HTML tags despite how you format the text (line wraps too).
If the component is not naturally the default font, style, and size (Tahoma 11 plain) or you want a different font (ie not Tahoma) then you need to associate the changes in another component that is naturally the default like a JLabel. Therefore if 125 DPI increases the font by 3 then you increase your desired font by the same.
Component Sizing Issues:
All components have a preferred, minimum, and maximum size properties but I have found that they do not play well with DPI changes. The "Respect the preferred size of components" bullet in trashgod's answer tells you all about it. To summarize let the default size of the component take care of itself for it will try to size to whatever is inside.
If the component can use the default sizes then DPI handling can be done for you. Just as trashgod's said "First, trust the platform's Look & Feel designers to choose sensible default sizes for text and controls. Then, avoid the temptation to frustrate those defaults." Again, the component of the default size usually sizes to what is inside (or acts re-sizable). From my own experience when I set re-sizable components I do it via "Horizontal Resizable" or "Vertical Resizable" for I have found it works very well with DPI changes as well as window resizing.
If the default size does of the component does not work then first try looking below at some specific issues I found. Alternatively try scaling the component according to changes in a component that does get scaled right. IE, apply ratio of what you expected the scaling component to be at 100% DPI and the change to the new DPI. Examples of components that need to be scaled to other component changes would be one that it's text is filled by code or it is an image.
As a last resort use a JScrollPane to allow the user to scroll to see the whole thing. If the window/dialog is fairly large then a JScrollPane is a great idea because if the DPI is higher for the user's eyesight then the window often is bigger than the screen.
Note:
I have found that encapsulating groups of components in a JPanel helps swing handle DPI changes a lot better.
JTextField Size Issues:
Set the columns property and nothing else but the text if you wish. The columns property is the number of letters or numbers you want to show. Typically used when allowing the user to enter a number. Know that the columns property works great for multiple platforms.
JSpinner Size Issues:
Set the model to be accurate, valid, and default values. Therefore the auto-sizing of the component is done for the max value and works great for DPI changes and other platforms.
Table Row Height Issue:
Table row height does not change with higher DPI. I encountered this issue and it seems to be due to me trying to be compatible with older versions of Java. To fix multiply the change in font size ratio or change in JLabel height ratio due to the DPI change.
Use JRE 9 (or greater).
This is because the Java runtime (older versions) declared themselves to be "DPI-aware" but didn't really supported it for AWT and Swing. Java applications were sized and rendered based on pixels rather than being properly scaled, this included HiDPI displays.
Anyways, this has been recently solved.
See the issue JEP 263: HiDPI Graphics on Windows and Linux
and the upgrade.
So, increasing the font size does not work (because it does not increase the rest of the things); the jvm argument -Dsun.java2d.dpiaware=false does not work (because it is not really supported); and the manifest file + registry edit (for Windows) just does not work.
Then, You need to run it on JRE 9 because it really supports this feature.
By using
System.setProperty( "sun.java2d.uiScale", "1.0" );
in your java code, ui scaling should be deactivated.
I have been struggling to get the images displayed in an SWT TableItem to scale. I have a listener which scales the fonts correctly, and I have confirmed that the images being set into the TableItem are correctly scaled. I know that the scaled images are being successfully set into the TableItem, because I can even change what image gets displayed. But the new image is always displayed at the original scale.
I have read in SWT: The Standard Widget Toolkit, Volume 1 where the authors state:
The First Image Defines the Size of
All Images in the Control
Due to a Windows limitation, just like
ToolBar, TabFolder, and Tree, Table
scales the images it displays to be
the size of the first image inserted
into the control.
The behaviour I'm seeing is the most extreme case suggested by this quote -- images in the table seem to be being scaled, not the the size of the first image in the table, but to the size of the first image ever to have been in the table. Can anyone confirm or refute this? Does anyone have any more detailed information about the behaviour of images in TableItems? Is this restriction really the show-stopper it seems to be?
And in particular, if I go down the path of custom drawing table items (Custom Drawing Table and Tree Items), am I likely to bump into any further showstoppers?
(You'll note what a good job I'm doing of gritting my teeth and not giving way to rage at having to deal with Windows stupidity even when using a supposedly cross-platform development environment!)
I can confirm this in my experience on Windows.
I propose one of two solutions:
Use custom table drawing as per the link you mentioned. It's a little annoying but not more than 2 hours of work I'd say to learn and implement it.
Use an alternative SWT table control e.g. Nebula Grid or KTable which do not share the same platform limitations of Table on Windows
Edit: in response to "And in particular, if I go down the path of custom drawing table items (Custom Drawing Table and Tree Items), am I likely to bump into any further showstoppers?"
The only issue I found with custom drawing is that it's best to know ahead of time what the maximum row height will be, otherwise there will be jumping when Table has to increase the row height and therefore scroll items a bit while it readjusts
I am looking for ways to zoom in a Java Swing application. That means that I would like to resize all components in a given JPanel by a given factor as if I would take an screenshot of the UI and just applied an "Image scale" operation. The font size as well as the size of checkboxes, textboxes, cursors etc. has to be adjusted.
It is possible to scale a component by applying transforms to a graphics object:
protected Graphics getComponentGraphics(Graphics g) {
Graphics2D g2d=(Graphics2D)g;
g2d.scale(2, 2);
return super.getComponentGraphics(g2d);
}
That works as long as you don't care about self-updating components. If you have a textbox in your application this approach ceases to work since the textbox updates itself every second to show the (blinking) cursor. And since it doesn't use the modified graphics object this time the component appears at the old location. Is there a possibility to change a components graphics object permanently? There is also a problem with the mouse click event handlers.
The other possibility would be to resize all child components of the JPanel (setPreferredSize) to a new size. That doesn't work for checkboxes since the displayed picture of the checkbox doesn't change its size.
I also thought of programming my own layout manager but I don't think that this will work since layout managers only change the position (and size) of objects but are not able to zoom into checkboxes (see previous paragraph). Or am I wrong with this hypothesis?
Do you have any ideas how one could achieve a zoomable Swing GUI without programming custom components? I looked for rotatable user interfaces because the problem seems familiar but I also didn't find any satisfying solution to this problem.
Thanks for your help,
Chris
You could give a try to the JXLayer library.
There are several tools in it, which could help you to make a zoom. Check the examples shown here. I would recommend you to read more about the TransformUI, from this library. From the example, it seems like it could help solving your problem.
Scaling the view is easy enough; transforming mouse coordinates is only slightly more difficult. Here's an elementary example. I'd keep JComponents out, although it might make sense to develop an analogous ScaledComponent that knows about the geometry. That's where #Gnoupi's suggestion of using a library comes in.
hey you can try this if you want to zoom a image like any other image viewer the use a JPanel draw an image using drawImage() method now create a button and when you click the button increase the size of the panel on the frame it appears as if the image is being viewed in Zoom
You might find Piccolo2D.java API useful: http://code.google.com/p/piccolo2d/
It is very simple.
It touts in particular its smooth zooming. You essentially make a "canvas" that can contain various elements, and can then zoom by just holding right-click and panning the mouse back and forth.
I worked on a team that used it to create this: http://sourceforge.net/apps/mediawiki/guitar/index.php?title=WebGuitar#EFG.2FGUI_Visualizer
The nodes you see there are clickable links themselves.
Since Java 9, there are VM arguments (actually meant to be used for high dpi scaling) that can render a application with a higher scaling factor:
java -Dsun.java2d.uiScale=2.0 -jar MyApplication.jar
Or:
java -Dsun.java2d.win.uiScaleX=2.0 -Dsun.java2d.win.uiScaleY=2.0 -jar MyApplication.jar