Best practices to have portable GUI appearance on controls?

Share icon

What are the recommended best practices to put together a control panel where the controls are to be immediately portable in relative appearance between macOS and Windows systems? What combinations of DefaultGUIControls and DefaultGUIFont are recommended as settings *localized solely to the control panel*?

I don't have answers, but one consideration is whether the panel will fit on the screen. There are some pointers to how to deal with this in an earlier discussion. Resizable panels are great, but must be initially rendered small enough to fit on the screen.

DisplayHelpTopic "Resize Controls Panel"

I too would like to have some guidance on how to choose font sizes and whatnot so that there are no unpleasant surprises when a panel is created on a computer with different display settings.

May 7, 2020 at 01:46 am - Permalink

My experiences suggest that two guidelines are important during development.

  • You can develop a control panel that can appear somewhat consistent in its layout for both macOS and Windows, but you still have to test your control panel on both platforms. You cannot just rely on faith or even a best-practices guideline. For example, you will need to review because you may have inadvertently chosen a font face on one OS that is not compliant on the other or you may have set the positions and sizes too tightly for the one or the other OS.
  • Regardless of the OS, you also have to establish whether the control panel will have alower bound for screen size / resolution settings. For example, a large panel that fits on a 24in quad-resolution monitor will not necessarily fit well or at all on a 12in laptop screen at sVGA-resolution.

The DefaultGUIControls and DefaultGUIFont operations seem to help to avoid issues in the first case. They also eliminate the need to include an fSize flag on each panel control operation. What I still need to appreciate are the trade offs when using different settings for {font face, font size, font style}.

I am still struggling with how to address the monitor size/resolution issue. I think here we might benefit by having a "rule of thumb" that involves the ratio of panel size to monitor size and/or resolution. For example, suppose you create a panel that is 6cm tall on a monitor running at 1080p. What advice should you give to a user who wants to run your package on 14in ~ 16in/10in ~ 20cm high laptop at 1366x768 native resolution? I have to think that we could use some code to cross-correlate this information, e.g. cross-checking the panel height or width against the current IgorInfo monitor settings and giving the user a warning when the settings going to be unworkable.

May 7, 2020 at 08:05 am - Permalink

Maybe the best answer would be one pointing to a recent demo, included in Igor 8, and recently programmed to have an amazing GUI?

I don't know one, though.

May 11, 2020 at 10:52 pm - Permalink

Perhaps "amazing" is a stretch. I'm after a basic level of consistency in appearance.

I've got the GUI font issues resolved EXCEPT for the text in pop menus. Apparently, the text for popup menu lists is handled by the OS itself. So, when a Windows user changes the font magnification from 100% to 125% on the overall system, the size of the popmenu fonts will change but all other font sizes will not. Not good.

In the meantime, to handle the screen size problem, I include this code (e.g. in my Image Tools package) ...

Static Constant k_minscreenh = 600

Function init_CreateGUIs()

    string scrwarning = "This package can only be used on a screen with a minimum height of " + num2str(k_minscreenh) + " pixels. Change your screen resolution and try again."
   
    if (init_CheckScreen() < 0)
        DoAlert/T="Screen Too Small" 0, scrwarning
        return 0
    endif

    // code here to start package
    ...
       
    return 0
end

// check screen height
Function init_CheckScreen()

    variable rtn = 0, nitems, sheight
    string sinfo
   
    sinfo = StringbyKEY("SCREEN1",IgorInfo(0))
    nitems = ItemsInList(sinfo,",")
    sinfo = StringFromList(nitems-1,sinfo,",")
    sheight = str2num(sinfo)
   
    if (sheight < k_minscreenh)
        rtn = -1
    endif
   
    return rtn
end

 

May 12, 2020 at 10:23 am - Permalink

Igor 9 will have a "panel expansion" factor that can expand or contract panels and controls.

The feature is still in development, but is basically as simple as ModifyPanel expand=1.25.

There will be a global default in Misc Settings so you can leave the recreation macros alone and they'll be automatically adjusted.

The idea is the user of a small-screen computer could set the global default panel expansion to 0.75, for example, to make the panels fit their small monitor, and those of us who are older may choose to set the global default expansion to 1.25 to make things just a little bit bigger.

This way GUIs can be designed at the nominal expansion of 1.0, and the user gets to decide how big or small the panel is.

May 12, 2020 at 10:27 am - Permalink

> ... and those of us who are [older] may choose to set the global default expansion to 1.25 to make things just a little bit bigger.

Interestingly, it is the need that my [younger] graduate student had to set his control panel on his Windows laptop to a huge size that got me started here. I am quite happy having my Retina MBP display set to a notch higher than normal (with more content on the screen but at smaller sizes throughout).

The new panel scaling approach sounds very nice indeed!

May 12, 2020 at 02:31 pm - Permalink