Re: XRaiseWindow for activating windows in multiwindow mode

Re: XRaiseWindow for activating windows in multiwindow mode

[Patrick Herbst]

On 03 Sep 2011, Jon TURNEY wrote:
>
> On 13/08/2011 19:39, Oliver Schmidt wrote:
> > as reported in
> >
> >    http://www.cygwin.com/ml/cygwin-xfree/2005-06/msg00072.html
> >
> > windows are not raised from the Cygwin X Server in multiwindow
> > mode, if a program wants to programmatically activate a window.
> >
> > I played around and figured out that the problem can be solved by
> > invoking the windows function SetForegroundWindow if a top level
> > window is to be restacked and has no previous sibling.
> >
> > I enclose the patch in this email. It works fine for me, but
> > I'm not sure if it has any side effects for other configurations
> > or usage patterns.
>
> Thanks for looking into this, and for the patch.
>
> There definitely are some problems in this area, but I'm not sure this is the
> 'correct' fix, though.
>
> The code as it stands is the product of some ... erm ... historical compromises.
>
> If I am reading the code correctly, it looks like currently no attempt is made
> to synchronize changes in the X window Z-order (e.g. made by XRaiseWindow())
> to the native Windows window Z-order, and the comment in [1] seems to bear
> this out.  The code which perhaps would do this is in the disabled branch of
> the #if/#else/#endif in winRestackWindowMultiWindow()
>
> 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.
>
> [1] http://sourceware.org/ml/cygwin-xfree/2004-12/msg00074.html
> [2] http://sourceware.org/ml/cygwin-xfree/2004-03/msg00540.html
> [3]
> http://cgit.freedesktop.org/xorg/xserver/commit/?h=CYGWIN&id=40bb4441ac7c87cfa0c62e8553c7e53b9fe4d765
>
> > It would be nice if this feature could be integrated into future
> > versions of the Cygwin X Server.
> >
> > Best regards,
> > Oliver
> >

Is there a fix planned for this?  I too use applications that make use
of XRaiseWindow to navigate around multiple windows, and it doesn't
work.

Anyone have any info on this issue??

Thanks!
Patrick Herbst

Ref: https://cygwin.com/ml/cygwin-xfree/2011-09/msg00000.html

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

[Oliver Schmidt]

On 6/11/2014 10:50 PM, Patrick Herbst wrote:
> On 03 Sep 2011, Jon TURNEY wrote:
>> On 13/08/2011 19:39, Oliver Schmidt wrote:
>>> as reported in
>>>     http://www.cygwin.com/ml/cygwin-xfree/2005-06/msg00072.html
>>> windows are not raised from the Cygwin X Server in multiwindow
>>> mode, if a program wants to programmatically activate a window.
>>>
>>> I played around and figured out that the problem can be solved by
>>> ...
>>> I enclose the patch in this email. It works fine for me, but
>>>...
>
> Is there a fix planned for this?  I too use applications that make use
> of XRaiseWindow to navigate around multiple windows, and it doesn't
> work.
>
> Anyone have any info on this issue??

I used my patch from 2011 every day for the last three years and it 
worked always without any problems. I was also able to incorporate this 
patch into the newest cygwin x server running under 64-bit cygwin 
without any problems.

See also:
    https://cygwin.com/ml/cygwin-xfree/2011-08/msg00034.html
    https://cygwin.com/ml/cygwin-xfree/2011-09/msg00000.html
    https://cygwin.com/ml/cygwin-xfree/2011-09/msg00003.html

I don't understand, why this patch was not included into the official 
cygwin-x-server. Of course it would be nice, if a better solution was 
available. For pragmatic reasons it would be nice to include this patch 
into official cygwin x server until a better solution is available.

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/

XRaiseWindow for activating windows in multiwindow mode

[Oliver Schmidt]

[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]

Hi,

as reported in 

  http://www.cygwin.com/ml/cygwin-xfree/2005-06/msg00072.html

windows are not raised from the Cygwin X Server in multiwindow
mode, if a program wants to programmatically activate a window.

