0

I need a way to manually control/stretch the size of my whole GUI.

I have a 1400 x 1050 Desktop (native resolution) and I want to scale the resolution manually to 1024 x 1050 inside the code, because my application was written on/for a 1024 x 768 Desktop. So in general the whole frame and all buttons etc should be stretched / bigger as a whole and the relation should stay the same.

I can´t do it via Windows properties because the resolution in general needs to be 1400 x 1050 because of another application.

My approach was something like:

Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
screenHeight = screenSize.height;
screenWidth = screenSize.width;

..and then change the screen size via setSize()? But I don´t understand how.

Java Tookit Screen Resolution - How can I use it?

..unfortunately the link in the answer here does not work anymore.

How to set resolution manually in Java Swing?

Miri
  • 3
  • 1
  • 3
  • 5
    *"because my application was written on/for a 1024 x 768 Desktop"* That's not only the source of the problem, but the thing that should be fixed. By using Java layouts appropriately, component sizes and placement will be automatically changed according to the available app. size, no matter what screen size it is maximized on. See also [What is the XY problem?](http://meta.stackexchange.com/q/66377) – Andrew Thompson Jan 31 '18 at 14:42
  • 1
    And what if you set the size of your frame instead of changing the screen resolution ? Otherwise, i'm not sure that it's easy to access to a OS parameter as the screen resolution easily in Java. – SebVb Jan 31 '18 at 14:49
  • if i only set the size of the frame, the buttons etc are too small in relation to the frame.. – Miri Jan 31 '18 at 14:56
  • i want a way to manually control/stretch the size of my whole GUI. @Andrew Thompson in this case what ist the appropriatley way of using Java layouts? – Miri Jan 31 '18 at 14:58
  • 2
    This question is too vague to provide concrete help for. But proper use of [layout managers](https://docs.oracle.com/javase/tutorial/uiswing/layout/visual.html) will allow you to define how your GUI elements stretch / resize. – Ironcache Jan 31 '18 at 15:04
  • 1
    I will add (as a personal opinion) that, of the built-in Java Layout Managers, I feel that [GridBagLayout](https://docs.oracle.com/javase/tutorial/uiswing/layout/gridbag.html) is the most generally useful, and, further still, most (if not all) of the other built-in layout managers are academic toys rather than useful front-end utilities for all but the most simple of components. There are also 3rd party layout managers that are widely used ([MigLayout](http://www.miglayout.com/) is a commonly used 3rd party layout manager). – Ironcache Jan 31 '18 at 15:07
  • [link](https://docs.oracle.com/javase/tutorial/displayCode.html?code=https://docs.oracle.com/javase/tutorial/uiswing/examples/components/FileChooserDemoProject/src/components/FileChooserDemo.java) I was using this Oracle FileChooserDemo Code to play around with different approaches, in this case BoarderLayout is used. – Miri Jan 31 '18 at 15:16
  • 1
    Yeah this would qualify as an academic example to me. It gets a simple example up and running quickly (and maybe that's okay for you; I can't say for certainty without more knowledge of your specific GUI). But most production-quality front-end applications will not look like you want them to with just `BorderLayout` / `FlowLayout` / etc.. They are good for providing a Layout Manager to individual components as necessary, but do not provide enough fine-grained control to position elements properly. Recommend `GridBagLayout` / `MigLayout` for such things. – Ironcache Jan 31 '18 at 15:20
  • 1
    I would recommend checking the [Layout Managers](https://docs.oracle.com/javase/tutorial/uiswing/layout/visual.html) tutorial to see the difference between managers. I won't sugar coat it; learning to use Layout Managers *properly* is a time investment. **Alternatively**, if you absolutely cannot take the effort to get your GUI code in check (which is the **vastly** preferred option), is there any reason you cannot put your application inside of a panel (with a layout manager that obeys the preferred panel size, such as BoxLayout), and set the preferred size of that panel to 1024 x 768? – Ironcache Jan 31 '18 at 15:35
  • 2
    @Ironcache *"of the built-in Java Layout Managers, I feel that GridBagLayout is the most generally useful"* You seem to be taking the approach of using a single layout for the entire GUI. That is rarely how a GUI would be made. Much more often we [combine layouts](http://stackoverflow.com/a/5630271/418556) as needed for each section of the GUI. ..as I now note you also do in your answer! – Andrew Thompson Jan 31 '18 at 23:12
  • 1
    @AndrewThompson I was worried that that comment was giving the wrong impression. The part where I said "*... **(if not all)** of the other built-in layout managers are academic toys ...*" was far-reaching. What I meant was that certain layout managers give you more control than others. It's kind of like `GridBagLayout` is precision screwdriver set; it can sometimes be more cumbersome than just having the right screwdriver, but (with proper nesting techniques), it can generally do what all the other layouts can do (vica versa not being true, esp. with eg. `BorderLayout` / `FlowLayout`). – Ironcache Feb 01 '18 at 11:39
  • 1
    I ran out of characters in the previous comment (I am beginning to think that I might be just slightly a tad bit too verbose in my method of commenting). I just wanted to add that I also acknowledge that `Border` and `Flow` (and others) have functionality that you wouldn't want to try to emulate with `GridBag`; my point is more that, in the wild, dealing with UI/UX teams, I have found myself faced with specs that tend towards desiring nested `GridBag` layouts more than alternatives. – Ironcache Feb 01 '18 at 11:56
  • 1
    @Ironcache *"(I am beginning to think that I might be just slightly a tad bit too verbose in my method of commenting)"* (chuckle) Yeah comments can be a bit limiting, no? I've done many a 'multi-part comment' myself. But yeah, I think I'm now getting what you meant. – Andrew Thompson Feb 01 '18 at 12:08

1 Answers1

3

As mentioned in the comments, the best approach here is to fix the underlying code to not mandate a 1024 x 768 display. This is usually a very distinct code smell of front-end Java code. Proper use of Layout Managers can almost always get your display to function in a more flexible manner.

However, in industry, sometimes refactoring to get legacy components functioning properly is not a feasible effort. In such a case, I would propose that you treat the inflexible GUI you can't refactor as a component of a larger GUI that you can control.

Consider the following example code:

public static void main(String[] args) {
  // Initialize the frame
  JFrame myApp = new JFrame("App");
  myApp.setSize(1400, 1050);

  // Create container for the GUI
  JPanel container = new JPanel(new BorderLayout());
  container.setPreferredSize(new Dimension(1024, 768));

  // Load the GUI into the container
  JComponent myGui = new JPanel(); // Replace this with actual GUI.
  myGui.setBackground(Color.RED); // Remove this once using actual GUI.
  container.add(myGui, BorderLayout.CENTER);

  // Create the frame's content pane
  JPanel content = new JPanel(new FlowLayout(FlowLayout.CENTER));
  content.setBackground(Color.BLUE); // Also remove this in production.

  // Add GUI to content pane
  content.add(container);

  // Add content pane to frame, show frame
  myApp.setContentPane(content);
  myApp.setVisible(true);
}

This works because we've added the GUI to the CENTER of a BorderLayout panel (which will stretch the GUI to occupy the entire size of the panel in the absence of any components on the NORTH/SOUTH/EAST/WEST). We set the preferred size of that BorderLayout panel to be 1024 x 768 (IE: the size that the GUI is specified to work for), and then feed that panel into a FlowLayout panel (which will preserve the preferred size).

The result is that our 1400 x 1050 application contains a 1024 x 768 rendering of our GUI component (you can easily change this to 1024 x 1050 by modifying the preferred size of the panel containing the BorderLayout).

As an exercise to the user, you'll notice that the GUI code isn't centered vertically if you run this. This can be tackled by modifying the layout of the content panel.

Ironcache
  • 1,719
  • 21
  • 33