Fix Components Using Pixels

[Ailsa Cape]

Hi, everyone

I just finished the client GUI and found the major Layout settings are difficult to settle components. For example, it is a painstaking to fix components in FlowLayout. GridLayout makes all its children components the same size, sometimes it looks strange since components� sizes should be different from each other. When you resize the window, sometimes components in GridBagLayout could shrink becoming a dot or disappear.

So I decided to use null Layout and setBounds method to do it.

class MyFrame extends JFrame{
    �
    MyFrame(){
        JButton deleteButton = new JButton(�delete�);
        [B]deleteButton.setBounds(new Rectangle(5,10,70,25));[/B]
        JScrollPane scrollPane = new JScrollPane(table);
        [B]ScrollPane.set Bounds(new Rectangle(5,100,800,375)); [/B]
        �
        [B]setLayout(null);[/B]
        add(deleteButton);
        add(scrollPane);
        setSize(800,600)
        setResizable(false);
    }
    �
}

The advantage is that it can fix all components� positions precisely and provide exact size of each component. It also has some weaknesses. Each component must use setBounds method. If you resize the window, all components� sizes don�t change accordingly so I use �setResizable(false)�.

But I heard using pixels to fix components would cause disorder when transplanting the program into another OS. My OS is Windows 2000, so I installed the Cygwin software to mimic Unix Box and test my client GUI on it. I found the program displays the same appearance as in Windows2000.
Does it mean that I can safely use setBounds method, which uses pixels to fix all components, or it could be trouble when I run it in pure Unix Box?

Thanks in advance!
Regards, Ailsa Cape
[ August 23, 2005: Message edited by: Ailsa Cape ]

[Andrew Monkhouse]

Hi Ailsa,

The Cygwin utilities do not mimic the low level Unix graphics drivers, so you cannot rely on them to give you a true Unix GUI.

This is dangerous as component sizes can differ on different platforms. Take a look at the following three screen dumps from the discussion of this topic in The Sun Certified Java Developer Exam with J2SE 5, Second Edition, all of which were generated by the same source code - only the look and feel was changed. In particular take a look at the button sizes.







Regards, Andrew

[Ailsa Cape]

Hi,Andrew

Thank you for your answers. I haven't received the book yet, so I want to know what kind of Layout the three screen snapshots above uses.

This is dangerous as component sizes can differ on different platforms.

Do you mean even if each component uses setBounds method, its size can also differ on different platforms? In this situation, all components will be disorder or simply change zoom scales?

Thanks in advance!
Ailsa Capt

[Andrew Monkhouse]

Hi Ailsa,

what kind of Layout the three screen snapshots above uses.

They were created using the combination of multiple layouts. We used a FlowLayout with left alignment for the data entry field, and FlowLayout with right alignment for the three buttons. These were then combined in a BorderLayout.

Do you mean even if each component uses setBounds method, its size can also differ on different platforms?

Yes. Take a look at the physical button sizes in each of those three graphics - they are physically different sizes.

In this situation, all components will be disorder or simply change zoom scales?

In general the "zoom scale" as you put it will change. Worst case scenario - say you had used the look and feel that created the second diagram. The buttons are physically very small in that (32x20 pixels). If someone then used a different look and feel - say the third option where the buttons are nearly twice the size (61x28 pixels) - you might find that one button obscures another button, rendering your GUI useless.

Combining layouts is a very powerful method way of designing a GUI that can handle different platforms / look and feels / resizing correctly. Here is the code that created those samples:

import java.awt.*;
import javax.swing.*;
 
public class MyFrame extends JFrame {
    public static void main(String[] args) throws Exception {
        new MyFrame(args).setVisible(true);
    }
 
    public MyFrame(String[] args) throws Exception {
        String lookAndFeelName = (args.length > 0)
                ? args[0]
                : "com.sun.java.swing.plaf.windows.WindowsLookAndFeel";
 
        UIManager.setLookAndFeel(lookAndFeelName);
 
        setDefaultCloseOperation(EXIT_ON_CLOSE);
        Panel topPanel = new Panel(new FlowLayout(FlowLayout.LEFT));
        topPanel.add(new JTextField(15));
        add(topPanel, BorderLayout.NORTH);
        Panel centerPanel = new Panel(new FlowLayout(FlowLayout.RIGHT));
        centerPanel.add(new JButton("One"));
        centerPanel.add(new JButton("Two"));
        centerPanel.add(new JButton("Three"));
        add(centerPanel, BorderLayout.CENTER);
        pack();
        setSize(210, 100);
    }
}

Regards, Andrew

[Ailsa Cape]

Hi, Andrew

Thanks a lot! I notice many methods in Swing package using pixels to fix size or location, such as JFrame's setSize/setLocation, JTable's setColumnsWidth/setRowHeight and many setBounds methods. Should we all avoid using these methods?

Thanks in advance!
Regards,
Ailsa Cape
[ August 26, 2005: Message edited by: Ailsa Cape ]

[Andrew Monkhouse]

Hi Ailsa,

There are many reasons why these methods exist, including that prior to having layout managers, graphical components needed to be set in explicit locations (the problems with doing this was one of the major reasons for the development of layout managers). So if you are working with any old code that uses explicit positioning then you will want to be able to explicitly position your new components. Also many programmers from other languages are used to explicitly setting positions. And if you know that your application is only going to be run on one particular platform and cannot have its look and feel changed then you might take this particular shortcut.

In general though, it is better to set minimum, maximum, and default sizes only where necessary, not set explicit bounds if you can avoid it, and let the layout manager do the work necessary to ensure a good GUI.

Regards, Andrew

[Ailsa Cape]

Hi, Andrew

Thanks a million! I should follow your advice, trying to avoid using pixels to fix components location, which could result in unexpected GUI appearance.

Regards,
Ailsa Cape

[Lara McCarver]

I have just recently started working on the UI elements, and I discovered that the GUI does not size down as well as it sizes up. For example, I found some of my elements disappearing when I grabbed the window frame and made it smaller than its starting size. This was only in the 1 window I have completed, the server window, so I don't know if this is a general problem with Swing components or not.

Anyway, if this is what you are running into, my solution was to create each element at its minimum permissable size, in terms of logical units (like number of characters for text edit fields), then create the window and make it visible, then set the size of the window to twice the minimum size (because the minimum size is kind of tiny). I also added code to prevent the window from getting any smaller than its initial size.