I played around and figured out that the problem can be solved by 
invoking the windows function SetForegroundWindow if a top level 
window is to be restacked and has no previous sibling.

I enclose the patch in this email. It works fine for me, but 
I'm not sure if it has any side effects for other configurations 
or usage patterns.

It would be nice if this feature could be integrated into future
versions of the Cygwin X Server.

Best regards,
Oliver


diff --git a/hw/xwin/winmultiwindowwindow.c b/hw/xwin/winmultiwindowwindow.c
index 956a9a5..22390b3 100644
--- a/hw/xwin/winmultiwindowwindow.c
+++ b/hw/xwin/winmultiwindowwindow.c
@@ -465,6 +465,7 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
   HWND			hInsertAfter;
   HWND                  hWnd = NULL;
 #endif
+  static Bool fRestacking = FALSE; /* Avoid recusive calls to this function */
   ScreenPtr		pScreen = pWin->drawable.pScreen;
   winScreenPriv(pScreen);
 
@@ -472,10 +473,27 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
   winTrace ("winRestackMultiWindow - %08x\n", pWin);
 #endif
   
+  if (fRestacking)
+    {
+      /* It is a recusive call so immediately exit */
+#if CYGWINDOWING_DEBUG
+      ErrorF ("winRestackWindowMultiWindow - "
+	      "exit because fRestacking == TRUE\n");
+#endif
+      return;
+    }
+  fRestacking = TRUE;
+
    WIN_UNWRAP(RestackWindow);
    if (pScreen->RestackWindow) 
      (*pScreen->RestackWindow)(pWin, pOldNextSib);
    WIN_WRAP(RestackWindow, winRestackWindowMultiWindow);
+
+  if (isToplevelWindow(pWin) && pWin->prevSib == NULL)
+    {
+      winWindowPriv(pWin);
+      SetForegroundWindow(pWinPriv->hWnd);
+    }
   
 #if 1
   /*
@@ -538,6 +556,8 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
 		0, 0,
 		uFlags);
 #endif
+
+  fRestacking = FALSE;
 }
 
 static void

[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1405 bytes --]

diff --git a/hw/xwin/winmultiwindowwindow.c b/hw/xwin/winmultiwindowwindow.c
index 956a9a5..22390b3 100644
--- a/hw/xwin/winmultiwindowwindow.c
+++ b/hw/xwin/winmultiwindowwindow.c
@@ -465,6 +465,7 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
   HWND			hInsertAfter;
   HWND                  hWnd = NULL;
 #endif
+  static Bool fRestacking = FALSE; /* Avoid recusive calls to this function */
   ScreenPtr		pScreen = pWin->drawable.pScreen;
   winScreenPriv(pScreen);
 
@@ -472,10 +473,27 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
   winTrace ("winRestackMultiWindow - %08x\n", pWin);
 #endif
   
+  if (fRestacking)
+    {
+      /* It is a recusive call so immediately exit */
+#if CYGWINDOWING_DEBUG
+      ErrorF ("winRestackWindowMultiWindow - "
+	      "exit because fRestacking == TRUE\n");
+#endif
+      return;
+    }
+  fRestacking = TRUE;
+
    WIN_UNWRAP(RestackWindow);
    if (pScreen->RestackWindow) 
      (*pScreen->RestackWindow)(pWin, pOldNextSib);
    WIN_WRAP(RestackWindow, winRestackWindowMultiWindow);
