At 11:57 AM 3/19/00 -0500, William M. Perry wrote: Cool! I think this would work well for toolbars but not so well for menubars (I'm thinking of the mswindows implementation here). You would also need to implement 3d buttons under athena if you were to replace the toolbar implementation. You would also gain the ability to have several rows of toolbars which is standard for many mswindows apps. However I would advocate running the two side-by-side at least for a couple of releases. Also I would take the mswindows gui code as a template for this and try and get away from using lwlib at all. I guess this depends on how like Intrinsics the API is. I would not advocate rewriting lwlib, it is far too fragile in my experience. But yes in principle this would work and would be much more flexible than what we have at the moment. I would be interested in critiquing any design docs you produce ... andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

Hi Bill, You wrote to me awhile ago about this and asked about documentation, and I dictated a response but never got it sent, so here it is: I don't think there's any more documentation on how things work under Xt but it should be clear. The EmacsFrame widget is the widget corresponding to the X window that Emacs draws into and there is a handler for expose events called from Xt which arranges for the invalidated areas to get redrawn. I think this used to happen as part of the handler itself but now it is delayed until the next call to redisplay. However, one thing that you absolutely must not do is remove the Xt support. This would be an incredibly unfriendly thing to do as it would prevent people from using any widget set other than Qt or GTK. Keep in mind that people run XEmacs on all sorts of different versions of X in Unix, and Xt is the standard and the only toolkit that probably exists on all of these systems. Pardon me if I've misunderstood your intentions w.r.t. this. As for how you would implement GTK support, it will not be very hard to convert redisplay to draw into a GTK window instead of an Xt window. In fact redisplay basically doesn't know about Xt at all, except in the portion that handles updating menubars and scrollbars and stuff that's directly related to Xt. What you'd probably want to do is create a new set of event routines to replace the ones in event-Xt.c. On the display side you could conceivably create a new device type but you probably wouldn't want to do that because it would be an externally visible change at the Lisp level. You might simply want to put a flag on each frame indicating what sort of toolkit the frame was created under and put conditions in the redisplay code and the code to update toolbars and menubars and so forth to test this flag and do the appropriate thing. "William M. Perry" wrote: Read what I've written in Architecting XEmacs about dialog boxes -- I describe a similar but even more general scheme, that makes *all* frame layout be controllable in Lisp, i.e. an Emacs "window" is just another widget just like menubars, toolbars, scrollbars, etc. If you're going to rehash this stuff you might as well go whole hog in your implementation. (As far as I know, you can already do this with toolbars ...) -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.