Re: XRaiseWindow for activating windows in multiwindow mode

[Oliver Schmidt <oschmidt-mailinglists at gmx dot de>]

Hi Jon,

On 03/09/11 21:01, Jon TURNEY wrote:
> There definitely are some problems in this area, but I'm not sure this is the 
> 'correct' fix, though.

yes, it's some kind of workaround, but it works and is very useful for
may daily work. At least the patch is very defensive, it just raises top
level windows that should be on top over all other top level windows
(i.e. have no previous sibling).

Some programs become unusable if programmatically raised windows are not
raised. Of course it would be better if the cygwin multiwindow mode
would react on window manager messages, i.e. atom "_NET_ACTIVE_WINDOW"
for raising windows.

> The code as it stands is the product of some ... erm ... historical compromises.

I tried to left it mostly at it is, but yes, one can see that the coding
at this point is a little bit "historic", especially the #if 1...#else
block later on in the function winRestackWindowMultiWindow....

> this out.  The code which perhaps would do this is in the disabled branch of 
> the #if/#else/#endif in winRestackWindowMultiWindow()

yes, I had the same thoughts about it, but I didn't get it to work with
this uncommented code. At least this uncommented code does not invoke
SetForegroundWindow, so I doubt that it would raise windows under all
conditions.

> The relevant thread seems to be [2] and the relevant change seems to be [3], 
> but I can't reconstruct the reasoning behind it.
> 
> As discussed in the thread [2] various scenarios, e.g. AOT windows, native 
> windows interleaved with X windows in the native Z order, Windows with 
> focus-follows-mouse enabled via TweakUI all need testing after trying to fix 
> this, to ensure you haven't regressed them.

yes, is there any one here on this thread that uses these features and
can confirm that they are still working with the patch?

> I'd like this patch more if you said why recursive calls can occur,
> and why they must be avoided.

This was not my idea: it's just copied code from the function
winReorderWindowsMultiWindow, so the reasons for avoiding the recursive
behaviour are the same reasons that apply to existing code.

The patched function winRestackWindowMultiWindow invokes the function
winReorderWindowsMultiWindow in the #if 1 code block.

So my idea was to move this lock a little bit higher, because with this
patch critical work is done in the invoking fucunction
winRestackWindowMultiWindow now.

The recursive behaviour did occur in my testing, so this condition
testing for avoiding recursive behaviour was necessary in the existing
code and is also necessary for the patch. I think that the recursice
behaviour occurs because changes on the top level windows with native
Windows-API-Calls are leading to native Windows messages that again are
fed into the x server and are leading to the funcion
winRestackWindowMultiWindow. But this is only a theory, it is very
difficult to find theses things out under cygwin, because stack traces
via function "backtrace" from <execinfo.h> and "addr2line" are
unfortunately not possible with cygwin :-(

At least I'm happy now with my patched cygwin x server and I'm using it
every day now ;-)

Best regards,
Oliver

--
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/