+
+  if (isToplevelWindow(pWin) && pWin->prevSib == NULL)
+    {
+      winWindowPriv(pWin);
+      SetForegroundWindow(pWinPriv->hWnd);
+    }
   
 #if 1
   /*
@@ -538,6 +556,8 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
 		0, 0,
 		uFlags);
 #endif
+
+  fRestacking = FALSE;
 }
 
 static void


[-- Attachment #3: Type: text/plain, Size: 223 bytes --]

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

[Jon TURNEY]

On 13/08/2011 19:39, Oliver Schmidt wrote:
> as reported in
>
>    http://www.cygwin.com/ml/cygwin-xfree/2005-06/msg00072.html
>
> windows are not raised from the Cygwin X Server in multiwindow
> mode, if a program wants to programmatically activate a window.
>
> I played around and figured out that the problem can be solved by
> invoking the windows function SetForegroundWindow if a top level
> window is to be restacked and has no previous sibling.
>
> I enclose the patch in this email. It works fine for me, but
> I'm not sure if it has any side effects for other configurations
> or usage patterns.

Thanks for looking into this, and for the patch.

There definitely are some problems in this area, but I'm not sure this is the 
'correct' fix, though.

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

If I am reading the code correctly, it looks like currently no attempt is made 
to synchronize changes in the X window Z-order (e.g. made by XRaiseWindow()) 
to the native Windows window Z-order, and the comment in [1] seems to bear 
this out.  The code which perhaps would do this is in the disabled branch of 
the #if/#else/#endif in winRestackWindowMultiWindow()

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.

[1] http://sourceware.org/ml/cygwin-xfree/2004-12/msg00074.html
[2] http://sourceware.org/ml/cygwin-xfree/2004-03/msg00540.html
[3] 
http://cgit.freedesktop.org/xorg/xserver/commit/?h=CYGWIN&id=40bb4441ac7c87cfa0c62e8553c7e53b9fe4d765

> It would be nice if this feature could be integrated into future
> versions of the Cygwin X Server.
>
> Best regards,
> Oliver
>
>
> diff --git a/hw/xwin/winmultiwindowwindow.c b/hw/xwin/winmultiwindowwindow.c
> index 956a9a5..22390b3 100644
> --- a/hw/xwin/winmultiwindowwindow.c
> +++ b/hw/xwin/winmultiwindowwindow.c
> @@ -465,6 +465,7 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
>     HWND			hInsertAfter;
>     HWND                  hWnd = NULL;
>   #endif
> +  static Bool fRestacking = FALSE; /* Avoid recusive calls to this function */

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

>     ScreenPtr		pScreen = pWin->drawable.pScreen;
>     winScreenPriv(pScreen);
>
> @@ -472,10 +473,27 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
>     winTrace ("winRestackMultiWindow - %08x\n", pWin);
>   #endif
>
> +  if (fRestacking)
> +    {
> +      /* It is a recusive call so immediately exit */
> +#if CYGWINDOWING_DEBUG
> +      ErrorF ("winRestackWindowMultiWindow - "
> +	      "exit because fRestacking == TRUE\n");
> +#endif
> +      return;
> +    }
> +  fRestacking = TRUE;
> +
>      WIN_UNWRAP(RestackWindow);
>      if (pScreen->RestackWindow)
>        (*pScreen->RestackWindow)(pWin, pOldNextSib);
>      WIN_WRAP(RestackWindow, winRestackWindowMultiWindow);
> +
> +  if (isToplevelWindow(pWin)&&  pWin->prevSib == NULL)
> +    {
> +      winWindowPriv(pWin);
> +      SetForegroundWindow(pWinPriv->hWnd);
> +    }
>
>   #if 1
>     /*
> @@ -538,6 +556,8 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
>   		0, 0,
>   		uFlags);
>   #endif
> +
> +  fRestacking = FALSE;
>   }
>
>   static void

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

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

[Oliver Schmidt]

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/

Re: XRaiseWindow for activating windows in multiwindow mode

[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

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

Re: XRaiseWindow for activating windows in multiwindow mode

[Michel Hummel]

I am a bit late but I will be happy to test this version of XWin.

Could you give me a patched binary version please ?

Regards,

2011/9/4 Oliver Schmidt <oschmidt-mailinglists@gmx.de>
>
> 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/
>

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

[Oliver Schmidt]

Hi Michel,

On 10/19/2011 11:33 AM, Michel Hummel wrote:
> I am a bit late but I will be happy to test this version of XWin.
> Could you give me a patched binary version please ?

You can download my currently used version of XWin.exe from:

	http://min.us/mgtjlVdju

This version includes also my other patches (e.g. experimental redrawing
of windows while they are resized/moved, see
http://www.cygwin.com/ml/cygwin-xfree/2011-08/msg00049.html). I'm using
this version daily, so it can be considered stable for my personal usage
patterns ;-) However if the redrawing patch causes problem on your setup
I could prepare a version without this patch.

For me the most missing feature from the official Cygwin's x-server is
the possibility to programmatically raise windows in multi window mode,
so I'm happy to hear that others are interested in this feature too.

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

[Michel Hummel]

2011/10/21 Oliver Schmidt <oschmidt-mailinglists@gmx.de>:
> Hi Michel,
>
> On 10/19/2011 11:33 AM, Michel Hummel wrote:
>> I am a bit late but I will be happy to test this version of XWin.
>> Could you give me a patched binary version please ?
>
> You can download my currently used version of XWin.exe from:
>
>        http://min.us/mgtjlVdju
>
> This version includes also my other patches (e.g. experimental redrawing
> of windows while they are resized/moved, see
> http://www.cygwin.com/ml/cygwin-xfree/2011-08/msg00049.html). I'm using
> this version daily, so it can be considered stable for my personal usage
> patterns ;-) However if the redrawing patch causes problem on your setup
> I could prepare a version without this patch.
>
> For me the most missing feature from the official Cygwin's x-server is
> the possibility to programmatically raise windows in multi window mode,
> so I'm happy to hear that others are interested in this feature too.
>
> Best regards,
> Oliver

 Thank you for the binary version and for your work !
 Can I know the exact patch list applied to generate it ?

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

[Oliver Schmidt]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On 10/21/2011 1:43 PM, Michel Hummel wrote:
>  Can I know the exact patch list applied to generate it ?

you can see the source code of my current playground version at
	https://github.com/osch/cygwin-xserver

Commit 1ec241341cf1c85abf0372e00ae9acc8be66894b contains the official
sources from xserver-cygwin-1.10.3-1.

I'm also attaching a patch file of my current version against
xserver-cygwin-1.10.3-1 to this email.

Best regards,
Oliver


[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 10859 bytes --]

diff --git a/cygwin/dix/dispatch.c b/cygwin/dix/dispatch.c
index 44f8087..18e9697 100644
--- a/cygwin/dix/dispatch.c
+++ b/cygwin/dix/dispatch.c
@@ -343,33 +343,27 @@ DisableLimitedSchedulingLatency(void)
 
 #define MAJOROP ((xReq *)client->requestBuffer)->reqType
 
-void
-Dispatch(void)
-{
-    int        *clientReady;     /* array of request ready clients */
-    int	result;
-    ClientPtr	client;
-    int	nready;
-    HWEventQueuePtr* icheck = checkForInput;
-    long			start_tick;
+static     int        *clientReady;     /* array of request ready clients */
+static     int	result;
+static     ClientPtr	client;
+static     int	nready;
+static     HWEventQueuePtr* icheck = checkForInput;
+static     long			start_tick;
 
