My Swing Application's GUI is built using Window Builder Pro GUI editor. Layouts used are MigLayout and AbsoluteLayout. Application is developed using Windows Machine, So UI is well aligned and neat in Windows, but when I run the same application in Mac OS X, Application's Frame couldn't accommodate the components inside its bounds. I mean, size of Components inside the frame changes across platforms. When I give extra space(Increased frame bounds), it looks nice in Mac but weird in Windows. Is there any way to have Frame or Panel to grow with respect to its contents or Components.
Don't use the absolute layout. Layout managers are used precisely to avoid the kind of problems that you're facing.
Assuming you used AbsoluteLayout because none of the existing layout managers suited your needs,
Have a look at Creating a Custom Layout Manager and use one instead of AbsoluteLayout.(Before that make sure none of the present layout managers suit your need)
Related
I designed (Netbeans Project) the swing GUI in one computer 15" screen.
Next, I moved the project to another computer 14" screen. When I launch the app in the 14" screen, it's like zooming the GUI and I can't see some part of it.
How can I let my design adjust itself from one computer to another?
Ps : In the GUI editor of netbeans, the size is the same in both computers
Update
I don't know if layout manage will solve it as they said in comments. I've just notice my Windows 10 displays 125 % zoom scaling on 1920 x 1080 resolution. When I switched to 100%, though all other applications of the computer looked aweful, the design I made in Netbeans looked exactly the same. What can I do then ? I think it's more related to Windows scaling than Swing's LayoutManager features. Am I correct ?
You need to use layout managers. Layout managers will organize your components in different ways depending on screen size, aspect ratio, etc.
Depending on what kind of GUI you want, you are going to choose a different layout manager. Once you have picked a layout manager, you can pass it to a JPanel on construction
JPanel panel = new JPanel(new FlowLayout());
More on info on how to use layout managers, here
JFrame is Extending Frame. Then, How JFrame is lightweight but Frame is heavyweight?
I red this article but still i didn't get how JFrame achieves its lightweight property?
I got from here that JFrame is heavyweight but other Components starts with J* are lightweight. How other Swing components achieves this. I need bit of technical details.
Technically it's not. Both are heavy weight components, but because JFrame has been setup to support the JRootPane, which contains the content pane (and possibly) the glass pane (as well as the JMenuBar), it is consider "light weight", because it's been deliberately configured to support light weight components
Essentially JFrame and JWindow have been modified as light weight containers that support light weight components
it is still a heavyweight component because it(JFrame) inherits from the Frame.And it is not belong to the JComponents which is lightweight components.
Heavyweight means each Java component has a native peer associated with it. A native peer is an OS-specific component... AWT is heavyweight, so if you create a AWT Button, on the Windows platform an MFC button is created, on *nix a Motif button is created, etc.
Lightweight means that there is not a native peer associated with the java component. This is done by having only the top-level component be heavyweight and all the lightweight components are drawn on to it. Swing is lightweight.
Of course, AWT and Swing are specific to standard Java (J2SE). Under J2ME it depends on what sort of device you are using. If you are using a more powerful device, like the Sharp Zaurus, then you have AWT and functionality pretty close to J2SE levels. If you have something like a Java-Enabled cell phone, you don't have all the capabilites that you need for a fully featured GUI, so there are special libraries used for making these applications. You'd need to look at the APIs provided by the device manufacturer most probably.
JFrames are heavyweight, since it's impossible to create a task-view-level window in most OS without creating a "heavy" AWT window. Lightweight components can replace internal widgets with java-based stuff that doesn't require JNI calls, but windows are the special case. JFrame does let you do custom renders, though. Also, if you're using other lightweight stuff, then I suggest using JFrame as well since it makes the rendering more efficient overall than mixing light and heavy components.
It is still a heavyweight component because it(JFrame) inherits from the Frame. And it is not belong to the JComponents which is lightweight components.
How can I globally compress Matisse-generated GroupLayout and perhaps other gap spacings to make Swing dialogs generated with Matisse and GroupLayout more compact?
I have used Matisse to re-implement in Java Swing some large dialogs originally developed for Windows in Visual Basic's GUI builder.
The results in the Swing Windows L&F are very similar to native (of a certain age), except more "spread out." At lower res they leak off the screen. This is a real problem for the app.
Measuring shows all the gaps proportionally bigger than the Windows defaults. (The way Swing scales for different resolutions is not helping either.) This includes ContainerGaps emitted by Matisse and L&F-controlled gaps between GUI components.
I have looked at GroupLayout documents and the Matisse documentation I can find. I've looked at L&F parameters and the ContainerGap and related classes in the GroupLayout source. Nothing is taking me where I need to go.
All insight appreciated.
There are too many ways this could be wrong and no single point of adjustment that will fix it. The Visual Basic version surely looks good on its single target platform. By design, Swing relies on pack(), which "Causes this Window to be sized to fit the preferred size and layouts of its subcomponents." The preferred size may vary by platform, as shown in this nested layout example. Instead, study available layouts and use the GUI designer in a focused way, as suggested here.
There's no easy way to fix layout problems in the GUI designer without understanding Swing layouts; happily, the GUI designer is an excellent way to study the effects of various Swing layouts.
I have a Windows Mobile application written in Java that uses AWT for the user interface. I am looking at porting the UI to SWT. I got a hold of the SWT libraries for windows mobile and I started looking at what work will be involved in actually porting it over. I think the first thing I have to decide is how to handle a large number of screens in the application.
In AWT the UI is basically a single java.awt.Frame with CardLayout. Each screen is then just an extension of java.awt.Panel, and is added to the Frame. Then whenever we need to change to a different screen we just set that panel to the top-most.
SWT doesn't have such a layout manager (and I'm not even sure if that is the best/most efficient way of doing it anyway, since the system resources associated with every screen in the application are always held). One way I thought of doing it was that each screen would be its own org.eclipse.swt.widgets.Shell. Switching from one screen to another would involve a display manager class creating the new screen (shell) and disposing of the old one (not sure of the performance hit here of creating the shell and all of the widgets every time the screen is shown?). I am not sure though if having multiple shells in one mobile application is a good idea??
Does anyone have any suggestions on the best way to handle multiple screens in a mobile application using SWT? Is there an equivalent to the method we are currently using in AWT, i.e. CardLayout? Or am I right in thinking that this is not really the best way of doing it, given the use of resources for every screen, even if they are not being displayed?
So the answer to my own question seems to be that there is in fact a StackLayout in SWT, which is pretty much identical to CardLayout in AWT. So I can use that and the job of porting from one to the other is pretty easy because they act in the same way.
Not sure how it would play out in Windows Mobile, but MigLayout is a great layout manager for SWT, which may support the kind of layout you describe.
Check out its demos.
I'm using Qt Jambi 4.4 for a project I'm working on (and designing the windows in the Qt Designer eclipse plugin). One of the windows I'd like to use is a preview window which is basically just a window with a QWebView on it. How can I make it so that the QWebView resizes as the window does? I've set the sizePolicy to expanding for both Horizontal and Vertical position. What else do I need to do?
(also bear in mind that I'm a newbie to both Java and eclipse and need to be talked to in stupid people terms on both of those subjects)
UPDATE
Just to illustrate the point, here are a couple of screenshots (I've made the window background bright just to illustrate my point):
alt text http://img13.imageshack.us/img13/2103/screenshot2oi7.jpg
alt text http://img152.imageshack.us/img152/6250/screenshot1mz9.jpg
I don't know Jambi, but with Qt Designer just give the background the focus and then apply a layout from the toolbar. Then the main widget will get resized by that layout manager -- if you don't add that layout manager you'll get the widget resizing but the contents staying at their old positions.
I haven't used qt-jambi, but if it is anything like Qt in C++ or PyQt, the QWebView would resize automatically as the window size changes. As far as I know, setting size policies/ expansion factors, adding QSpacerItem objects etc. is only necessary if the sizing behavior is not working right. Just laying it out using an appropriate layout within the preview window should be sufficient. Do let me know if I have misunderstood the question.
You need to place the QWebView in a layout, that it will follow the change in its "container". For using layout with Qt Designer, refer to http://doc.trolltech.com/4.5/designer-layouts.html
From Qt Designer docs:
The form's top level layout can be set by clearing the selection
(click the left mouse button on the form itself) and applying a
layout. A top level layout is necessary to ensure that your widgets
will re-size correctly when its window is re-sized.