>>>> "sjt" == Stephen J Turnbull
sjt> What *should* happen is that in the case of a WM-driven
sjt> resize, size changes should propagate unidirectionally
sjt> downward via widget Resize methods. Parents may
sjt> XQueryGeometry their children, but then they *command* the
sjt> resize they think best via Resize. Children must never
sjt> XtConfigureRequest their parents. That latter is what I'm
sjt> afraid is happening, in EmacsManagerChangeSize, called from
I've confirmed that this happens, and that the request does propagate
up to the window manager (in my case at the moment fluxbox). I can
see the WM resizing XEmacs's frame at the expect places while
single-stepping through those functions.
Simply preventing EmacsManagerChangeSize from calling XtResizeRequest
leads to an infinite loop; apparently x_layout_widgets wants to force
things, and until its idea of what is right corresponds to the widget
it's looking at, it keeps trying to resize. I don't know exactly
what's happening yet and I'm out of time for several days.
sjt> It is true that EmacsFrameResize always does a
It is possible to inhibit this, with no huge ill-effect on XEmacs
functionality. I'm supplying a patch, with this action controlled
from Lisp by the variable `wedge-metacity', defaulting to nil.
If people who observe the problem could
(1) Confirm that in their current build the still get the
jitter/infloop (yeah, I know it happened just a few minutes ago; humor
me, this behavior seems to depend on all kinds of magic and karma).
(2) Apply the patch, rebuild, restart XEmacs and try maximizing then
unmaximizing the XEmacs frame. I'm sorry, I don't have much hope that
this will actually make metacity happy (since we know that XEmacs is
calling XtResizeRequest via EmacsManagerChangeSize), but who knows?
If it *does* prevent the jittering behavior, then
(3) M-: (setq wedge-metacity t) RET and see if the jitter returns.
diff --git a/src/EmacsFrame.c b/src/EmacsFrame.c
index 0dfae44..53c2a98 100644
＠＠ -365,7 +365,7 ＠＠ EmacsFrameResize (Widget widget)
of EmacsFrameSetCharSize(), this information will be stored twice.
This is not a big deal, as storing this information doesn't actually
do anything until the next resize. */
- if (FRAME_X_TOP_LEVEL_FRAME_P (f))
+ if (wedge_metacity && FRAME_X_TOP_LEVEL_FRAME_P (f))
x_wm_set_variable_size (FRAME_X_SHELL_WIDGET (f), columns, rows);
/* Kick the manager so that it knows we've changed size. */
diff --git a/src/console-x-impl.h b/src/console-x-impl.h
index 765ad0a..843b04f 100644
＠＠ -40,6 +40,8 ＠＠ Boston, MA 02111-1307, USA. */
+extern int wedge_metacity;
diff --git a/src/console-x.c b/src/console-x.c
index a164735..e95d9a1 100644
＠＠ -41,6 +41,8 ＠＠ Boston, MA 02111-1307, USA. */
+int wedge_metacity; /* nonzero means update WM_HINTS always */
extern void x_has_keysym (KeySym, Lisp_Object, int);
＠＠ -399,6 +401,22 ＠＠ console_type_create_x (void)
CONSOLE_HAS_METHOD (x, perhaps_init_unseen_key_defaults);
+ DEFVAR_BOOL ("wedge-metacity", &wedge_metacity /*
+When non-nil, all frame resizes, XEmacs-initiated or not, update WM_HINTS.
+Otherwise only update on XEmacs-initiated resizes. Resizes initiated by
+the window manager will not update WM_HINTS.
+This is backward-compatible behavior.
+The default is nil. This probably gives correct behavior regardless of the
+window manager used. Setting non-nil causes some versions of metacity, and
+perhaps other window managers, to jitter between truly maximizing the frame
+and using the nearest approximation giving an integer number of character
+cells in the text area.
diff --git a/src/emacs.c b/src/emacs.c
index 35ea6b4..0f7585c 100644
＠＠ -2186,6 +2186,7 ＠＠ main_1 (int argc, Wexttext **argv, Wextt
+ vars_of_console_x ();
diff --git a/src/symsinit.h b/src/symsinit.h
index 51ba077..0e44626 100644
＠＠ -306,6 +306,7 ＠＠ void reinit_vars_of_console (void);
void vars_of_console_stream (void);
void vars_of_console_mswindows (void);
void vars_of_console_tty (void);
+void vars_of_console_x (void);
void vars_of_data (void);
void vars_of_database (void);
void vars_of_debug (void);
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.