-    nextFreeClientID = 1;
-    nClients = 0;
-
-    clientReady = malloc(sizeof(int) * MaxClients);
-    if (!clientReady)
-	return;
-
-    SmartScheduleSlice = SmartScheduleInterval;
-    while (!dispatchException)
-    {
+int DispatchOneStep(Bool handleWindowMessage)
+{
+    int rslt = 0;
+    
         if (*icheck[0] != *icheck[1])
 	{
 	    ProcessInputEvents();
 	    FlushIfCriticalOutputPending();
 	}
-
 	nready = WaitForSomething(clientReady);
+	rslt = nready;
+
+        if (handleWindowMessage)
+            handleNextWindowMessage();
 
 	if (nready && !SmartScheduleDisable)
 	{
@@ -460,6 +454,24 @@ Dispatch(void)
 		client->smart_stop_tick = SmartScheduleTime;
 	}
 	dispatchException &= ~DE_PRIORITYCHANGE;
+
+    return rslt;
+}
+
+void
+Dispatch(void)
+{
+    nextFreeClientID = 1;
+    nClients = 0;
+
+    clientReady = malloc(sizeof(int) * MaxClients);
+    if (!clientReady)
+	return;
+
+    SmartScheduleSlice = SmartScheduleInterval;
+    while (!dispatchException)
+    {
+        DispatchOneStep(TRUE);
     }
 
     if (ddxHooks.ddxBeforeReset)
diff --git a/cygwin/hw/xwin/winkeybd.c b/cygwin/hw/xwin/winkeybd.c
index 9e5a9b0..99c822d 100644
--- a/cygwin/hw/xwin/winkeybd.c
+++ b/cygwin/hw/xwin/winkeybd.c
@@ -282,6 +282,29 @@ winRestoreModeKeyStates (void)
    * have a logical XOR operator, so we use a macro instead.
    */
 
+  {
+    /* consider modifer keys */
+    
+    BOOL ctrl   = (GetAsyncKeyState (VK_CONTROL) < 0);
+    BOOL shift  = (GetAsyncKeyState (VK_SHIFT)   < 0);
+    BOOL alt    = (GetAsyncKeyState (VK_LMENU)   < 0);
+    BOOL altgr  = (GetAsyncKeyState (VK_RMENU)   < 0);
+
+    if (ctrl && altgr) ctrl = FALSE;
+    
+    if (WIN_XOR (internalKeyStates & ControlMask, ctrl))
+      winSendKeyEvent (KEY_LCtrl, ctrl);
+  
+    if (WIN_XOR (internalKeyStates & ShiftMask, shift))
+      winSendKeyEvent (KEY_ShiftL, shift);
+  
+    if (WIN_XOR (internalKeyStates & Mod1Mask, alt))
+      winSendKeyEvent (KEY_Alt, alt);
+  
+    if (WIN_XOR (internalKeyStates & Mod5Mask, altgr))
+      winSendKeyEvent (KEY_AltLang, altgr);
+  }
+
   /* Has the key state changed? */
   dwKeyState = GetKeyState (VK_NUMLOCK) & 0x0001;
   if (WIN_XOR (internalKeyStates & NumLockMask, dwKeyState))
@@ -327,6 +350,12 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
   MSG		msgNext;
   LONG		lTime;
   Bool		fReturn;
+  
+  static Bool   hasLastControlL = FALSE;
+  static UINT   lastMessage;
+  static WPARAM lastWparam;
+  static LPARAM lastLparam;
+  static LONG   lastTime;
 
   /*
    * Fake Ctrl_L presses will be followed by an Alt_R keypress
@@ -360,9 +389,22 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
 				 WM_KEYDOWN, WM_SYSKEYDOWN,
 				 PM_NOREMOVE);
 	}
-      if (msgNext.message != WM_KEYDOWN && msgNext.message != WM_SYSKEYDOWN)
+      if (fReturn && msgNext.message != WM_KEYDOWN && msgNext.message != WM_SYSKEYDOWN)
           fReturn = 0;
 
+      if (!fReturn)
+        {
+          hasLastControlL = TRUE;
+          lastMessage = message;
+          lastWparam  = wParam;
+          lastLparam  = lParam;
+          lastTime    = lTime;
+        } 
+      else
+        {
+          hasLastControlL = FALSE;
+        }
+
       /* Is next press an Alt_R with the same timestamp? */
       if (fReturn && msgNext.wParam == VK_MENU
 	  && msgNext.time == lTime
@@ -377,11 +419,33 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
 	}
     }
 
+  /*
+   * Check for Alt_R keypress, that was not ready when the
+   * last Ctrl_L appeared.
+   */
+  else if ((message == WM_KEYDOWN || message == WM_SYSKEYDOWN)
+      && wParam == VK_MENU
+      && (HIWORD (lParam) & KF_EXTENDED))
+    {
+      if (hasLastControlL)
+        {
+          lTime = GetMessageTime ();
+          
+          if ((lastMessage == WM_KEYDOWN || lastMessage == WM_SYSKEYDOWN)
+              && lastTime == lTime)
+            {
+                /* take back the fake ctrl_L key */
+                winSendKeyEvent (KEY_LCtrl, FALSE);
+            }
+          hasLastControlL = FALSE;
+        }
+    }
+
   /* 
    * Fake Ctrl_L releases will be followed by an Alt_R release
    * with the same timestamp as the Ctrl_L release.
    */
-  if ((message == WM_KEYUP || message == WM_SYSKEYUP)
+  else if ((message == WM_KEYUP || message == WM_SYSKEYUP)
       && wParam == VK_CONTROL
       && (HIWORD (lParam) & KF_EXTENDED) == 0)
     {
@@ -410,9 +474,11 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
 				 PM_NOREMOVE);
 	}
 
-      if (msgNext.message != WM_KEYUP && msgNext.message != WM_SYSKEYUP)
+      if (fReturn && msgNext.message != WM_KEYUP && msgNext.message != WM_SYSKEYUP)
           fReturn = 0;
       
+    hasLastControlL = FALSE;
+
       /* Is next press an Alt_R with the same timestamp? */
       if (fReturn
 	  && (msgNext.message == WM_KEYUP
@@ -429,6 +495,10 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam)
 	  return TRUE;
 	}
     }
