I second Stefan's suggestion of encapsulating your dialog panel within a scrolled window, and in fact I have made it a habit to implement that for every major toplevel window in all of my GUI software. You never know when an app that was designed for a nice fat desktop display will end up being run on a teeny-weeny laptop. Use the screen dimension discovery functions and the toplevel window size hints to set a maximum size on your toplevel window so that it's always guaranteed to be fully visible, even if the larger embedded scrolled window is only partially visible. You don't ever want to be in a position where your 'Click to Continue' button is completely inaccessable because it's hanging off the bottom of the screen.
Another solution I have used in the couple of odd cases where I was forced to show an especially large dialog, e.g., to configure plot parameters for a rather complex mapping display with dozens of display options, is to group your dialog components into subsets and access each group independently via a secondary dialog window which you display only when the user clicks on an 'Edit Group X Parameters' button in the main dialog.
I'm not a big fan of small font sizes to make things fit -- if you've already got what is practically a fullscreen window filled to overflowing, then making all those widgets smaller is just going to leave you with an illegible mess. Solve your problem through better organization, not miniaturization.
Roger Davis Univ. of Hawaii _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list