Re: XRaiseWindow for activating windows in multiwindow mode

2011-09-04 Thread Oliver Schmidt 
some additions to my last mail:

On 04/09/11 10:52, Oliver Schmidt wrote:
 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,

After looking again at the code, I must correct my above statements: now
I think, that it's not the native Windows function SetForegroundWindow
that is calling the recursive behaviour.

It's still the already existing code in the function
winReorderWindowsMultiWindow that is causing recursive behaviour: in
this existing code the function ConfigureWindow is invoked (this is not
a native Windows function, it seems to be some x server function). So
the invocation of this function is triggering the x server to invoke
winRestackWindowMultiWindow recursively.

But these are still theories. At least the recursive behaviour is not
introduced by the patch, it was already there in the existing coding ;-)

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/

Re: XRaiseWindow for activating windows in multiwindow mode

2011-09-04 Thread Oliver Schmidt 
It's me again ;-)

On 9/3/2011 9:01 PM, Jon TURNEY wrote:
 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.
 
 [2] http://sourceware.org/ml/cygwin-xfree/2004-03/msg00540.html

I'm not sure if I'm correctly reproducing the above usage scenario
always on top, but I did the following under Windows 7 and XP:

1) downloaded and installed http://www.abstractpath.com/powermenu/
2) launched a xclock or a native Windows program (e.g. Internet
Explorer) and select Always on top with right mouse click on the
window's titel bar
3) programmatically launched and raised other x top level windows
4) Everything works: the checked windows stay top level, the
programmatically raised windows became top level amongst all other non
always top level windows and get keyboard focus and activated window frame.

I was also able to minimize and restore the always on top window
without any problems. Moreover the redraw windows while moving and
sizing hack
 http://www.cygwin.com/ml/cygwin-xfree/2011-08/msg00049.html
does also work with the always on top feature enabled for the
foreground and background window. Also mixtures of cygwin x server
windows with native Windows applications all with always on top
feature enabled are working.

What is not working: Clicking on minimize to tray on a cygwin x server
window that has also the always on top feature: this causes the window
frame to vanish, but the window content is still redrawn by the xserver
on the underlaying x11 window. This is difficult to describe, but this
does also not work with the official unpatched cygwin x server 1.10.3-1.
This minimize-to-tray effect for always on top windows is also
described here:
http://sourceware.org/ml/cygwin-xfree/2004-03/msg00540.html

So according to my tests the patch does not introduce new misbehaviour
regarding powermenu's always on top window feature.

I could provide a patched binary XWin.exe, if someone wants to do more
testing...

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/