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: Cameron Simpson <email@hidden>
- Date: Thu, 26 Dec 2013 10:53:15 +1100
On 25Dec2013 13:35, Eeri Kask <email@hidden> wrote:
> 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?).
In a sense. I believe an XRestackWindows() call manipulates windows
in the X11 window hierachy but the X11 server doesn't muck with
their (existing) relationship to the Aqua "app level" window hierachy.
I can understand that.
One test of your "lowering certain other windows" hypothesis would
be to get one X11 window above some Aqua app windows, and then
"raise" an obscured X11 window. Under your hypothesis the other
window, already above some Aqua windows, might drop below.
XRaiseWindow() seems to do an outright Aqua level raise, which is
very desirable/fortuitous.
> 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
Have you tested this? Just asking. I must try it sometime.
> ... 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? :-)
Well, some X11 apps want to raise "alert" or "important" windows
to the top to show them to the user. IIRC xterm and some others
have a raise-on-bell option. It would be way annoying if that didn't
work with respect to Aqua windows (for users relying on that behaviour
in X11-land).
> Maybe include your tweak beween
> #ifdef __APPLE__
> ...
> #endif
> and send them a "fix"?
I'm intending to do that. Is "__APPLE__" a documented reliable feature macro?
I still have to tweak things a little first.
One side effect of my hack is that the raise aterm is now above the
TaskBar, and also above the one-pixel sensitive area utilised to
expose the Taskbar for autohiding taskbars. This breaks the GF's
raise/show-the-taskbar idiom of just moving the pointer into the
Apple toolbar (which sticks the logical X11 cursor at the top of
the rendering area, thus reliably leaving it in the raise-the-taskbar
zone - no need to aim carefully at a very thin strip).
So at the least I should be XRaiseWindow()ing those too.
Icewm's restack method has a very clear list of stuff that needs
to be raised in addition to the stock layers, so I need to review
it and XRaiseWindow() a select few items after the main XRaiseWindow().
Cheers,
--
Cameron Simpson <email@hidden>
You try and make the place as secure as you can, but you don't reckon
with the kind of people who try and break into an explosives factory
with an oxy-acetylene torch.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden