aboutsummaryrefslogtreecommitdiff
path: root/pattern.c
diff options
context:
space:
mode:
authorSimon Tatham <anakin@pobox.com>2012-11-20 20:05:27 +0000
committerSimon Tatham <anakin@pobox.com>2012-11-20 20:05:27 +0000
commit2a2520b8e7985242d0e970d8db0eff06d8657d34 (patch)
tree7a5fcfcf4e45b6d9adf844d0c388cb2f38232b3d /pattern.c
parent083aeafc5ca8fdf753b987c58b805108f5a9732b (diff)
downloadpuzzles-2a2520b8e7985242d0e970d8db0eff06d8657d34.zip
puzzles-2a2520b8e7985242d0e970d8db0eff06d8657d34.tar.gz
puzzles-2a2520b8e7985242d0e970d8db0eff06d8657d34.tar.bz2
puzzles-2a2520b8e7985242d0e970d8db0eff06d8657d34.tar.xz
Work around an annoying GTK behaviour I noticed the other day on my
Ubuntu 12.04 machine. What seems to happen is that we set up a window containing a menu bar, a drawing area and a status bar, and set the size of the drawing area; then the window is displayed _without_ the menu bar; then we reduce the drawing area's size request to (1,1) to let the user resize the window smaller; and now GTK gets round to constructing the menu bar, and the drawing area helpfully shrinks a bit to make room for it. My fix is to set a 'shrink pending' flag instead of shrinking the drawing area's size request, and defer the actual shrink operation until the menu bar and status bar are both present. [originally from svn r9711]
Diffstat (limited to 'pattern.c')
0 files changed, 0 insertions, 0 deletions