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.
Related
Whenever I test these accessibility settings with a larger display size or font size, it seems to almost always break parts of my layout and make it look awful. I really like the feature of autosizing text but these settings being changed seem to making autosizing text useless. Changing the display size also creates issues like weird holes in my table rows for reasons I can't figure out. Weighted views seem to break down in how they should work as well.
I have seen there are a couple of ways to work around these settings and making it so that the user's preferences of these settings do not affect your app. Do you all do this?
I understand the utility of the settings for the users. But, it seems kind of arbitrarily implemented because in order to make the layout work with these settings as a developer you might have to make your text size smaller from the beginning (in order to fit a larger font if user chooses to do this), which would lead to the exact same text size you, as a developer, would have chosen in the first place if you weren't trying to accommodate a larger font size being able to fit. I also believe I have heard that IOS doesn't allow for these accessibility settings to affect third party apps.
I am just curious how you all go about dealing with this. Thanks.
It is possible to ignore the user's preferred font sizing, by using dp instead of sp. Same for display size, if you really want to, you could check the current density and draw something according to that, still sizing things smaller. That's not a good approach. While your layouts will not break that way, the user who prefers a larger font/display sizes will still not be able to use your app, as they need a bigger text size.
There are some different techniques you can use to make layouts scale better:
Use minHeight/minWidth attributes in layouts, instead of hardcoding the sizes of the views.
Check that the constraints in constraint layouts are bound in both directions, not just start.
Allow text views to take up multiple lines, add ellipsis option where user can click through to see more information.
I wrote a blog post covering some of these in a bit more detail: Accessible Text Scaling for Android
Sometimes, however, fixing it for all scenarios will involve rethinking the design.
For iOS, the font settings also affect all third-party apps, it's not just an Android thing.
In general, you should always used scale-independent pixels, especially for a large body of text.
However if your text has to fit into a bounding-box of known size then you should use density independent pixels in order to ensure that the text always fits properly and that all characters are visible regardless of the users' setting.
Actually, Settings font size affects only sizes in sp. So all You need to do - define textSize in dp instead of sp, then settings won't change text size in Your app.
Here's a link to the documentation: Dimensions
I have a very, very, very simple application that I'm working on (been trying my luck at writing an app in Java instead of Unity) and I have a background image that is fullscreen, this image has a lot of design and scales well with every device, and looks great (tested on every resolution we can think of).
However the text doesn't want to stay where it belongs, and that's not permissible. We have a basic setup, similar to this (however with about 6 hours of design work put into it):
and we need text to be centered in the squares at all times. How can we do this? Do we have to manually position and size it for each resolution? That seems like hell.
With a relative layout, if I understand correctly, the boxes will be parents and the text that goes into the boxes will be the children. You can put your TextViews into the boxes and then use things like android:layout_centerVertical or android:layout_centerHorizontal in order to make sure they are centered. Make sure to use sp for your font size so that it scales correctly with the density of the display.
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.
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.
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.