what would be a standard/optimal java swing gui (eg. JFrame) dimension when rendering on a user screen? would it be wise to set preferred size to 1024 x 768 or 800 x600 or something similar?
should we set preferred size according to the screen size? or is that not a good route?
In my experience it's usually best not to set preferred sizes but to use layout managers judiciously and to call pack() on the top level window after adding all components, letting the components and the layout managers size themselves.
This really isn't a Java question, but a user interface design question. An application I am currently developing needs at least 1024 by 768 to fit everything properly. But if it didn't need the space, then why make it start at that size? Why not let the user maximize the window if he wants to? A user interface should work on as many different display sizes as possible.
My policy is that the best window size is the smallest one that still lets the user do everything he needs to do with the program.
Now back to Java: When creating a swing app, call pack() after placing all the components into the containers. If for some reason I feel that pack tightens things up too much, then I might add a little to the width or height right after a call to pack.
If you need to learn the dimensions of the display you are running on, use this:
Toolkit toolkit = Toolkit.getDefaultToolkit();
Dimension screensize = toolkit.getScreenSize();
With swing, you can also set the preferred size for components and this will affect how much size they take up after a call to pack().
Big enough so all the components fit in the JFrame and no bigger. Typically, I do not set the frame size in pixels, and just let the components size the frame so I know everything will fit.
I would say it's safe to assume more than 1024x768 resolution, but it depends on how compatible your application needs to be. To be certain you can get the screen size with Toolkit.getDefaultToolkit().getScreenSize();
According to the statistics given by w3schools here: http://www.w3schools.com/browsers/browsers_display.asp , it is safe to assume people have a screen resolution of 1024x768 or more.
If you are building a GUI with a fixed size, I'd recommend staying a bit under this resolution, in order to accomodate users with a double-height taskbar or a lateral taskbar (try to see for yourself what fits, something like 900x700 could be good enough).
If your window is resizeable then I would try different sizes to see what looks nicer. Depending on the layout of your application, too small will look too busy, too large could make visual elements too sparse. Obviously you shouldn't exceed the fixed-size limit above, or the current resolution.
You could also try starting your application fullscreen, this only makes sense for some applications though.
Related
We have developed a huge application using Java Swings, this is well exceuting and running on all systems, but the problem is the resolution , if the resolution is 1260/768 it works well means all the components including the scrollbar will be visible, even application will fit to the width and height of the screen, but when its below 1280/768 its not fitting the screen, what i do is manually change the system resolution to 1280/768 and also wrote program which will change the resolution, but the problem is most systems does not support more than 1024/768,on old systems its max VGA Cards-1024/768.
What is the way to resolve this?Which layout manager to change?
Update
Our application will be going live in next 5 days, so need something much quicker, tried with FlowLayout but it will not be good UI.
Or how to resize components when maximized or minimized? how is it implememted?
The answer basically depends on how your GUI is designed.
In some cases, a FlowLayout will allow components to wrap around.
JScrollPane wrappers can be added around sections to make them independently scrollable. Along this line of thought, the entire current GUI could be placed in a JScrollPane and set never to be less than 1280x768 such that scrollbars will appear on smaller displays.
JTabbedPanel could also be used to stack sections of the GUI which are not commonly used in unison.
The smaller resolution could use a smaller and especially a more narrow font. It is a huge task to substitute hard coordinates with scaled ones; something like Scale.x(80). But it is a "dumb" dependable solution. If you still can use a smaller font (Arial Narrow?).
Mind, smaller resolution is often displayed on the same physical size monitor. Or with today's tablets tininess is acceptable.
I have a java based tool that displays every new canvas image in a new tab, and am planing to improve it with more functions. And soon its gona become complex tool have options to create images, viewing sequence images, thus having thought of using JInternal frame rather than JTabbedPane. So would like to know which would be better option in terms of efficiency,processing power and memory?
I think it depends a lot of the size of the images and the way you actually want to display the images to users.
If you have very big images like 10+ of MPixels ones or your users don't need to see several images in the same time then you could go with the JTabbedPane. When you display only one image at a time, you can improve memory consumption by having only that image loaded into memory and probably keep the other images wrapped in SoftReference.
I'd go with JInternalFrame, illustrated here, as each frame can be resized individually. JTabbedPane, shown here, has a lot of appeal, but one-size-may-not-fit-all without scrolling. Only profiling such examples can realistically address efficiency, processing power and memory.
I have just completed an application for my final year project and I need to create the interface for it now. The application will not include many different screens, just one introduction screen with a simple tutorial and the main screen with 5 JPanel and a JMenu. I have each part of the application providing its own JPanel, and the GUI I am about to make should put all those panels together and provide the intro.
What I want to ask is how I can properly set the sizes of different
components so that they are displayed the same on different screen sizes.(not getting really close to each other on small screens / big blank spaces on larger screens)
Should I manually set their preferred sized based on some percentage of the screen dimensions ?(e.g. 20% * width,40% * height) Or there is some other way to do it ?
Also, having one week ahead to complete this part, would it be any benefit to try and learn some library like MigLayout? I read a lot that is easier to use than standard Swing.
p.s
The JPanels include trees,textAreas,toolBar, buttons,checkboxes,comboboxes and textfields. Each one of those panels are quite simple to make.
The answer to this type of question is pretty application dependent, simply because what is 'reasonable' depends on the application and user expectations, but...
If you want the content of the frame to dictate the size of each frame, you can just call frame.pack() and an appropriate size will be guessed at based on the size requirements of the frame's children.
However, if it makes more sense to let the screen size dictate the frame dimensions, you can use Toolkit.getScreenSize() to get the screen size and do your positioning based on what you find.
I've spent many fruitless hours trying to create what I consider to be a very simple GUI. One thing that makes it simple is that I don't even expect it to be resizeable. I want it to display just the way I've laid it out. Simple as that.
There's a JFrame containing two Jpanels of equal width, one above the other. I've got the JPanels behaving themselves finally, and I can slide them around without their enclosed components mysteriously shifting.
But I can't for the life of me get the JFrame to nicely enclose the JPanels. I'm attaching a screen shot showing the layout and the inspector, and another showing how it previews
(Notice that it's chopping off the bottom edge.)
Is there any way to work in a "WYSIWYG mode" in the GUI builder? I don't care about (in fact, I dread) resizeability, at all at this point. I would have thought Absolute Layout would be the right choice for this, but there's still something wrong. (I need an elementary solution, folks -- please don't suggest GridBagLayout!! ;)
EDIT: By restoring some defaults, mainly for MaximumSize, to the JFrame, I got rid of the clipping problem. The right edge was still off by one pixel, and I managed to find which of five (five!) width properties was controlling that. (bounds, max size, min size, preferred size, and width - changing min size fixed that.)
I've already found that you can't completely avoid tweaking properties (e.g. to override "snapping" and achieve pixel-precise positioning). I clearly made trouble for myself at some point by playing with some properties I shouldn't have. The question remains: for non-resizable, WYSIWYG GUI design, is Absolute Layout a reliable choice; and, what properties should I avoid editing?
Is the JFrame showing any better when you actually run than preview? I think this is an OS X specific NB behavior. I did not see this in Win32. For now, you may try adding a JLabel ( spaces as the text content) at the bottom to make sure that space is drawn when the actual JFrame runs.
I have an Swing app whose main panel is divided into a 3x2 grid of charts, and the app can be resized, with the charts (JFreeChart) auto scaling. One of these panels I would like to display the Apdex rating in, which is just text (e.g. '0.89 [0.5]*'). We use the application to display on a monitor visible to everyone, and scale multiple instances of the app that monitor different data centers. Scaling the Apdex font size to fit available panel space is what I'm after.
Any good ideas?
After re-reading and rethinking the question I would suggest for you to try calculating it yourself by use of FontMatrics stringWidth with the string and iteratively increasing the font size until you can, i.e. the size evaluated by you versus the available space.
A ready algorithm would be nice but I didn't hear of any.
Good luck, Boro.
I'd render it off-screen at some suitably large point size, as shown here, and then down-sample it using AffineTransformOp, as shown here.