+  else
+    {
+      hasLastControlL = FALSE;
+    }
   
   /* Not a fake control left press/release */
   return FALSE;
diff --git a/cygwin/hw/xwin/winmultiwindowwindow.c b/cygwin/hw/xwin/winmultiwindowwindow.c
index 956a9a5..123533b 100644
--- a/cygwin/hw/xwin/winmultiwindowwindow.c
+++ b/cygwin/hw/xwin/winmultiwindowwindow.c
@@ -465,6 +465,7 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
   HWND			hInsertAfter;
   HWND                  hWnd = NULL;
 #endif
+  static Bool fRestacking = FALSE; /* Avoid recusive calls to this function */
   ScreenPtr		pScreen = pWin->drawable.pScreen;
   winScreenPriv(pScreen);
 
@@ -472,10 +473,27 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
   winTrace ("winRestackMultiWindow - %08x\n", pWin);
 #endif
   
+  if (fRestacking)
+    {
+      /* It is a recusive call so immediately exit */
+#if CYGWINDOWING_DEBUG
+      ErrorF ("winRestackWindowMultiWindow - "
+	      "exit because fRestacking == TRUE\n");
+#endif
+      return;
+    }
+  fRestacking = TRUE;
+
    WIN_UNWRAP(RestackWindow);
    if (pScreen->RestackWindow) 
      (*pScreen->RestackWindow)(pWin, pOldNextSib);
    WIN_WRAP(RestackWindow, winRestackWindowMultiWindow);
+
+  if (pWin->realized && pWin->prevSib == NULL && isToplevelWindow(pWin))
+    {
+      winWindowPriv(pWin);
+      SetForegroundWindow(pWinPriv->hWnd);
+    }
   
 #if 1
   /*
@@ -538,6 +556,8 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib)
 		0, 0,
 		uFlags);
 #endif
+
+  fRestacking = FALSE;
 }
 
 static void
diff --git a/cygwin/hw/xwin/winmultiwindowwndproc.c b/cygwin/hw/xwin/winmultiwindowwndproc.c
index bd84c05..265fdcc 100644
--- a/cygwin/hw/xwin/winmultiwindowwndproc.c
+++ b/cygwin/hw/xwin/winmultiwindowwndproc.c
@@ -321,6 +321,7 @@ winTopLevelWindowProc (HWND hwnd, UINT message,
   static Bool		s_fTracking = FALSE;
   Bool			needRestack = FALSE;
   LRESULT		ret;
+  static Bool           hasEnteredSizeMove = FALSE;
 
 #if CYGDEBUG
   winDebugWin32Message("winTopLevelWindowProc", hwnd, message, wParam, lParam);
@@ -871,7 +872,15 @@ winTopLevelWindowProc (HWND hwnd, UINT message,
 
     case WM_MOVE:
       /* Adjust the X Window to the moved Windows window */
