MultiWindow versus MWExtWM

[billh]

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/