Re: XRaiseWindow for activating windows in multiwindow mode In-Reply-To: 53a2b675.3020...@gmx.de
> 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/msg0.html > https://cygwin.com/ml/cygwin-xfree/2011-09/msg3.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. How can we get this rolled into the release? -- 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
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/msg0.html https://cygwin.com/ml/cygwin-xfree/2011-09/msg3.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/
Re: XRaiseWindow for activating windows in multiwindow mode
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/msg0.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
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
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 */
-intresult;
-ClientPtr client;
-intnready;
-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 longstart_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 == W
Re: XRaiseWindow for activating windows in multiwindow mode
2011/10/21 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 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
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
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 > > 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
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
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
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 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
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)
HWNDhInsertAfter;
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/
XRaiseWindow for activating windows in multiwindow mode
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 */
ScreenPtrpScreen = 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
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 */
ScreenPtrpScreen = 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
--
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/