-      winAdjustXWindow (pWin, hwnd);
+      if (!hasEnteredSizeMove) 
+        {
+          winAdjustXWindow (pWin, hwnd);
+        }
+      else
+        {
+          winAdjustXWindow (pWin, hwnd);
+          while (DispatchOneStep(FALSE) > 0) {}
+        }
       return 0;
 
     case WM_SHOWWINDOW:
@@ -1012,6 +1021,16 @@ winTopLevelWindowProc (HWND hwnd, UINT message,
       */
       break; 
 
+    case WM_ENTERSIZEMOVE:
+      hasEnteredSizeMove = TRUE;
+      return 0;
+
+    case WM_EXITSIZEMOVE:
+      /* Adjust the X Window to the moved Windows window */
+      hasEnteredSizeMove = FALSE;
+      winAdjustXWindow (pWin, hwnd);
+      return 0;
+
     case WM_SIZE:
       /* see dix/window.c */
 #if CYGWINDOWING_DEBUG
@@ -1036,9 +1055,17 @@ winTopLevelWindowProc (HWND hwnd, UINT message,
 		(int)(GetTickCount ()));
       }
 #endif
-      /* Adjust the X Window to the moved Windows window */
-      winAdjustXWindow (pWin, hwnd);
-      if (wParam == SIZE_MINIMIZED) winReorderWindowsMultiWindow();
+      if (!hasEnteredSizeMove)
+        {
+          /* Adjust the X Window to the moved Windows window */
+          winAdjustXWindow (pWin, hwnd);
+          if (wParam == SIZE_MINIMIZED) winReorderWindowsMultiWindow();
+        }
+      else
+        {
+          winAdjustXWindow (pWin, hwnd);
+          while (DispatchOneStep(FALSE) > 0) {}
+        }
       return 0; /* end of WM_SIZE handler */
 
     case WM_STYLECHANGING:
diff --git a/cygwin/hw/xwin/winwakeup.c b/cygwin/hw/xwin/winwakeup.c
index 031a510..6eab76a 100644
--- a/cygwin/hw/xwin/winwakeup.c
+++ b/cygwin/hw/xwin/winwakeup.c
@@ -43,6 +43,14 @@ winWakeupHandler (int nScreen,
 		  unsigned long ulResult,
 		  pointer pReadmask)
 {
+    /* was: handleNextWindowMessage, but
+            this will block in WaitForSomething when
+            moving resizing windows in multiwindow 
+            mode. */
+}
+
+void handleNextWindowMessage(void)
+{
   MSG			msg;
 
   /* Process one message from our queue */
diff --git a/cygwin/hw/xwin/winwndproc.c b/cygwin/hw/xwin/winwndproc.c
index 316cf08..7de5a5d 100644
--- a/cygwin/hw/xwin/winwndproc.c
+++ b/cygwin/hw/xwin/winwndproc.c
@@ -1060,6 +1060,10 @@ winWindowProc (HWND hwnd, UINT message,
       if ((wParam == VK_LWIN || wParam == VK_RWIN) && !g_fKeyboardHookLL)
 	break;
 
+      /* Discard fake Ctrl_L presses that precede AltGR on non-US keyboards */
+      if (winIsFakeCtrl_L (message, wParam, lParam))
+	return 0;
+      
       /* 
        * Discard presses generated from Windows auto-repeat
        */
@@ -1080,10 +1084,6 @@ winWindowProc (HWND hwnd, UINT message,
         }
       } 
       
-      /* Discard fake Ctrl_L presses that precede AltGR on non-US keyboards */
-      if (winIsFakeCtrl_L (message, wParam, lParam))
-	return 0;
-      
       /* Translate Windows key code to X scan code */
       winTranslateKey (wParam, lParam, &iScanCode);
 


[-- Attachment #3: Type: text/plain, Size: 223 bytes --]

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