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 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 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=CYGWINid=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
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
2011/10/21 Oliver Schmidt oschmidt-mailingli...@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
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 == WM_KEYDOWN || message ==
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 oschmidt-mailingli...@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
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
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/
