|
From: | Vivek Dasmohapatra |
Subject: | bug#22000: Patch addressing the menu-bar frame-resize interaction |
Date: | Wed, 18 Jul 2018 11:39:12 +0100 (BST) |
User-agent: | Alpine 2.02 (DEB 1266 2009-07-14) |
suppose we used a non-scrolled container window to put the menu bar in, get its size before updating the menu bar, update the menu bar and make a gtk_widget_set_size request for that container window to restore its previous size. Would that fail and why?
Depends on the behaviour of the container. The menu bar gets poked to emit its size from time to time by an internal gtk callback so if the container respects its wishes it will pop back to the larger size semi-predictably (this behaviour can occasionally be seen in the currently released emacs as that's how the hbox behaves). So we'd need a container that didn't grant such space requests. gtk fixed is close, but from its documentation has other limitations we don't want (no RTL support). You can turn scrollbars off in a scrolled window but unfortunately this results in the scrolled window responding to size allocation requests from its child.
[Prev in Thread] | Current Thread | [Next in Thread] |