Re: MultiWindow versus MWExtWM
The issues that arose over the six or seven years were various and particular to each application that some customer was dependent upon. One class of problems you could describe as a clash between window managers, Windows and X . This could easily occur for modal popup windows, override redirect, always on top(Windows) and just the general problem of trying to maintain focus in various focus policies that might conflict between the two management styles. Focus fights were fun to watch... Joe Krahn wrote: billh wrote: Any discussion of internal vs external window management cannot take place without acknowledging the fact that we are talking about XWindows operating within another window system, Cygwin/X. The immediate fact here is that any action that a window manager takes that is synchronous to the actions of the clients, such as on an xterm resize, when the window manager may inforce an incremental sizing based on the character width or heighth has to be handled in the window proc of the X server running as a Windows client, otherwise the sequence of events cannot be the same as in a native X Windows environment. In the case of window resizing, the first order solution has the window being resized to any arbitrary size by the Windows window system, and then a second event where an external window manager would resize the window to a size based on window hints registered with the X Window system. Though this can happen very quickly, there are always side effects typically in older programs that are perhaps more reliant on past behavior of X and even in some cases certain window managers. Okay, I'll fess up. I used to work for WRQ on the ReflectionX server. We found that in fact there were financial reasons, meaning enough customers, to support both approaches. Some customers wanted a more Windows centric look and feel and some needed for compatibility reasons an X window manager. I'm not trying to discuss Win32 WM-proxy versus a true X Window Manager. I'm simply comparing how the Win32 WM is implemented. I think most people would prefer using the Win32 WM, if there were no compatibilty problems. (BTW: what types of compatibilyt problems were there?) What I am aiming toward is Windows-managed windows, but proxied in a way that works more like a native X window manager. This means that most of the WndProc handling needs to be handled by "Window Manager" code. That's why I suggested WndProc Hooking. I ported GWM to our environment and my associate Kyle went through the ICCCM documents and made our Windows management mode honor all of that documents guidelines for window management. This gave us both modes at the flip of a switch in the control interface gui. For a commercial product, we could justify both. My idea is that WndProc hooking can allow you to turn the internal WM on or off by adding/removing WndProc hooks (or possibly internal "hooks".) I'm just suggesting that using the external WM approach will simplify the code; it's rather messy right now. THings may have changed, but i tend to doubt it. PS This is offered in the spirit of openness. I am not saying that you should 'go commercial' for your X in Windows needs. Actually I am currently working on a Linux on Windows product that has its own X Server port via a frame buffer driver. Very cool! Don't port your Linux code, run it natively!!! Joe Krahn wrote: What is the history of internal versus external Win32 WMs? It seems that Cygwin/X is favoring the internal WM, even though the external WM is a better fit to the X server design. I was looking into adding some NET_WM/EWMH features (mainly icons for now), and realized that most things have to be done differently on an internal WM, meaning extra work making non-reusable code. The current external WM is implemented using a proper X extension, which might be the source of some problems with the external WM. Maybe an efficient solution for the external WM would be to use WndProc hooks, so that window message passing can be done natively instead of through an X extension. Joe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x
Re: MultiWindow versus MWExtWM
billh wrote: Any discussion of internal vs external window management cannot take place without acknowledging the fact that we are talking about XWindows operating within another window system, Cygwin/X. The immediate fact here is that any action that a window manager takes that is synchronous to the actions of the clients, such as on an xterm resize, when the window manager may inforce an incremental sizing based on the character width or heighth has to be handled in the window proc of the X server running as a Windows client, otherwise the sequence of events cannot be the same as in a native X Windows environment. In the case of window resizing, the first order solution has the window being resized to any arbitrary size by the Windows window system, and then a second event where an external window manager would resize the window to a size based on window hints registered with the X Window system. Though this can happen very quickly, there are always side effects typically in older programs that are perhaps more reliant on past behavior of X and even in some cases certain window managers. Okay, I'll fess up. I used to work for WRQ on the ReflectionX server. We found that in fact there were financial reasons, meaning enough customers, to support both approaches. Some customers wanted a more Windows centric look and feel and some needed for compatibility reasons an X window manager. I'm not trying to discuss Win32 WM-proxy versus a true X Window Manager. I'm simply comparing how the Win32 WM is implemented. I think most people would prefer using the Win32 WM, if there were no compatibilty problems. (BTW: what types of compatibilyt problems were there?) What I am aiming toward is Windows-managed windows, but proxied in a way that works more like a native X window manager. This means that most of the WndProc handling needs to be handled by "Window Manager" code. That's why I suggested WndProc Hooking. I ported GWM to our environment and my associate Kyle went through the ICCCM documents and made our Windows management mode honor all of that documents guidelines for window management. This gave us both modes at the flip of a switch in the control interface gui. For a commercial product, we could justify both. My idea is that WndProc hooking can allow you to turn the internal WM on or off by adding/removing WndProc hooks (or possibly internal "hooks".) I'm just suggesting that using the external WM approach will simplify the code; it's rather messy right now. THings may have changed, but i tend to doubt it. PS This is offered in the spirit of openness. I am not saying that you should 'go commercial' for your X in Windows needs. Actually I am currently working on a Linux on Windows product that has its own X Server port via a frame buffer driver. Very cool! Don't port your Linux code, run it natively!!! Joe Krahn wrote: What is the history of internal versus external Win32 WMs? It seems that Cygwin/X is favoring the internal WM, even though the external WM is a better fit to the X server design. I was looking into adding some NET_WM/EWMH features (mainly icons for now), and realized that most things have to be done differently on an internal WM, meaning extra work making non-reusable code. The current external WM is implemented using a proper X extension, which might be the source of some problems with the external WM. Maybe an efficient solution for the external WM would be to use WndProc hooks, so that window message passing can be done natively instead of through an X extension. Joe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: MultiWindow versus MWExtWM
Any discussion of internal vs external window management cannot take place without acknowledging the fact that we are talking about XWindows operating within another window system, Cygwin/X. The immediate fact here is that any action that a window manager takes that is synchronous to the actions of the clients, such as on an xterm resize, when the window manager may inforce an incremental sizing based on the character width or heighth has to be handled in the window proc of the X server running as a Windows client, otherwise the sequence of events cannot be the same as in a native X Windows environment. In the case of window resizing, the first order solution has the window being resized to any arbitrary size by the Windows window system, and then a second event where an external window manager would resize the window to a size based on window hints registered with the X Window system. Though this can happen very quickly, there are always side effects typically in older programs that are perhaps more reliant on past behavior of X and even in some cases certain window managers. Okay, I'll fess up. I used to work for WRQ on the ReflectionX server. We found that in fact there were financial reasons, meaning enough customers, to support both approaches. Some customers wanted a more Windows centric look and feel and some needed for compatibility reasons an X window manager. I ported GWM to our environment and my associate Kyle went through the ICCCM documents and made our Windows management mode honor all of that documents guidelines for window management. This gave us both modes at the flip of a switch in the control interface gui. For a commercial product, we could justify both. THings may have changed, but i tend to doubt it. PS This is offered in the spirit of openness. I am not saying that you should 'go commercial' for your X in Windows needs. Actually I am currently working on a Linux on Windows product that has its own X Server port via a frame buffer driver. Very cool! Don't port your Linux code, run it natively!!! Joe Krahn wrote: What is the history of internal versus external Win32 WMs? It seems that Cygwin/X is favoring the internal WM, even though the external WM is a better fit to the X server design. I was looking into adding some NET_WM/EWMH features (mainly icons for now), and realized that most things have to be done differently on an internal WM, meaning extra work making non-reusable code. The current external WM is implemented using a proper X extension, which might be the source of some problems with the external WM. Maybe an efficient solution for the external WM would be to use WndProc hooks, so that window message passing can be done natively instead of through an X extension. Joe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
MultiWindow versus MWExtWM
What is the history of internal versus external Win32 WMs? It seems that Cygwin/X is favoring the internal WM, even though the external WM is a better fit to the X server design. I was looking into adding some NET_WM/EWMH features (mainly icons for now), and realized that most things have to be done differently on an internal WM, meaning extra work making non-reusable code. The current external WM is implemented using a proper X extension, which might be the source of some problems with the external WM. Maybe an efficient solution for the external WM would be to use WndProc hooks, so that window message passing can be done natively instead of through an X extension. Joe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
