public inbox for cygwin-xfree@sourceware.org help / color / mirror / Atom feed
* Re: XRaiseWindow for activating windows in multiwindow mode
@ 2014-06-11 20:50 Patrick Herbst
2014-06-19 10:07 ` Oliver Schmidt
0 siblings, 1 reply; 11+ messages in thread
From: Patrick Herbst @ 2014-06-11 20:50 UTC (permalink / raw)
To: cygwin-xfree
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/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: XRaiseWindow for activating windows in multiwindow mode 2014-06-11 20:50 XRaiseWindow for activating windows in multiwindow mode Patrick Herbst @ 2014-06-19 10:07 ` Oliver Schmidt 0 siblings, 0 replies; 11+ messages in thread From: Oliver Schmidt @ 2014-06-19 10:07 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* XRaiseWindow for activating windows in multiwindow mode @ 2011-08-13 18:39 Oliver Schmidt 2011-09-03 19:02 ` Jon TURNEY 0 siblings, 1 reply; 11+ messages in thread From: Oliver Schmidt @ 2011-08-13 18:39 UTC (permalink / raw) To: cygwin-xfree [-- 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: XRaiseWindow for activating windows in multiwindow mode 2011-08-13 18:39 Oliver Schmidt @ 2011-09-03 19:02 ` Jon TURNEY 2011-09-04 8:52 ` Oliver Schmidt 2011-09-04 11:18 ` Oliver Schmidt 0 siblings, 2 replies; 11+ messages in thread From: Jon TURNEY @ 2011-09-03 19:02 UTC (permalink / raw) To: cygwin-xfree; +Cc: oschmidt-mailinglists 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: XRaiseWindow for activating windows in multiwindow mode 2011-09-03 19:02 ` Jon TURNEY @ 2011-09-04 8:52 ` Oliver Schmidt 2011-09-04 9:09 ` Oliver Schmidt 2011-09-04 11:18 ` Oliver Schmidt 1 sibling, 1 reply; 11+ messages in thread From: Oliver Schmidt @ 2011-09-04 8:52 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: XRaiseWindow for activating windows in multiwindow mode 2011-09-04 8:52 ` Oliver Schmidt @ 2011-09-04 9:09 ` Oliver Schmidt 0 siblings, 0 replies; 11+ messages in thread From: Oliver Schmidt @ 2011-09-04 9:09 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: XRaiseWindow for activating windows in multiwindow mode 2011-09-03 19:02 ` Jon TURNEY 2011-09-04 8:52 ` Oliver Schmidt @ 2011-09-04 11:18 ` Oliver Schmidt 2011-10-19 9:33 ` Michel Hummel 1 sibling, 1 reply; 11+ messages in thread From: Oliver Schmidt @ 2011-09-04 11:18 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: XRaiseWindow for activating windows in multiwindow mode 2011-09-04 11:18 ` Oliver Schmidt @ 2011-10-19 9:33 ` Michel Hummel 2011-10-21 10:36 ` Oliver Schmidt 0 siblings, 1 reply; 11+ messages in thread From: Michel Hummel @ 2011-10-19 9:33 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: XRaiseWindow for activating windows in multiwindow mode 2011-10-19 9:33 ` Michel Hummel @ 2011-10-21 10:36 ` Oliver Schmidt 2011-10-21 11:43 ` Michel Hummel 0 siblings, 1 reply; 11+ messages in thread From: Oliver Schmidt @ 2011-10-21 10:36 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: XRaiseWindow for activating windows in multiwindow mode 2011-10-21 10:36 ` Oliver Schmidt @ 2011-10-21 11:43 ` Michel Hummel 2011-10-21 12:26 ` Oliver Schmidt 0 siblings, 1 reply; 11+ messages in thread From: Michel Hummel @ 2011-10-21 11:43 UTC (permalink / raw) To: cygwin-xfree 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: XRaiseWindow for activating windows in multiwindow mode 2011-10-21 11:43 ` Michel Hummel @ 2011-10-21 12:26 ` Oliver Schmidt 0 siblings, 0 replies; 11+ messages in thread From: Oliver Schmidt @ 2011-10-21 12:26 UTC (permalink / raw) To: cygwin-xfree [-- 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-06-19 10:07 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-11 20:50 XRaiseWindow for activating windows in multiwindow mode Patrick Herbst 2014-06-19 10:07 ` Oliver Schmidt -- strict thread matches above, loose matches on Subject: below -- 2011-08-13 18:39 Oliver Schmidt 2011-09-03 19:02 ` Jon TURNEY 2011-09-04 8:52 ` Oliver Schmidt 2011-09-04 9:09 ` Oliver Schmidt 2011-09-04 11:18 ` Oliver Schmidt 2011-10-19 9:33 ` Michel Hummel 2011-10-21 10:36 ` Oliver Schmidt 2011-10-21 11:43 ` Michel Hummel 2011-10-21 12:26 ` Oliver Schmidt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).