diff options
| author | Simon Tatham <anakin@pobox.com> | 2012-11-20 20:05:27 +0000 |
|---|---|---|
| committer | Simon Tatham <anakin@pobox.com> | 2012-11-20 20:05:27 +0000 |
| commit | 2a2520b8e7985242d0e970d8db0eff06d8657d34 (patch) | |
| tree | 7a5fcfcf4e45b6d9adf844d0c388cb2f38232b3d /pattern.c | |
| parent | 083aeafc5ca8fdf753b987c58b805108f5a9732b (diff) | |
| download | puzzles-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