Re: [SOLVED] Re: different window raise behaviour with xquartz under twm and icewm
Re: [SOLVED] Re: different window raise behaviour with xquartz under twm and icewm
- Subject: Re: [SOLVED] Re: different window raise behaviour with xquartz under twm and icewm
- From: Eeri Kask <email@hidden>
- Date: Wed, 25 Dec 2013 13:35:04 +0100
On 25.12.13 02:27, Cameron Simpson wrote:
>>> Possibly, although my guess would be XRestackWindows(). This probably slaps
>>> all X11 windows into the same "layer" relative to Aqua windows, and
>>> probably does *not* relocate that layer to the top of the OS X window
>>> stack. XRaiseWindow() is more likely to raise an individual window over
>>> other windows, X11 or Aqua.
>>
>> Your guess is correct. Icewm appears to maintain a data structure
>> of lots of window layers; a "raise" manipulates this structure and
>> then calls wmmgr.cc's restack method which assembles a call to
>> XRestackWindows().
> [....]
If I understand XRestackWindows() documentation correctly then it
appears icewm raises windows by lowering certain other windows; this
strategy apparently fails on systems with multiple concurrent windowing
environments like Aqua and X11 in this case (because there are always
Aqua windows out of X11's reach which have to be lowered too?).
Twm's f.raiselower obviously doesn't "work" too if there are no other
X11 windows obscuring the affected window, i.e. the affected window is
not raised ontop of Aqua windows if it accidentally is not obscured by
some other X11 window ... but in contrast, f.raise _does_ work, i.e. the
affected X11 window is raised ontop of all Aqua windows, even if it
already is on top of X11 window hierarchy! How that? :-)
Maybe include your tweak beween
#ifdef __APPLE__
...
#endif
and send them a "fix"?
Eeri Kask
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden