[Xquartz-dev] override-redirect problems

Jeremy Huddleston jeremyhu at apple.com
Fri Oct 17 16:30:25 PDT 2008


>> Yeah, but this fails due to async:
>>
>> 1) Click on the File menu
>> 2) Activate xterm
>> 3) file window is mapped and now child of xterm
>
> I'm not clear on how to do this. In which app do you click on the File
> menu, and then how do you activate xterm?

I'm just describing a series of events where it is possible for you to  
send a mouse click event to nedit, then raise the xterm window before  
nedit actually registers the mouse click and maps the menu window.


>>> If (b), and you don't want to re-use any of the existing Window
>>> fields, devPrivates is an option.
>>
>> This needs to be something the WM has access to...
>>
>> I think what I might just do is always move the window to the
>> current space when it is ordered in if it is override-redirect.
>
>
> This exposes my ignorance of how OS X menus and windows work with
> Spaces and how X windows interact with them...
>
> In the Ubuntu/GNOME multiple workspaces, as well as older Mac OS 9
> workspace apps, the physical screen is kind of a window onto a much
> larger canvas. And the way you switch workspaces is to move the canvas
> around by traversing the window list and moving all the windows by a
> uniform offset so the ones you want to see are visible on-screen and
> the rest are somewhere else. (There's more to it than that - lots of
> bookkeeping and exceptions, but that's the gist.)
>
> Is that how Spaces works, or is something else going on?

The problem is that when we order in a window that was ordered out on  
another space, it is automatically ordered in on that original space.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3221 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20081017/80bbc0d9/attachment.bin 


More information about the Xquartz-dev mailing list