anthony> Should it be expected to work? Nothing in GTK builds should be relied on to work. It's officially experimental. Anything that involves taking out widgets from GTK builds should probably be expected to fail, because the whole purpose of GTK is maximizing the flash'n'trash on your screen. No thought at all has been given to removing them as far as I know. anthony> The only reason I really would like to do this is that anthony> I'd like to avoid the excessive geometric contortions anthony> that xemacs appears to go through in sizing the main anthony> window. Changing the default face, hiding the toolbar, anthony> and various other tweaks all appear to be executed after anthony> the main window has been mapped. That may be an unforutnate side-effect of the generic widget support. We used to have a highly optimized redisplay based on the assumption that there really was only a very few important widgets getting updated at any given time, the text pane, the scrollbars. Tool bars and even menus generate relatively few events. But with more and more widgets cluttering the frame, things have gotten more complicated and the optimizations not only don't speed things up, they result in parts of the display failing to update at all. So we've been systematically generating more and more X protocol activity. One thing I would like you to try is Kirill's redisplay preemption patch. Search the XEmacs patches archive http://list-archive.xemacs.org/xemacs-patches for "preempt". It was in spring or early summer of this year IIRC. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.