Ian Burrell wrote: > > 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.
But one *has* to. Otherwise the "feel" of menus would be wrong (you could click in some parts of the screen without dismissing the menu). > > 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 It would have to know the appropriate MS-Windows look. Because IMHO "seamless" means that you *don't* have to know whether a window is X or 'true MS-Windows'. > and handles moving, resizing, and all that. Wouldn't that be very inefficient; and also prevent things like outline move/resize? > The > X server is responsible of moving the Windows window. > > Does any of this make sense? Perfect sense. > > - Ian > -- > [EMAIL PROTECTED] > http://www.znark.com/ HaND -- Michel Bardiaux Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles Tel : +32 2 790.29.41
