Michel Bardiaux wrote: > > Aye, there's the rub. When the X application pops up a menu, it must > grab the keyboard and the *whole* screen. In other words, a "system > modal" window is required, which means one can't use an internal WM but > must use MS-Windows as WM - while still being responsive to ICCM. >
Does the menu need to be truly modal on the Windows side? The menu window has the focus so it will get keyboard events. It can be modal with respect to all the other X server-owned windows. It is harder to make it modal relative to Windows. Just to make sure we are using the same terms, what I mean by an internal window manager one running inside the X server. I am taking my cue from the eXcursion2 design document. Windows is generating the move, resize, etc events. The window manager hooks into the X server Windows event loop and handles window state events. The internal window manager should act as proper window manager which presumably means talking to the server. The other way I can see to handle a rootless X server is with a separate X client window manager. For each root-level X window, there is a corresponding Windows window. But without any frame at all. The window manager draws the frame and handles moving, resizing, and all that. The X server is responsible of moving the Windows window. Does any of this make sense? - Ian -- [EMAIL PROTECTED] http://www.znark.com/