MultiWindow versus MWExtWM

[Joe Krahn]

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/