GUI written without GUIDE: How to make sure layout remains consistent across different displays (different resolutions)?

Hello everyone. I have written a GUI programmatically, i.e. elements are arranged and placed using pixels as positioning tools. However, this becomes a problem when switching displays, since not all displays have the same resolution. Consequently, some elements are moved out of place. Is there a way to correct for this?

It is not a problem with elements, like axes, that can be placed with normalized positions because those automatically adjust with changes in pixels. Is there a way to do this for any GUI element? Thanks!

Answer 1

[Walter Roberson]

figures and all uicontrols and uipanel can be placed by normalized units. Be sure to specify the Units before the Position.

Fonts, on the other hand, are absolute sizes (points), so when you move to a smaller display text can come out too big for the area you allocated. Accounting for this often requires that you allow a variable-sized area and use the textwrap() function. Key trick: if you put text inside a text control and then ask for the Extent property of the control, the result will be how wide the control would need to be to include all of the text. You will find yourself writing a routine that tosses the desired text into a temporary (invisible) control just to find out how big of a space you need for it so you can determine the Position to use for your real control.

Once you start allocating variable amounts of space for text areas, you will need to start positioning (and sizing) your other controls relative to those spaces. In combination with the fact that it's a real pain to program human-readable position information in normalized units, this will likely lead you to start writing layout routines, especially to position a box to the top right side of another box, and to position a box to the left and underneath another box. You may occasionally need to position in other relative coordinates.

Note that it is not just for different resolutions that you might want to do this. You might also want to do this if you offer the user a choice of fonts or font sizes.

[sicilian27]

Thank you very much Walter! Changing the elements to normalized units helped a lot. And I also looked through the documentation on the TEXTWRAP function. It looks like it could be helpful. However, is there really no way to set the text to be a variable size so that it changes with the display? Or is it really necessary to design the layout around the absolutely-positioned text spaces (i.e. labels)?

Additionally, is there a way to make all of the cells in a table move with the display? I set the table itself to normalized units, but the cells don't appear to move with the border of the table when it is altered. Thanks again!

[Walter Roberson]

Well I'll be... uicontrol allow FontUnits 'normalized':

If you set this property to 'normalized', then MATLAB interprets the font size as a fraction of the uicontrol height. When you resize the uicontrol, MATLAB scales the displayed font to maintain that fraction.

And that's fine if you don't mind that on smaller screens the text might become too small to comfortably read.

For this matter there are a couple of different notions of "resolution" that you need to be aware of:

• DPI, dots per inch. The physical density of the pixels.
• number of rows and columns of pixels
• physical size of display
• information density
• position accuracy

On LCD displays, dpi was often given as 75 dpi or 100 dpi even when the physical size varied and the number of pixels stayed the same. Although in theory the DPI and number of pixels together should be enough to calculate the physical size, in practice the DPI figures were only approximations and objects sized for the same reported DPI and same reported rows and columns, would come out very different sizes.

Apple's Retina display is roughly 220 dpi for their OS-X devices, roughly 320 for some of their iPad mini, and as high as 401 for the iPhone 6 Plus. With 1 point = 1/72 inch, 75 dpi is pretty close to 1 pixel per point, so "12 point type" would be about 12 pixels, 1/6 of an inch on 75 dpi devices. At 100 dpi, 12 pixels is about 1/8 of an inch. At 220 dpi, 12 pixels is about 1/18 of an inch; at 326 dpi, about 1/26th of an inch. But even if you are up quite close, you can't read text that is 1/26th of an inch. Choosing a text font size in pixels is thus going to fail. Likewise if you choose the font size in pixels and take it to a low resolution display (whether physical or a high resolution one set to emulate lower resolution) then the characters are going to become larger than is pretty

I seem to require an afternoon nap at this point, so I will continue later.

[Walter Roberson]

Sometimes a physically larger display means larger pixels with the same number of rows and columns, and sometimes a physically larger display has about the same pixel density but more rows and columns. If one makes figures (or sizes of objects) a proportional width of the screen then one runs the risk of making objects larger than they need to be, when instead one should be presenting more information or should be leaving the window narrower so that the user can be doing other things with their screen at the same time (e.g., referring to the graph while writing code or writing a paper.)

Consider a web browser: if you grab a browser window and pull it smaller, sometimes what you want is for something (e.g., graphics) to stay fixed size and a scroll bar to appear (if needed), and sometimes what you want is for text to stay the same size but to "flow", narrower columns with more rows. Which reminds me: another reason to use programmatic layouts is to allow the user to resize the window. Programming for a fixed width is poor user experience on multipurpose devices.

Sometimes with higher density displays what you want is to be able to write smaller without pixelation or draw finer lines, to be able to present more information in a given physical space. But sometimes your purpose is to be able to present the elements more accurately or precisely, like smoother anti-aliasing, more natural looking curves, or better kerning.

Generally speaking, then:

• as pixel density changes and as allocated row and column pixels change (different display, or user resizes window), people usually want text characters to maintain a relatively constant viewing angle; in the case of consistent viewing distance that translates to a relatively constant physical width. The preferred angle will depend upon the user and may change with time (e.g., I have been having difficulty with my eyes lately and need larger text.) If the width you have allocated for the text is not enough, you can truncate the text, or you can put in a scroll bar, or you can flow or wrap the text. (There is a whole study of hyphenation rules for breaking words "nicely"!)
• for plots, the most common desired behavior is to rescale to fit available space, with zoom and pan potentially enabled. But sometimes that just loses too much detail and you want to go for a larger presentation and scroll-bar
• for images, the choice tends to depend more on context. Scaling images to fit the available space is not at all unusual, and is typical for viewing photographs for enjoyment or for using an image as a design background. But wanting to view images at full resolution, one image pixel per screen pixel, is not unusual, and for image editing work wanting to zoom images is par for the course. Viewing an image "full-screen" is common, in which case the other controls and border decoration should "get out of the way". Especially for cases where the user has choice of images, you need to decide ahead of time which viewing mode you are employing and make provision for the major alternate mode. When there is an image with scroll-bars, people generally expect that if they make the containing window larger, that more of the image will become visible rather than the same portion of the image will be visible but drawn with larger pixels. Until, that is, the whole image is visible, after which they might expect magnification, but not necessarily...

What humans "expect" is not always easily quantified, and can depend on context and mood. But as they go for "larger" or "smaller" screens (or windows), the expectation is seldom for a pure magnification such as would be achieved by programming everything in normalized units.

[sicilian27]

Thank you so much Walter for your fantastic answers! Your suggestions were immensely helpful, and your comments gave me so much to think about with the layout of my GUI. It definitely made me consider new layout options or problems that I hadn't before, so thank you for that!

I think I will provide my users with a few more options now and add certain restrictions to other graphical elements. Additionally, normalization made a huge improvement. Thanks again!