[Xquartz-dev] some more "white rectangle" behaviour data

[Jeremy Huddleston]

On Dec 5, 2008, at 00:26, Cameron Simpson wrote:

> On 04Dec2008 18:36, George Peter Staplin <georgeps at xmission.com>  
> wrote:
>> Quoted Cameron Simpson <cs at zip.com.au>:
>>> [...] My GF is running 2.3.1 in rootless mode using icewm.
>>> If she leaves her machine she uses fast user switching to go to  
>>> the login
>>> window. On return there are large while rectangles positioned  
>>> where some
>>> former apps used to be. They behave like the X11 root window; her  
>>> X11 root
>>> window context menus function in these areas.
>>>
>>> Restarting the window manager gets rid of most of these white  
>>> rectangles;
>>> the ones that remain appear (loosely) to be associated with things  
>>> like
>>> the mozilla/seamonkey URL bar and the URL completion drop down etc.
>>
>> Those sound to me like windows with the override_redirect attribute  
>> set
>> to True.  In which case the problem is probably not with quartz-wm,  
>> but
>> rather with the X11 server, or Xplugin that the X11 server uses.
>
> As mentioned, quartz-wm is not running.
>
> The large windows are related to conventional app windows. If you're
> talking about those that remain after WM restart, yes, seems  
> consistent.

I've seen it going in and out of fullscreen, others have talked about  
it happening with FUS or hiding.  The common code point there is in  
hiding the windows.  Further, all the windows that I've seen exhibit  
this behavior and have been reported to show this have been override- 
redirect windows (menus, tooltips, and other "undecorated" windows)

> It rings a bell with me too.
>
> I'm also wondering if these windows are the apple-land windows that I
> imagine must get made to render the rootless X11 top level windows.

They are.

> The override redirect is then a slight red herring. Suppose that these
> rectangles are the apple-land windows for top level rootless windows,
> devoid of the interior X11 app scribbling. It looks like the X11  
> server
> loses track of some of them when an X11 app closes the window, or if  
> the
> app exits and the server has to clean up.

Yeah, that's what it looks like.  This happens with no WM running at  
all.  override-redirect is nothing special inside the server.  It's  
really only used to tell the WM "hey, leave this alone".

> My own 2.3.2rc1 setup is configured for full screen mode. I seem to  
> get
> window associated with apps that are made before the WM starts. So  
> if I
> start an X11 app and the X server is started as a side-effect then  
> there
> tends to be a big white rectangle in apple land where the app starts.
> Click on it and the full screen X11 desktop appears. Interestingly,  
> the
> white rectangle is visible inside X11 too.

hmm...

> A short experiment now, as I type this, shows that the "Click on it
> and the full screen X11 desktop appears" is an effect of apple land  
> app
> focus change - it only happens if the focused apple app is not the X11
> server. If X11 has the focus (enter X11, option-command-A out of full
> screen mode) then clicking on the big white apple land rectangle is  
> just
> a bit of X11 root window - my FVWM root context menu shows up and I do
> not re-enter full screen X11 mode.
>
> A restart of my WM also removes the apple land large white rectangle.
> The inside-X11 white rectangle is still there. It is above the root  
> window
> (shown by an "xsetroot -solid blue" leaving it untouched) and below  
> the
> X11 apps (shown by moving them around). It does behave as root window
> context, so I presume mouse clicks are caught by it or fall through.
>
> [Flips back and forth a little..] Argh. The big white rectangle is
> visible in apple land again - same size and place.
>
> I can perform other experiments if you can suggest something  
> specific to
> test.

Yeah, the common code point in all of this is the X11 window being  
hidden and Xquartz still rendering it (albeit empty) to an OSX  
window.  Unfortunately, almost all of my work thus far has been on the  
input side of things, so I'm not too familiar with that code.  But,  
all of my showstoppers for 2.3.2 are cleared up, so I'll dig into that  
while waiting on some more GLX updates from George.