Re: Window manager commands in native window manager multiwindow mode
On 10/7/2015 11:48 AM, Ken Brown wrote:
On 10/7/2015 11:20 AM, Gulliver Smith wrote:
I ask this question from time to time just in case someone new sees it
and decides to work on it or others might agree that it is a priority.
Other people have raised this over the last few years as well.
The issue is that I would like to raise windows from within a program
(Emacs to be precise), but it doesn't work with the native window
manager running in multiwindow mode.
Emacs has several nice commands for which I have not-so-nice work
arounds (opening and closing windows). These are:
(raise-frame f)
(iconify-frame f)
(decionify-frame f)
(make-frame-visible f)
None of these work with Cygwin X.
Please give a detailed recipe for reproducing the problem.
Never mind. I searched the archive and found the details in an earlier
post of yours:
https://sourceware.org/ml/cygwin-xfree/2011-08/msg00046.html
Here's what I found when I tried to reproduce the problem:
>> (raise-frame f)
I agree that this doesn't work. But there's a post by Oliver Schmidt
(https://sourceware.org/ml/cygwin-xfree/2011-08/msg00047.html)
purporting to have a fix for this. There is later discussion in which
Jon Turney had some questions about the patch, but I didn't read all of
it. Jon, was this ever resolved?
>> (iconify-frame f)
This works.
>> (decionify-frame f)
There's no such function in GNU emacs (even after correcting the obvious
typo).
>> (make-frame-visible f)
This seems to be working. Maybe you're misunderstanding what "visible"
means in this context (or maybe I am). The frame is initially visible,
even if other windows are hiding it, as evidenced by the fact that
(frame-visible-p f) evaluates to something non-nil ('icon' if the frame
is iconified, 't' otherwise). If I now make it invisible by evaluating
(make-frame-invisible f), both the frame and its icon disappear.
There's no way to bring it to the front by using Alt-Tab. The frame and
icon reappear if I now evaluate (make-frame-visible f).
In summary, the only problem I see is with raise-frame, and maybe that
one is fixable. We'll have to wait to hear from Jon and/or Oliver.
Ken
--
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/
Window manager commands in native window manager multiwindow mode
I ask this question from time to time just in case someone new sees it and decides to work on it or others might agree that it is a priority. Other people have raised this over the last few years as well. The issue is that I would like to raise windows from within a program (Emacs to be precise), but it doesn't work with the native window manager running in multiwindow mode. Emacs has several nice commands for which I have not-so-nice work arounds (opening and closing windows). These are: (raise-frame f) (iconify-frame f) (decionify-frame f) (make-frame-visible f) None of these work with Cygwin X. Thanks Gulliver -- 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: Window manager commands in native window manager multiwindow mode
On 10/7/2015 11:20 AM, Gulliver Smith wrote: I ask this question from time to time just in case someone new sees it and decides to work on it or others might agree that it is a priority. Other people have raised this over the last few years as well. The issue is that I would like to raise windows from within a program (Emacs to be precise), but it doesn't work with the native window manager running in multiwindow mode. Emacs has several nice commands for which I have not-so-nice work arounds (opening and closing windows). These are: (raise-frame f) (iconify-frame f) (decionify-frame f) (make-frame-visible f) None of these work with Cygwin X. Please give a detailed recipe for reproducing the problem. I just tried the following: 1. Start the X server by running startxwin in a Cygwin Terminal (mintty). 2. Use the xdg menu icon to start xterm. 3. In xterm, run 'emacs&'. 4. In emacs, run 'M-x iconify-frame'. The current frame did indeed get iconified, as expected. I'm not sure how to test the other commands. Ken P.S. The cygwin-xfree mailing list is obsolete. You should use the main cygwin mailing list in the future to make sure your mail is seen by the maximum number of people. -- 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 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/
Window manager commands in native window manager multiwindow mode
I ask this question from time to time just in case someone new sees it and decides to work on it or others might agree that it is a priority. Other people have raised this over the last few years as well. The issue is that I would like to raise windows from within a program (Emacs to be precise), but it doesn't work with the native window manager running in multiwindow mode. Emacs has several nice commands for which I have not-so-nice work arounds (opening and closing windows). These are: (raise-frame f) (iconify-frame f) (decionify-frame f) (make-frame-visible f) None of these work with Cygwin X. Thanks Gulliver -- 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: Excess MotionNotify events to a minimized window in multiwindow mode
On 18/12/2012 07:29, Heiko Bihr wrote: On 17.12.2012 19:38, Jon TURNEY wrote: On 10/12/2012 19:01, Heiko Bihr wrote: I think, there is a problem with mouse polling in multiwindow mode (XWin.exe :0 -multiwindow) in Cygwin/X 1.13. If a window gets maximized and then minimized, it will receive motion notify events, whenever the user moves the mouse cursor over the screen. I'm not sure I follow your reasoning. If you run 'xev -root', you can see that MotionNotify events are sent from everywhere. Is there some specific problem you are trying to fix? We're running a terminal server setup, that delivers X11 applications (e.g. firefox) via X display forwarding to users' desktops, which run Cygwin/X in multiwindow mode. We noticed quite some network traffic, even if all application windows were minimized. This network traffic is caused by the MotionNotify events, that were still reported to miminized windows. As we want to serve 500+ users, we have to keep an eye on network traffic. It might be relevant to note that MotionNotify events were potentially being sent every time the polling timer fired, even if the mouse wasn't moved. This was fixed in 1.13.0-1. In any case, the events should only be sent to clients which have registered an interest using XSelectInput() with PointerMotionMask. Thanks for the patch. There are definitely some things wrong with the way that this mouse pointer polling timer works, I noticed during testing that is was possible sometimes to move the pointer out of an xeyes without starting the polling timer. I'm not sure this patch is right though: With this patch applied, if you have 2 xeyes running, minimizing the first one stops the second one from tracking the mouse pointer. You're right. I did not test with xeyes (although I noticed it being mentioned in a comment), but only with our applications. Unfortunately, I'm not that familiar with Cygwin/X' internal data structures and window handler functions. I thought, each window will have its own timer. But after looking into the source again, i assume, this timer is a global one. Maybe it would be a better approach to disable reporting of MotionNotify events to minimized X client windows, instead of messing with the timer. I'll take a look at it. Unfortunately, the way that XWin treats minimized windows is not correct (which also causes other problems), they should probably be unmapped, but aren't. I did work on some patches fixing that a while ago, but that ended up getting blocked by other problems, which I think have now been fixed, so it might be worth revisiting them. -- 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: Excess MotionNotify events to a minimized window in multiwindow mode
On 10/12/2012 19:01, Heiko Bihr wrote: I think, there is a problem with mouse polling in multiwindow mode (XWin.exe :0 -multiwindow) in Cygwin/X 1.13. If a window gets maximized and then minimized, it will receive motion notify events, whenever the user moves the mouse cursor over the screen. To reproduce the problem, please follow these steps: 1) start XWin.exe in -multiwindow mode 2) start xev 3) maximize xev window 4) minimize xev window 5) move mouse cursor around and watch xev output You will see lots of MotionNotify events from all over the screen. X.org does not show this behaviour and I think, Cygwin/X should not either. I'm not sure I follow your reasoning. If you run 'xev -root', you can see that MotionNotify events are sent from everywhere. Is there some specific problem you are trying to fix? The problem is caused by the WIN_POLLING_MOUSE_TIMER_ID, which doesn't get stopped, when the user minimizes a window. I made a small patch against Cygwin/X 1.13.0-1 which will stop the WIN_POLLING_MOUSE_TIMER_ID, whenever the user minimizes a window. If the user changes the window's size again, and the timer was stopped, it will be started again. The patch introduces a new flag in s_pScreenPriv to remember the state of the timer. Thanks for the patch. There are definitely some things wrong with the way that this mouse pointer polling timer works, I noticed during testing that is was possible sometimes to move the pointer out of an xeyes without starting the polling timer. I'm not sure this patch is right though: With this patch applied, if you have 2 xeyes running, minimizing the first one stops the second one from tracking the mouse pointer. -- 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/
Excess MotionNotify events to a minimized window in multiwindow mode
Hi,
I think, there is a problem with mouse polling in multiwindow mode
(XWin.exe :0 -multiwindow) in Cygwin/X 1.13.
If a window gets maximized and then minimized, it will receive motion
notify events, whenever the user moves the mouse cursor over the screen.
To reproduce the problem, please follow these steps:
1) start XWin.exe in -multiwindow mode
2) start xev
3) maximize xev window
4) minimize xev window
5) move mouse cursor around and watch xev output
You will see lots of MotionNotify events from all over the screen.
X.org does not show this behaviour and I think, Cygwin/X should not either.
The problem is caused by the WIN_POLLING_MOUSE_TIMER_ID, which doesn't
get stopped, when the user minimizes a window.
I made a small patch against Cygwin/X 1.13.0-1 which will stop the
WIN_POLLING_MOUSE_TIMER_ID, whenever the user minimizes a window. If the
user changes the window's size again, and the timer was stopped, it will
be started again.
The patch introduces a new flag in s_pScreenPriv to remember the state
of the timer.
Regards
Heiko Bihr
--
Dipl.-Inform. Heiko Bihr
Senior Consultant, Software Development
Business Unit Government
secunet Security Networks AG
diff -ur xserver-cygwin-1.13.0-1.orig/hw/xwin/win.h
xserver-cygwin-1.13.0-1/hw/xwin/win.h
--- xserver-cygwin-1.13.0-1.orig/hw/xwin/win.h 2012-12-10 15:19:42.09375
+0100
+++ xserver-cygwin-1.13.0-1/hw/xwin/win.h 2012-12-10 15:27:40.03125
+0100
@@ -595,6 +595,9 @@
UnrealizeFontPtr UnrealizeFont;
#endif
+/* mouse polling */
+BOOL bMousePollingTimerStoppedWhileMinimized;
+
} winPrivScreenRec;
#ifdef XWIN_MULTIWINDOWEXTWM
diff -ur xserver-cygwin-1.13.0-1.orig/hw/xwin/winmultiwindowwndproc.c
xserver-cygwin-1.13.0-1/hw/xwin/winmultiwindowwndproc.c
--- xserver-cygwin-1.13.0-1.orig/hw/xwin/winmultiwindowwndproc.c
2012-12-10 15:19:42.140625000 +0100
+++ xserver-cygwin-1.13.0-1/hw/xwin/winmultiwindowwndproc.c 2012-12-10
15:26:50.359375000 +0100
@@ -415,6 +415,22 @@
SetWindowLongPtr(hwnd, GWLP_USERDATA, (LONG_PTR) XMING_SIGNATURE);
+/*
+ * Initialize variables for mouse polling in s_pScreenPriv.
+ * Need to initialize s_pSreenPriv first, as WIN_WINDOW_PROP
+ * was read before we set it in WM_CREATE
+ */
+if ((pWin = GetProp (hwnd, WIN_WINDOW_PROP)) != NULL)
+ {
+/* Get a pointer to our window privates */
+pWinPriv = winGetWindowPriv(pWin);
+
+/* Get pointers to our screen privates and screen info */
+s_pScreenPriv = pWinPriv-pScreenPriv;
+
+s_pScreenPriv-bMousePollingTimerStoppedWhileMinimized = FALSE;
+ }
+
return 0;
case WM_INIT_SYS_MENU:
@@ -1007,6 +1023,27 @@
return 0;
case WM_SIZE:
+if(wParam == SIZE_MINIMIZED)
+ {
+/* Kill the timer used to poll mouse events, if window gets
minimized */
+if (g_uipMousePollingTimerID != 0)
+ {
+KillTimer (s_pScreenPriv-hwndScreen,
WIN_POLLING_MOUSE_TIMER_ID);
+g_uipMousePollingTimerID = 0;
+s_pScreenPriv-bMousePollingTimerStoppedWhileMinimized = TRUE;
+ }
+ }
+else
+ {
+/* If timer was killed on minimize, restart it */
+if(s_pScreenPriv-bMousePollingTimerStoppedWhileMinimized == TRUE)
+ {
+s_pScreenPriv-bMousePollingTimerStoppedWhileMinimized = FALSE;
+winStartMousePolling(s_pScreenPriv);
+ }
+ }
+
+
/* see dix/window.c */
#if CYGWINDOWING_DEBUG
{
diff -ur xserver-cygwin-1.13.0-1.orig/hw/xwin/winwndproc.c
xserver-cygwin-1.13.0-1/hw/xwin/winwndproc.c
--- xserver-cygwin-1.13.0-1.orig/hw/xwin/winwndproc.c 2012-12-10
15:19:42.18750 +0100
+++ xserver-cygwin-1.13.0-1/hw/xwin/winwndproc.c2012-12-10
15:20:52.703125000 +0100
@@ -139,6 +139,10 @@
winInitNotifyIcon(s_pScreenPriv);
}
+
+ /* initialize variables for mouse polling in s_pScreenPriv */
+ s_pScreenPriv-bMousePollingTimerStoppedWhileMinimized = FALSE;
+
return 0;
case WM_DISPLAYCHANGE:
--
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: Graphical glitch in all but multiwindow mode over remote desktop
On 04/10/2012 09:00, Erik Fonnesbeck wrote: This is on Windows Server 2008 R2 with desktop composition enabled over remote desktop and using Cygwin/X 1.12.4 (though I have not seen any release notes mentioning a fix for it, so I'm guessing it is still relevant in the current version). Windows 7 should be relevant for testing this bug as well. I do not recall testing without desktop composition enabled for the remote desktop session, and I do not know whether the issue is specific to Windows 7/Server 2008 R2. Multiwindow mode works fine, but all other modes draw on the taskbar instead of in the Cygwin/X window. I have tried various combinations of settings for the X server, but the behavior is the same in all cases. Did you try adding '-engine 1' option to the X server command line? All modes apart from multiwindow use DirectX drawing by default, and there have been reports that doesn't work correctly over RDP. (From my brief research, this may be related to the DirectX version which Xwin uses. DirectX over RDP, rendering on the host, is supposed to work since Vista, but only for DX9 or later clients, and XWin uses an older DX interface) -- 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: Graphical glitch in all but multiwindow mode over remote desktop
On Mon, Oct 8, 2012 at 7:36 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 04/10/2012 09:00, Erik Fonnesbeck wrote: This is on Windows Server 2008 R2 with desktop composition enabled over remote desktop and using Cygwin/X 1.12.4 (though I have not seen any release notes mentioning a fix for it, so I'm guessing it is still relevant in the current version). Windows 7 should be relevant for testing this bug as well. I do not recall testing without desktop composition enabled for the remote desktop session, and I do not know whether the issue is specific to Windows 7/Server 2008 R2. Multiwindow mode works fine, but all other modes draw on the taskbar instead of in the Cygwin/X window. I have tried various combinations of settings for the X server, but the behavior is the same in all cases. Did you try adding '-engine 1' option to the X server command line? All modes apart from multiwindow use DirectX drawing by default, and there have been reports that doesn't work correctly over RDP. (From my brief research, this may be related to the DirectX version which Xwin uses. DirectX over RDP, rendering on the host, is supposed to work since Vista, but only for DX9 or later clients, and XWin uses an older DX interface) I was unable to reproduce this on my Windows 7 desktop, with desktop composition enabled or disabled over remote desktop (same version of Cygwin/X). It does seem to be specific to desktop composition, as it seemed to behave fine when I disabled it on the remote desktop connection to my Windows Server 2008 R2 system (which is a VM with no 3d capabilities, if that's relevant). Since it isn't used as a server, after you mentioned DirectX I decided to try installing the missing DirectX 9 files in case it would have any effect (it didn't). Adding the '-engine 1' option did make it display properly. -- 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
+{
+ 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);
--
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 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: redraw windows while resizing/moving windows in multiwindow mode
On 08/09/2011 14:09, Oliver Schmidt wrote:
On 9/7/2011 5:05 PM, Jon TURNEY wrote:
This is fine as a proof of concept, and it would be nice to handle this
did you try the patch? It looks feels very smooth if you resize a
xlock and the xclock and all x11 background windows are redrawn while
resizing ;-)
better and do X window updates during the Windows modal resizing loop,
but I don't think I can apply this patch.
but I hope this patch can be used as a starting point.
Well, in fact, no X events are processed while in the modal resizing
loop, so for e.g. if you have ico running in another X window, it stops
updating while an xterm window is being resized.
with the patch X events are processed. With the patch, ico redraws also
while windows are moved or resized, as long as the mouse is moved. For
display updating without moving the mouse while modal resizing/moving is
in progress, I already mentioned the timer event that is possible to
improve the patch.
Thanks for mentioning ico, I didn't know this program, it is an
interesting experimental tool: it shows that the patch is too
aggressive, i.e. the ui interface is not responsive, perhaps due to my
critical code fragment:
while (DispatchOneStep(FALSE) 0) {}
So I will try now to improve the patch for better responsiveness.
Note that there are other modal loops in Windows message handling, I
think moving the scrollbar also involves one (which can happen in
windowed mode with the -scrollbar option)
One could introduce a similar patch there too ;-) However a patch for
scrollbar option in windowed mode is not as reasonable as in multiwindow
mode, because the static redrawing of the x server makes sense in
windowed mode.
I'm not sure I follow your reasoning here. If we have 'ico' running in
windowed mode, why should it stop updating while the scrollbars are being moved?
Only in multiwindow mode the redrawing is strange, e.g.
if you applied my patch minimize redraw events after resizing/moving
windows in multiwindow mode, you will see other X11 background windows
while resizing a x11 foreground window in the window that is resized,
because actually the x11 window is not resized due to missing x11 event
processing, but the xserver simply redraws all x11 windows in the
current size. In windowed mode, no x11 window is resized.
I'm not sure how to structure the change to Dispatch() in a way which
would be acceptable upstream.
I hoped, you had an idea. What are the criteria to be accepted upstream?
At least the patch introduces only a bypass, i.e. existing code/usage
is not affected. It would be discouraging if no upstream changes are
possible to improve the cygwin x server's multi window mode, since this
is the mode that allows the highest integration of x11 applications with
native windows programs. If no upstream changes are possible one
fallback could be to have a local patch (or #ifdef switch) for the
cygwin x server.
An additional point to consider is that you may have introduced the
possibility of re-entrancy into either the X window message dispatcher,
or the Windows message dispatcher, which may not be safe. (e.g.
winTopLevelProc - DispatchOneStep - (some X event processing calls a
DDX function which calls SendMessage) - winTopLevelProc ...)
Could you explaind this more explicitly? How can this be tested?
As I understood the code, the function Dispatch is only called once
per x server invocation. And the new function DispatchOneStep is meant
to be processed re-entrant.
I don't see how you can guarantee that all the X server code which
DispatchOneStep() might call is re-entrant?
I cannot rid myself the suspicion this may happen (since there are now code
paths winTopLevelProc-DispatchOneStep and DispatchOneStep-winTopLevelProc)
This is why the boolean parameter
handleWindowMessage is introduced and why I had to remove the invocation
of DispatchMessage out of the winWakeupHandler which is called in
WaitForSomething.
An alternative approach would be to move the Windows message pump into a
separate thread from the X server message dispatch. Unfortunately, this
would probably involve rather major changes, and careful examination of
I agree that this would cause a lot of more work than the approach of my
patch. I'm not sure if moving the Windows message handling into a
different thread will solve the problem totally: there still is the
problem, that in the modal windows event loop the x11 event processing
must be invoked. At least one has to totally decouple the x11 and
Windows event processing, but then still in the modal event loop the now
decoupled x11 processing must be triggered. So it seems to me, that
decoupling the x11 and Windows processing does only prevent upstream
changes but does not solve the problem, that in the modal Windows event
loop small progressing parts for X11 (coupled or decoupled) have to be done.
Alternatively, it might be worth investigating to see if it is possible
to use
Re: redraw windows while resizing/moving windows in multiwindow mode
Hi Jon,
On 9/7/2011 5:05 PM, Jon TURNEY wrote:
This is fine as a proof of concept, and it would be nice to handle this
did you try the patch? It looks feels very smooth if you resize a
xlock and the xclock and all x11 background windows are redrawn while
resizing ;-)
better and do X window updates during the Windows modal resizing loop,
but I don't think I can apply this patch.
but I hope this patch can be used as a starting point.
Well, in fact, no X events are processed while in the modal resizing
loop, so for e.g. if you have ico running in another X window, it stops
updating while an xterm window is being resized.
with the patch X events are processed. With the patch, ico redraws also
while windows are moved or resized, as long as the mouse is moved. For
display updating without moving the mouse while modal resizing/moving is
in progress, I already mentioned the timer event that is possible to
improve the patch.
Thanks for mentioning ico, I didn't know this program, it is an
interesting experimental tool: it shows that the patch is too
aggressive, i.e. the ui interface is not responsive, perhaps due to my
critical code fragment:
while (DispatchOneStep(FALSE) 0) {}
So I will try now to improve the patch for better responsiveness.
Note that there are other modal loops in Windows message handling, I
think moving the scrollbar also involves one (which can happen in
windowed mode with the -scrollbar option)
One could introduce a similar patch there too ;-) However a patch for
scrollbar option in windowed mode is not as reasonable as in multiwindow
mode, because the static redrawing of the x server makes sense in
windowed mode. Only in multiwindow mode the redrawing is strange, e.g.
if you applied my patch minimize redraw events after resizing/moving
windows in multiwindow mode, you will see other X11 background windows
while resizing a x11 foreground window in the window that is resized,
because actually the x11 window is not resized due to missing x11 event
processing, but the xserver simply redraws all x11 windows in the
current size. In windowed mode, no x11 window is resized.
I'm not sure how to structure the change to Dispatch() in a way which
would be acceptable upstream.
I hoped, you had an idea. What are the criteria to be accepted upstream?
At least the patch introduces only a bypass, i.e. existing code/usage
is not affected. It would be discouraging if no upstream changes are
possible to improve the cygwin x server's multi window mode, since this
is the mode that allows the highest integration of x11 applications with
native windows programs. If no upstream changes are possible one
fallback could be to have a local patch (or #ifdef switch) for the
cygwin x server.
An additional point to consider is that you may have introduced the
possibility of re-entrancy into either the X window message dispatcher,
or the Windows message dispatcher, which may not be safe. (e.g.
winTopLevelProc - DispatchOneStep - (some X event processing calls a
DDX function which calls SendMessage) - winTopLevelProc ...)
Could you explaind this more explicitly? How can this be tested?
As I understood the code, the function Dispatch is only called once
per x server invocation. And the new function DispatchOneStep is meant
to be processed re-entrant. This is why the boolean parameter
handleWindowMessage is introduced and why I had to remove the invocation
of DispatchMessage out of the winWakeupHandler which is called in
WaitForSomething.
An alternative approach would be to move the Windows message pump into a
separate thread from the X server message dispatch. Unfortunately, this
would probably involve rather major changes, and careful examination of
I agree that this would cause a lot of more work than the approach of my
patch. I'm not sure if moving the Windows message handling into a
different thread will solve the problem totally: there still is the
problem, that in the modal windows event loop the x11 event processing
must be invoked. At least one has to totally decouple the x11 and
Windows event processing, but then still in the modal event loop the now
decoupled x11 processing must be triggered. So it seems to me, that
decoupling the x11 and Windows processing does only prevent upstream
changes but does not solve the problem, that in the modal Windows event
loop small progressing parts for X11 (coupled or decoupled) have to be done.
Alternatively, it might be worth investigating to see if it is possible
to use a message filter set with SetWindowsHookEx(WH_MSGFILTER) to run
the X window dispatch while Windows is in a modal loop?
I'm not sure if I'm understanding this approach correctly, but I think
even with SetWindowsHookEx we still have the problem, that the main loop
in Dispatch has to be broken into smaller parts that can be invoked from
inside the modal Windows event loop (or hook).
Best regards,
Oliver
--
Unsubscribe info: http://cygwin.com/ml
Re: redraw windows while resizing/moving windows in multiwindow mode
On 20/08/2011 23:41, Oliver Schmidt wrote: the following patch is a quick dirty hack to enable redrawing of windows while the user moves or resizes the window. This patch should be seen as experimental proof that this can be done with only small changes in the source code. This is fine as a proof of concept, and it would be nice to handle this better and do X window updates during the Windows modal resizing loop, but I don't think I can apply this patch. The main problem with window resizing/moving under Windows is, that in the function invocation stack dix/Dispatch - os/WaitForSomething - WakeupHandler - hw/xwin/winWakeupHandler - Windows/DispatchMessage - hw/xwin/winTopLevelWindowProc the Windows function DispatchMessage does not return while the user resizes/moves a window. This function only returns after the user releases the mouse button. However the dix/Dispatch functions must be run to allow the clients to process the queued redraw/resizing events. Well, in fact, no X events are processed while in the modal resizing loop, so for e.g. if you have ico running in another X window, it stops updating while an xterm window is being resized. Note that there are other modal loops in Windows message handling, I think moving the scrollbar also involves one (which can happen in windowed mode with the -scrollbar option) The enclosed hack simply moves the invocation of DispatchMessage in winWakeupHandler outside WaitForSomething into Dispatch and breaks up the Dispatch function into a loop and inner dispatch handling that can be called from the winTopLevelWindowProc while WM_SIZE/WM_MOVE events are processed. This could further be improved by setting a windows timer while resizing moving to process clients messages even if the mouse is not moved while resizing (and therefore WM_SIZE/WM_MOVE events are not send). What do you think about this idea? One problem here is, that the dix package is also affected. Of course some work must be done to cleanly integrate this into the existing dix/hw architecture. I'm not sure how to structure the change to Dispatch() in a way which would be acceptable upstream. An additional point to consider is that you may have introduced the possibility of re-entrancy into either the X window message dispatcher, or the Windows message dispatcher, which may not be safe. (e.g. winTopLevelProc - DispatchOneStep - (some X event processing calls a DDX function which calls SendMessage) - winTopLevelProc ...) An alternative approach would be to move the Windows message pump into a separate thread from the X server message dispatch. Unfortunately, this would probably involve rather major changes, and careful examination of all the places where the window drawing code accesses internal server state to see if locking was needed. (I think Xquartz is structured more like that) Alternatively, it might be worth investigating to see if it is possible to use a message filter set with SetWindowsHookEx(WH_MSGFILTER) to run the X window dispatch while Windows is in a modal loop? -- 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
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/
minimize redraw events after resizing/moving windows in multiwindow mode
Hi,
in multiwindow mode the modal moving/resizing of windows causes a lot of
redraw events send to the X clients after the userse releases the mouse
button. During the moving/resizing client windows are not redrawn as
long as the mouse button is pressed. But all redraw/resizing events are
queued and executed step after step after moving/resizing ends.
Some clients collect and combine multiple redraw or resizing events,
other clients (e.g. xterm) simply execute each redraw or sizing event.
The enclosed patch minimizes the events for clients to only one event
after the user releases the mouse button to end the moving/resizing.
This improves the user experience and reduces strange screen flickerings
especially on slow platforms.
The enclosed patch modifies winmultiwindowwndproc.c such that the
windows events WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE are considered that
are send from windows if the modal window resizing/moving begins or
ends. Only after WM_EXITSIZEMOVE the redraw/resizing is executed. The
patch is against the sources of xserver-cygwin version 1.10.3-1.
Best regards,
Oliver
diff --git a/cygwin/hw/xwin/winmultiwindowwndproc.c
b/cygwin/hw/xwin/winmultiwindowwndproc.c
index bd84c05..5f536d0 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,8 @@ 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: Wait for WM_EXITSIZEMOVE */
return 0;
case WM_SHOWWINDOW:
@@ -1012,6 +1014,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 +1048,13 @@ 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: wait for WM_EXITSIZEMOVE */
return 0; /* end of WM_SIZE handler */
case WM_STYLECHANGING:
--
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/
redraw windows while resizing/moving windows in multiwindow mode
()));
}
#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 */
--
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/
[PATCH 2/2] Cygwin/X: Ensure WM_STATE atom exists in multiwindow mode
Workaround a bug in iiimxcf (assuming the WM_STATE atom exists),
which can cause many Solaris clients to simply fail with a BadAtom
error
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xwin/winmultiwindowwm.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/xwin/winmultiwindowwm.c b/hw/xwin/winmultiwindowwm.c
index c2d506a..81b9d7f 100644
--- a/hw/xwin/winmultiwindowwm.c
+++ b/hw/xwin/winmultiwindowwm.c
@@ -1005,6 +1005,16 @@ winMultiWindowXMsgProc (void *pArg)
WM_CHANGE_STATE,
False);
+ /*
+iiimxcf had a bug until 2009-04-27, assuming that the
+WM_STATE atom exists, causing clients to fail with
+a BadAtom X error if it doesn't.
+
+Since this is on in the default Solaris 10 install,
+workaround this by making sure it does exist...
+ */
+ XInternAtom(pProcArg-pDisplay, WM_STATE, 0);
+
/* Loop until we explicitly break out */
while (1)
{
--
1.6.3.2
--
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/
xwin server crashes in multiwindow mode
Hello, xwin server crashes in multiwindow mode when launching it with xwin -multiwindow command (also launching with startx script). The server is working correctly launched with xwin . I had the screen log: $ Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 6.8.99.901-4 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: XWin -multiwindow _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 (II) XF86Config is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winSetEngine - Multi Window or Rootless = ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 1024 depth: 32 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 null screen fn ReparentWindow null screen fn RestackWindow InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Hello winMultiWindowXMsgProc - Calling pthread_mutex_lock () MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shar ed memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (II) Loading US keyboard layout. (--) winConfigKeyboard - Layout: E0010411 (0411) (--) Using preset keyboard for Japanese (411), type 7 Rules = xorg Model = jp106 Layout = jp Variant = (null) Options = (null ) (--) 3 mouse buttons found Could not init font path element /usr/X11R6/lib/X11/fonts/TTF/, removing from li st! Could not init font path element /usr/X11R6/lib/X11/fonts/Type1/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from li st! Could not init font path element /usr/X11R6/lib/X11/fonts/100dpi/, removing from list! winPointerWarpCursor - Discarding first warp: 640 512 winInitMultiWindowWM - pthread_mutex_lock () returned. winInitMultiWindowWM - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - pthread_mutex_lock () returned. winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 winMultiWindowXMsgProc - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 104333 [unknown (0x610)] XWin 3852 _cygtls::handle_exceptions: Error while dump ing state (probably corrupted stack) [1]+ Segmentation fault (core dumped) XWin.exe -multiwindow -- 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/
Windows HWND and X Clients in multiwindow mode
Hi, I am trying to write a program, that when running the X Server in multi-window mode keeps track of the association between the HWND value that MSWindows assigns to each window that is created, and the X Client that owns that window. Finding X Client that owns an X Window is quite simple, but I couldn't manage to then go a step further and find anything that binds the X Window to the MS Window. I tried using the devPrivates of the _Window struct, by using the winGetWindowPriv() macro. This gives a winPrivWinPtr variable, pointing to a struct which has, as one of its elements, an HWND variable. I thought it should provide the link, but in actual fact it did not as the HWND element was always 0 (zero). I also tried modifying the code of the X Server and recompiled it to see if it works there, but the same thing happened. So now I ask, what is it that I am missing out? I am sure it can be done, as the X Server must be doing it somewhere, but where? and how? Any help will be greatly appreciated. AJ Caruana -- 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: Windows HWND and X Clients in multiwindow mode
My apologies, I was checking the value of the HWND in the window privates too early. I was checking it before the server calls the MapWindow() function, which is the function which calls some other functions that in the end call the actual CreateWindowEx() of MS Windows. The CreateWindow() function of Xlib (and all the functions that it calls) do not create the HWND, so here I answered my own question. Thanks anyway. Regards AJ Caruana On 2/1/07, Alan James Caruana [EMAIL PROTECTED] wrote: Hi, I am trying to write a program, that when running the X Server in multi-window mode keeps track of the association between the HWND value that MSWindows assigns to each window that is created, and the X Client that owns that window. Finding X Client that owns an X Window is quite simple, but I couldn't manage to then go a step further and find anything that binds the X Window to the MS Window. I tried using the devPrivates of the _Window struct, by using the winGetWindowPriv() macro. This gives a winPrivWinPtr variable, pointing to a struct which has, as one of its elements, an HWND variable. I thought it should provide the link, but in actual fact it did not as the HWND element was always 0 (zero). I also tried modifying the code of the X Server and recompiled it to see if it works there, but the same thing happened. So now I ask, what is it that I am missing out? I am sure it can be done, as the X Server must be doing it somewhere, but where? and how? Any help will be greatly appreciated. AJ Caruana -- 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/
Window remains in background in multiwindow mode
Hi, I'm using Cygwin with the integrated Windows-based window manager as it is started in startxwin.bat: run XWin -multiwindow -clipboard -silent-dup-error The problem is as follows: - An application initially creates some windows. The newly created windows occur in foreground one after the other. = OK - If the application changes content in an already existing window, then it doesn't come into foreground unfortunately. It remains in background and so changes are not immediately visible on the screen. This problem doesn't exist if using a native window manager. It always makes sure to bring the respective window in foreground. A similar problem occurs with windows intended to be always on top. E.g. a text editors 'search window' that should be displayed always in foreground while being able to see and edit text at the same time. Regards, Udo -- 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/
multiwindow mode alt-space
Hi all, Is there a way to enable the alt-space menu in the Cygwin/X multiwindow manager? (The window in the upper left which has restore, move, size, minimize, maximize, and close). Most windows applications enable the use of alt-space to access that menu, but under multiwindow mode it does not appear to do anything. If there is no way to do this, is there a place where I may be able to file this as a feature request? Thank you for your time, Sherman -- 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/
Remote Java GUI window decoration in multiwindow mode
Hello, I'm running Cygwin/X in multiwindow mode and it works quite fine. However, if I try to start a Java GUI that uses default lookfeel window decoration on a remote box, I get the following error in the shell on the remote host and the application won't start: --- Xlib: unexpected async reply (sequence 0x7d)! --- To make things a little bit clearer: I'm running Windows XP Professional with Cygwin/X on my machine. Options to XWin are -multiwindow -clipboard -silent-dup-error. I open an xterm and do an ssh -Y remotehost. The remote host runs under Linux and has Sun JDK 1.4.2_05 installed. Then I start my Java GUI that has been told to use system look and feel window decorations. Then the error mentioned above occurs. There's no error entry in my Cygwin XWin.log. For those familiar with Java: The top level container is a JFrame and there's the following line in the application's source code: --- JFrame.setDefaultLookAndFeelDecorated(true); --- I have found three workarounds to this problem, but as the name suggests these are only workarounds and don't satisfy me. 1) Removing the line mentioned above from the source code and running without changed window decorations obviously solves this problem. ;) 2) It works, too, if I don't run Cygwin/X in multiwindow mode and use twm or openbox as window manager. 3) Another solution is to use JDK 5.0. I didn't recompile my application with JDK 5.0, but used the classes generated with 1.4.2_05 and was able to successfully start it with the JRE from JDK 5.0. However this way I have the standard Windows window decoration wrapped around the window decorations that are used on my Linux box. :( The last solution makes me wonder if this is actually a problem with multiwindow mode in Cygwin/X or a bug in the older JDK. Bye Michael -- Michael Denk Fakultät für Mathematik und Informatik Tel. +49 (0851) 509-3136 Universität Passau, Raum K08 IM (Aquarium) denk at fmi.uni-passau.dehttp://www.fmi.uni-passau.de/~denk
How do I get titlebars on client application windows in non-multiwindow mode?
I've recently installed cygwin-xfree 6.8.2.0-1 and cannot figure out how to get titlebars on my windows. How is this done? Thank-you, Gary --- ~ cat startwin.bat @echo off SET DISPLAY=127.0.0.1:0.0 SET CYGWIN_ROOT=\cygwin SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH% SET XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults SET XCMSDB=/usr/X11R6/lib/X11/Xcms.txt SET XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB SET XNLSPATH=/usr/X11R6/lib/X11/locale if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix if %OS% == Windows_NT goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP/2003 echo startxwin.bat - Starting on Windows NT/2000/XP/2003 :STARTUP run XWin -clipboard -silent-dup-error REM Startup an xterm, using bash as the shell. run xterm -geometry 80x25+4+4 -sl 1000 -sb -rightbar -ms blue -fg black -bg white -e /usr/bin/bash -l run xterm -geometry 80x25-4-4 -sl 1000 -sb -rightbar -ms blue -fg black -bg white -e /usr/bin/bash -l run xterm -geometry 80x25-4 -title -sl 1000 -sb -rightbar -ms blue -fg black -bg white -e /usr/bin/bash -l run xterm -geometry 80x25+4-4 -title test -sl 1000 -sb -rightbar -ms blue -fg black -bg white -e /usr/bin/bash -l --- Cygwin Configuration Diagnostics Current System Time: Mon Apr 11 08:28:44 2005 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem\ c:\j2sdk1.4.2_02\bin c:\Program Files\Common Files\GTK\2.0\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 12967(garyta) GID: 10545(mkgroup-l-d) 10545(mkgroup-l-d) Output from C:\cygwin\bin\id.exe (ntsec) UID: 12967(garyta) GID: 10545(mkgroup-l-d) 0(root) 544(Administrators) 545(Users) 1006(Debugger Users)10545(mkgroup-l-d) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\garyta' MAKE_MODE = `unix' PWD = `/home/garyta' USER = `garyta' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\garyta\Application Data' CLIENTNAME = `Console' COLORFGBG = `0;default;15' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMSPEC = `C:\WINDOWS\system32\cmd.exe' CVS_RSH = `/bin/ssh' DISPLAY = `:0' HOMEDRIVE = `Q:' HOMEPATH = `\' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\DC-BHM1' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PRINTER = `ActiveTouch Document Loader' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 3, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0803' PROGRAMFILES = `C:\Program Files' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `c:\DOCUME~1\garyta\LOCALS~1\Temp' TERM = `xterm' TMP = `c:\DOCUME~1\garyta\LOCALS~1\Temp' USERNAME = `garyta' USERPROFILE = `C:\Documents and Settings\garyta' WINDIR = `C:\WINDOWS' WINDOWID = `168114600' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/mnt/NX/fonts (default) = `C:\Program Files\NX Client for Windows\usr\X11R6\lib\X11\fonts' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/tmp (default) = `C:\Documents and Settings\garyta\.nx\tmp' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/mnt/NX/fonts (default) = `C:\Program Files\NX Client for Windows\usr\X11R6\lib\X11\fonts' HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts (default) =
Re: How do I get titlebars on client application windows in non-multiwindow mode?
On Mon, 11 Apr 2005, Gary Taylor wrote: I've recently installed cygwin-xfree 6.8.2.0-1 and cannot figure out how to get titlebars on my windows. How is this done? Start a window manager. Twm is installed with xorg-x11-bin but you may also install windowmaker or fvwm2. REM Windows NT/2000/XP/2003 echo startxwin.bat - Starting on Windows NT/2000/XP/2003 :STARTUP run XWin -clipboard -silent-dup-error run twm run xterm -geometry 80x25+4-4 -title test -sl 1000 -sb -rightbar -ms blue -fg black -bg white -e /usr/bin/bash -l -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
xtermcontrol --deiconify/--raise/--lower don't work in multiwindow mode
Hi, I have been working with the author of xtermcontrol to get it working nicely under Cygwin, and it seems to be working except for 3 issues I have noticed. (And I only noticed them as a fluke). Normally I run my X in fullscreen mode, using wmaker as my WindowManager. When I make xtermcontrol, and then do a 'make test', all the tests run as expected, and to completion. HOWEVER, when I get rid of .xserverrc and .xinitrc, and then do startx using native multiwindow mode, 'make test' does not quite work as expected. All color mappings work, but I have noticed that --deiconify, --raise and --lower do not have any effect. I was going to see if I could figure out where what's broken, but the X base is so huge, I'm not sure where to even start looking. Could someone look into this and see if these are broken, or could they point me to the proper place in the code base to look for myself? Thanks.
RE: Pointer bug in multiwindow mode (native window manager)
On Wed, 2 Jun 2004, Stef Simoens wrote: you can run XWin with -logverbose 3 parameter. This will print some debugging information to the logfile which may help figuring out why the cursor disappears. If you encounter the problem another time, please send me your /tmp/XWin.log I also have the 'dissapearing mouse pointer'-phenomenon. It mostly happens after a while. This is my logoutput (with -logverbose 3): Looking at the code I see that the debug messages are disabled in the release version. So the -logverbose 3 will not produce useful output for the debugging. But if you find a reproducible way to let the cursor disappear then i can trace it with my debug build. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
RE: Pointer bug in multiwindow mode (native window manager)
On June 2 Kris Thielemans wrote: As I already mentioned, occassionally my mouse pointer does not display anymore. This then happens for all open and new X-windows. I believe that this problem has been fixed in the source code but has not made its way into an official build. If possible grab the sources and have a build. There is one known cause of this: XP's remote desktop feature. When you come back to your machine after having a remote desktop session the cursor will disappear. There could be others as well. hth
Re: Pointer bug in multiwindow mode (native window manager)
On Tue, 1 Jun 2004, Tom Sobczynski wrote: Using the current Cygwin X Server in multiwindow mode (i.e. Windows native window manager), I get the X pointer when the mouse is in the menu, toolbar and scrollbar areas of Gnome applications. The problem goes away when I switch to rootless mode and run another window manager, such as metacity. Window managers normally set a default cursor for a newly created window if the application does not provide one. It seem the internal window manager does not. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
RE: Pointer bug in multiwindow mode (native window manager)
Using the current Cygwin X Server in multiwindow mode (i.e. Windows native window manager), I get the X pointer when the mouse is in the menu, toolbar and scrollbar areas of Gnome applications. The problem goes away when I switch to rootless mode and run another window manager, such as metacity. Window managers normally set a default cursor for a newly created window if the application does not provide one. It seem the internal window manager does not. this is a bit a different problem from mine. As I already mentioned, occassionally my mouse pointer does not display anymore. This then happens for all open and new X-windows. I cannot give explicit instructions how to reproduce this, but for example, yesterday it happened as follows: - start new X server using startxwin.bat (Xwin -multiwindow -clipboard) - in the xterm, I typed cd somedir; emacs that's it. emacs came up and my (X) pointer disappeared. However, this is not reproducible though. I have this both on NT 4.0sp6a and XP sp1. cygwin-setup says that all my packages are up-to-date, except that I'm still using cygwin.dll version 1.5.9-1. Kris
RE: Pointer bug in multiwindow mode (native window manager)
On Wed, 2 Jun 2004, Kris Thielemans wrote: Using the current Cygwin X Server in multiwindow mode (i.e. Windows native window manager), I get the X pointer when the mouse is in the menu, toolbar and scrollbar areas of Gnome applications. The problem goes away when I switch to rootless mode and run another window manager, such as metacity. Window managers normally set a default cursor for a newly created window if the application does not provide one. It seem the internal window manager does not. this is a bit a different problem from mine. As I already mentioned, occassionally my mouse pointer does not display anymore. This then happens for all open and new X-windows. I cannot give explicit instructions how to reproduce this, but for example, yesterday it happened as follows: - start new X server using startxwin.bat (Xwin -multiwindow -clipboard) - in the xterm, I typed cd somedir; emacs that's it. emacs came up and my (X) pointer disappeared. However, this is not reproducible though. I have this both on NT 4.0sp6a and XP sp1. cygwin-setup says that all my packages are up-to-date, except that I'm still using cygwin.dll version 1.5.9-1. you can run XWin with -logverbose 3 parameter. This will print some debugging information to the logfile which may help figuring out why the cursor disappears. If you encounter the problem another time, please send me your /tmp/XWin.log bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
RE: Pointer bug in multiwindow mode (native window manager)
you can run XWin with -logverbose 3 parameter. This will print some debugging information to the logfile which may help figuring out why the cursor disappears. If you encounter the problem another time, please send me your /tmp/XWin.log I also have the 'dissapearing mouse pointer'-phenomenon. It mostly happens after a while. This is my logoutput (with -logverbose 3): Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 6.7.0.0-9 Contact: [EMAIL PROTECTED] XWin was started with the following command line: Xwin -broadcast -clipboard -lesspointer -logverbose 3 -screen 0 1024 768 -once ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1400 h 1050 winInitializeDefaultScreens - Returning ddxProcessArgument - screen - Found ``W D'' arg _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winValidateArgs - Returning. (II) XF86Config is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1024 dwHeight: 768 winSetEngine - Using Shadow DirectDraw NonLocking winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1024 h: 768 winCreateBoundingWindowWindowed - Current w: 1024 h: 768 winAdjustForAutoHide - Original WorkArea: 0 0 1020 1400 winAdjustForAutoHide - Adjusted WorkArea: 0 0 1020 1400 winCreateBoundingWindowWindowed - WindowClient w 1024 h 768 r 1024 l 0 b 768 t 0 winCreateBoundingWindowWindowed - Returning winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Created primary surface winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface winAllocateFBShadowDDNL - lPitch: 4096 winAllocateFBShadowDDNL - Created shadow pitch: 4096 winAllocateFBShadowDDNL - Created shadow stride: 1024 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowDDNL - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winRandRInit () winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 040C (040c) (--) Using preset keyboard for French (Standard) (40c), type 4 Rules = xorg Model = pc105 Layout = fr Variant = (null) Options = (null Could not init font path element /usr/X11R6/lib/X11/fonts/TTF/, removing from li Could not init font path element /usr/X11R6/lib/X11/fonts/Speedo/, removing from Could not init font path element /usr/X11R6/lib/X11/fonts/Type1/, removing from Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from li Could not init font path element /usr/X11R6/lib/X11/fonts/100dpi/, removing from winPointerWarpCursor - Discarding first warp: 512 384 winBlockHandler - Releasing pmServerStarted winBlockHandler - pthread_mutex_unlock () returned winProcEstablishConnection - Hello winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client un winProcEstablishConnection - Hello winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client un winProcEstablishConnection - Hello winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client un winInitClipboard () winProcQueryTree - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 winProcEstablishConnection - Hello (...) a lot of winClipboardWindowProc messages, I don't think they are relevant here. Stef Simoens
Pointer bug in multiwindow mode (native window manager)
Using the current Cygwin X Server in multiwindow mode (i.e. Windows native window manager), I get the X pointer when the mouse is in the menu, toolbar and scrollbar areas of Gnome applications. The problem goes away when I switch to rootless mode and run another window manager, such as metacity. The About... box doesn't tell me what version I'm running, but it explicitly calls itself a work in progress so I'll refrain from submitting a bug report for that, but I upgraded Cygwin this morning. Cheers, Tom
Weird multiwindow mode problem
Hello, This is probably unimportant, but I thought I'd mention it just the same... :) I have my Windows Taskbar at the top of the screen (instead of the bottom as it is by default). Running XWin -multiwindow, I open an xterm and move it right to the bottom of the screen. I open another window (e.g. Explorer) and move it over the xterm, completely covering it, and then away again. There is a white line left, covering the bottom of the xterm, exactly as thick as the Windows Taskbar. Typing in the xterm doesn't remove this line, nor does using the scrollbar. Moving the xterm a few pixels up redisplays only those pixels that have now appeared above where the line was. The only was to get the entire xterm back again is to move the entire window above the height of the line. Does multiwindow mode make some assumptions about where the Windows Taskbar is placed? I tried -mwextwm and the problem doesn't appear. Any ideas? Antony. Yahoo! Messenger - Communicate instantly...Ping your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html
Font problem with xterm in multiwindow mode
Hello, OS: WinXP, Service Pack 1 Cygwin: 1.5.9-1 Cygwin-X11-base: 6.7.0.0-8 Cygwin-X11-bin: 6.7.0.0-4 readline: 4.3-5 I'm having a stange problem with xterm that only manifests itself when XWin is running in multiwindow mode. When I launch an either an xterm or rxvt, the line of the terminal the cursor is on is only half vertically displayed - only the top half of the text appears. Also, any text I enter appears garbled. As soon as I hit Enter, the new shell line that appears is trashed, but the previous line now displays properly. I've tried -swcursor -fn with various fonts, but no difference. I've tried XWin vanilla, -rootless, and even -mwextwm with xwinwm, and all of these work fine; its only multiwindow this happens with. I've tried setting and unsetting my LANG and LC_ALL settings; nothing. Anyone else come across this? Any ideas? Thanks, Tony. Yahoo! Messenger - Communicate instantly...Ping your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html
Re: Font problem with xterm in multiwindow mode
Ah - got it. Its a problem caused by WindowBlinds. Tony. ... Hello, OS: WinXP, Service Pack 1 Cygwin: 1.5.9-1 Cygwin-X11-base: 6.7.0.0-8 Cygwin-X11-bin: 6.7.0.0-4 readline: 4.3-5 I'm having a stange problem with xterm that only manifests itself when XWin is running in multiwindow mode. When I launch an either an xterm or rxvt, the line of the terminal the cursor is on is only half vertically displayed - only the top half of the text appears. Also, any text I enter appears garbled. As soon as I hit Enter, the new shell line that appears is trashed, but the previous line now displays properly. I've tried -swcursor -fn with various fonts, but no difference. I've tried XWin vanilla, -rootless, and even -mwextwm with xwinwm, and all of these work fine; its only multiwindow this happens with. I've tried setting and unsetting my LANG and LC_ALL settings; nothing. Anyone else come across this? Any ideas? Thanks, Tony. Yahoo! Messenger - Communicate instantly...Ping your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html
Re: GDI leak fixed in multiwindow mode, thanks to Kensuke's work
Earle, It seems that we've got a lot of cut-n-pasted code in XWin. :( If someone has a few spare hours they should see if we can add a common multiwindow utility function file for things like generating class names or reloading the g_hiconX. I thought same thing when I tested off-by-one error and GDI leaks. MWExtWM's windows cursor and sizing/moving window improvement may be able to apply to multiwindow mode. Kensuke Matsuzaki -- Kensuke Matsuzaki mailto:[EMAIL PROTECTED] http://peppermint.jp
GDI leak fixed in multiwindow mode, thanks to Kensuke's work
I've just CVS commited a 1-line patch for the GDI leak I found last night. It's actually the same patch Kensuke did a few hours ago, but it wasn't applied to the MultiWindow files. [I'm not complaining, I forgot to apply the off-by-one classname fix to Kensuke's rootless code, too...] It seems that we've got a lot of cut-n-pasted code in XWin. :( If someone has a few spare hours they should see if we can add a common multiwindow utility function file for things like generating class names or reloading the g_hiconX.
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Earle, At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote: You give me a good insight to improve Z order handling. I believe we can approach to better solutions. The attached is my latest code which should fix all problems on restacking and a-o-t windows without using fAlwaysOnTop flag. Could you try and review this? After 48 hours of continuous running in a mixed environment of both X and Windows apps I haven't noticed any problems at all, and I've seen from the logfile that the fRestacking flag has captured and killed some recursive restacks as expected from looking at your code. Thank you very much for the hard test, I cleaned the code and commited it. I'm glad to see the result of our cooperative development. The only glitch I have seen, and this is NOT new, is that when the Win32 Z order changes because of a right-click system menu or a click-and-drag to move a window, the X window is only restacked at the end of the menu or move operation. I'm also aware of this bug but I won't fix it for now. As a note for the commit, I just commented out your code on PreserveWin32Stack() by '#if 0' because it is nice for use from wm thread. We can utilize it in the future. There are still some possibilities to optimization, one of which is the performance of winReorderWindowsMultiWindow() as you pointed out before. However more optimizations need detailed examination into DIX code (to understand X's Restack operation) despite relatively little speed-up. So I finish the series of my optimizations to -multiwindow mode. Of course any enhancement is welcome. Takuma Murakami
Re: [SOLVED] MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
Hey!! I didn't notice it immediately, but now the problem has disappeared (maybe because the new xterm-185?): speed is now 38400 as it should be. Thomas Dickey wrote: On Wed, 25 Feb 2004, Alexander Gottwald wrote: On Wed, 25 Feb 2004, Danilo Turina wrote: In effect opening an xterm within rootless mode I can see from stty that the terminal speed is 38400, while opening the same terminal from multiwindow mode I see that the speed is 0 (the same does not happens for rxvt for which stty always reports 38400). I've started bash the following ways: cmd.exe : speed 38400 - xterm.exe : speed 38400 - xterm.exe : speed 38400 XWin.exe (multiwindow) - xterm.exe : speed 0 XWin.exe (no multiwindow) - xterm.exe : speed 0 - xterm.exe : speed 0 XWin.exe (build with console window) - xterm.exe : speed 0 It seems the newly started xterm inherits the speed settings from the starting program. not exactly (I've rebooted to test cygwin, see that BAUD_0 isn't defined). I think the issue is that the ioctl to set the baud rate fails. It doesn't inherit the speed settings, since xterm always sets it. Seeing why it works for rxvt would be useful, for instance. Baud rate for a terminal emulator is bogus anyway - the reason why it is set is to give ncurses a hint about padding. I changed it from 9600 to 38400 a few years ago, and rxvt followed suit. The only solution seems to start the xterms from a windows console. for now, true. -- -- Danilo Turina Alcatel Optics OND Network Management Rieti (Italy) - Phone: +39 0746 600332 -- 2 anni 11 mesi 15 giorni 8 ore 15 minuti 29 secondi
Re: [SOLVED] MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
On Wed, 24 Mar 2004, Danilo Turina wrote: Hey!! I didn't notice it immediately, but now the problem has disappeared (maybe because the new xterm-185?): speed is now 38400 as it should be. But I didn't change anything in xterm. It would probably be something changed in the environment which executes xterm. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: [SOLVED] MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
Thomas Dickey wrote: On Wed, 24 Mar 2004, Thomas Dickey wrote: On Wed, 24 Mar 2004, Danilo Turina wrote: Hey!! I didn't notice it immediately, but now the problem has disappeared (maybe because the new xterm-185?): speed is now 38400 as it should be. But I didn't change anything in xterm. It would probably be something changed in the environment which executes xterm. on second thought - it is possible that there is a difference between the define's used by imake versus those derived from the configure script. We did also jump from 174 to 185... don't know if there were changes in that time period related to this or if you were already aware of that when you made your comment that not much changed. Harold
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Hi Takuma, At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote: You give me a good insight to improve Z order handling. I believe we can approach to better solutions. The attached is my latest code which should fix all problems on restacking and a-o-t windows without using fAlwaysOnTop flag. Could you try and review this? After 48 hours of continuous running in a mixed environment of both X and Windows apps I haven't noticed any problems at all, and I've seen from the logfile that the fRestacking flag has captured and killed some recursive restacks as expected from looking at your code. The only glitch I have seen, and this is NOT new, is that when the Win32 Z order changes because of a right-click system menu or a click-and-drag to move a window, the X window is only restacked at the end of the menu or move operation. I don't see any reason to not commit your changes to CVS as soon as possible! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Harold, At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote: You give me a good insight to improve Z order handling. I believe we can approach to better solutions. The attached is my latest code which should fix all problems on restacking and a-o-t windows without using fAlwaysOnTop flag. Could you try and review this? It works great from my testing today! On Monday I'll bring it to work for a harder test, I normally have 10 or so emacs and xterms running with an occasional EDA tool. (It seems that cygwin's emacs-x11 has some problems, not due to these changes, so I can't get too many started locally to test...) I haven't gotten a chance to test Takuma's new patch yet, so I was wondering if you have checked what happens when you open two xterms, place a Cygwin bash shell inbetween them in the Z order partially overlapping with both of them, then minimize one xterm and then the Cygwin bash shell... you'll have to play with the ordering a little bit, but see if you can get it to have one xterm showing the contents of the other xterm where they were previously overlapping. That was a bug that we have had before and Takuma's changes from last week re-introduced that bug. I'm not sure if his new patch was an attempt to fix that or not... but this is something that somebody will need to fix and I'd appreciate it if you had some insight if this is not already fixed. I revived winReorderWindowsMultiWindow() to fix the bug, which I call restacking bug. And it is called much less frequently than before (from winBlockHandler()). I believe Earle will confirm this by his hard tests. Takuma Murakami
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Earle, You give me a good insight to improve Z order handling. I believe we can approach to better solutions. The attached is my latest code which should fix all problems on restacking and a-o-t windows without using fAlwaysOnTop flag. Could you try and review this? Tamuka Murakami wrote... Popups on a-o-t windows are having problems and should be fixed. Did you fix it without reviving fAlwaysOnTop? I'm interested in the solution. Yes, this does not require the flag. Basically, any overridden window is now moved to the absolute top of the Z order, not just the top of the regular stack. It's a 1 line change in winmultiwindowwndproc.c. It must be the SetWindowPos() in the winTopLevelWindowProc's WM_SHOWWINDOW handler. I removed SWP_NOACTIVATE flag since popups can't get into the front with the flag. 1) Is minimization of a-o-t windows broken on release-59? 2) Does the CVS build fix restacking problem? Now it's quite clear to me, the culprit is my restacking bug. If Earle's solution fixes #2, then it is what we've sought for. Even if it doesn't fix it, he gives a nice stepping stone to the final solution. I'll look at the code for a while. I'll have to read the archives some more to understand what you mean by the restacking bug, but FWIW there's a new function called PreserveWin32Stack in winmultiwindowwm.c which just walks the Win32 window stack after a map or a raise and forces the X stack to be in the same order. It's implemented now just as a series of XRaiseWindows (it may be possible to use the X combined restacking function)... In recent changes I made winRestackWindowMultiWindow empty and removed winReorderWindowsMultiWindow(), which were my fault and forced you to reinvent PreserveWin32Stack(). I think winReorderWindowsMultiWindow() is Kensuke's version of PreserveWin32Stack(). He does the work in X server's internal function (ConfigureWindow) while you do through WM thread (XRaiseWindow). Due to the changes propagation of Z order changes between X and Windows were not correctly performed; that's the restacking bug I've mentioned. Takuma Murakami noaot.patch Description: Binary data
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Hello Takuma, At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote: You give me a good insight to improve Z order handling. I believe we can approach to better solutions. The attached is my latest code which should fix all problems on restacking and a-o-t windows without using fAlwaysOnTop flag. Could you try and review this? It works great from my testing today! On Monday I'll bring it to work for a harder test, I normally have 10 or so emacs and xterms running with an occasional EDA tool. (It seems that cygwin's emacs-x11 has some problems, not due to these changes, so I can't get too many started locally to test...) of the regular stack. It's a 1 line change in winmultiwindowwndproc.c. It must be the SetWindowPos() in the winTopLevelWindowProc's WM_SHOWWINDOW handler. I removed SWP_NOACTIVATE flag since popups can't get into the front with the flag. Yes, seems fine w/o that flag set. The HWND_TOPMOST still gets set fine, and menus stay in the top z-pane. I just put it in there because during some intermediate testings I left all created windows as OVERLAPPEDWINDOW and not set back to POPUP (for the cascading). In recent changes I made winRestackWindowMultiWindow empty I was wondering about the #if 0 on this section, but your new reorder routine seems to keep things working 100%. and removed winReorderWindowsMultiWindow(), which were my fault and forced you to reinvent PreserveWin32Stack(). I think winReorderWindowsMultiWindow() is Kensuke's version of PreserveWin32Stack(). He does the work in X server's internal function (ConfigureWindow) while you do through WM thread (XRaiseWindow). Yes, I'm more familiar with Xlib than internal DDX routines, so chose the one I understood. The restacking you've put back in the ReorderMW works just as well, or probably better. One thing I was worried about, and I see that you've taken care of, is the fact that since we iterate over the Win32 window stack and do a series of ConfigureWindow/etc., those ConfigureWindows() might cause yet another Restack call, resulting in up to ((n*(n-1))/2) calls. The fRestacking flag you put back in looks like the easiest way of handling this... Thanks, I'll let you know if anything pops up in my testing! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Earle, Earle F. Philhower III wrote: Hello Takuma, At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote: You give me a good insight to improve Z order handling. I believe we can approach to better solutions. The attached is my latest code which should fix all problems on restacking and a-o-t windows without using fAlwaysOnTop flag. Could you try and review this? It works great from my testing today! On Monday I'll bring it to work for a harder test, I normally have 10 or so emacs and xterms running with an occasional EDA tool. (It seems that cygwin's emacs-x11 has some problems, not due to these changes, so I can't get too many started locally to test...) I haven't gotten a chance to test Takuma's new patch yet, so I was wondering if you have checked what happens when you open two xterms, place a Cygwin bash shell inbetween them in the Z order partially overlapping with both of them, then minimize one xterm and then the Cygwin bash shell... you'll have to play with the ordering a little bit, but see if you can get it to have one xterm showing the contents of the other xterm where they were previously overlapping. That was a bug that we have had before and Takuma's changes from last week re-introduced that bug. I'm not sure if his new patch was an attempt to fix that or not... but this is something that somebody will need to fix and I'd appreciate it if you had some insight if this is not already fixed. and removed winReorderWindowsMultiWindow(), which were my fault and forced you to reinvent PreserveWin32Stack(). I think winReorderWindowsMultiWindow() is Kensuke's version of PreserveWin32Stack(). He does the work in X server's internal function (ConfigureWindow) while you do through WM thread (XRaiseWindow). Yes, I'm more familiar with Xlib than internal DDX routines, so chose the one I understood. The restacking you've put back in the ReorderMW works just as well, or probably better. One thing I was worried about, and I see that you've taken care of, is the fact that since we iterate over the Win32 window stack and do a series of ConfigureWindow/etc., those ConfigureWindows() might cause yet another Restack call, resulting in up to ((n*(n-1))/2) calls. The fRestacking flag you put back in looks like the easiest way of handling this... Thanks, I'll let you know if anything pops up in my testing! Glad to know that you guys are looking at this in depth. :) Harold
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Earle, Thank you for your comments and commits. That not only fixes a-o-t problems but also gives hints for the ongoing restacking problem. Let me confirm some points to make things clear. Minimized always-on-top windows never disappear from in front of other X windows in all the tests I've tried. I can't reproduce this behaviour with release-59. I made two windows overlapped, set one of them as a-o-t, then minimized the a-o-t window. The second window was shown correctly. Could you show me how to reproduce it? And when a non-aot window is created on top of an a-o-t one, it is popped to the top of the X window stack, even if there is an a-o-t window in Win32 space above it. It's as if a chunk of the window below the aot window is showing through, and a real pain. (It's caused by XRaiseWindow()ing a window that's not really at the top of the Win32 stack...) I can't reproduce it with release-59. Maybe I am doing the tests in a wrong way... Could you point it out? I've cleaned all this up in my local copy, and made Emacs/xterm menus work properly in a-o-t mode (they don't disappear!) without stepping on any of Takuma's changes. Popups on a-o-t windows are having problems and should be fixed. Did you fix it without reviving fAlwaysOnTop? I'm interested in the solution. However, I can't get minimization to work without turning off the Win32 a-o-t setting on the window during the minimize... As I wrote above, I think it is achieved in current releases. The old behavior was to copy the current a-o-t state to a private flag in pWinPriv on a minimize, remove the a-o-t bit from the window, and on a restore set the a-o-t flag back on the Win32 window if so cached. If I put this flag and behavior back I can get things working 100% AFAICT: a-o-t windows minimized from the taskbar, the system menu, or the button disappear. Takuma, if you're reading the list, can you give some insight as to why you took out the old private flag? (I agree it should be cached in the wndproc on the WM_SIZE message, not the SC_* menu handler where it was, that's where I've got it placed presently, and it now works for all different methods of minimizing a window I can think of...) In the change I fixed window manipulation (remove, resize, minimize and maximize). My principle is to have Windows do as much work as possible; I let Windows all window operations and propagate the resulting position and size to underlying X windows through winAdjustXWindow(). Within the process I removed some cache variables including fAlwaysOnTop since they seemed unnecessary. I did basic tests so minimization of a-o-t windows should be work fine. I want to go on without fAlwaysOnTop flag if we can. However popups on a-o-t windows are surely broken, it is my fault. I built and ran on the latest CVS. It works fine with popups on a-o-t windows (it yields some BadWindow errors but they cause no actual faults.) It could be the best solution. What we should verify now are: 1) Is minimization of a-o-t windows broken on release-59? 2) Does the CVS build fix restacking problem? I appreciate anyone who gives feedbacks on item 1. Item 2 is about the problem on which Harold and I are working so Harold can verify it. Takuma Murakami
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Takuma Murakami wrote: Minimized always-on-top windows never disappear from in front of other X windows in all the tests I've tried. I can't reproduce this behaviour with release-59. I made two windows overlapped, set one of them as a-o-t, then minimized the a-o-t window. The second window was shown correctly. Could you show me how to reproduce it? 4.3.0-59 would not have this problem because it does not yet contain your recent changes to multi-window mode. This problem would only show up in the CVS builds. And when a non-aot window is created on top of an a-o-t one, it is popped to the top of the X window stack, even if there is an a-o-t window in Win32 space above it. It's as if a chunk of the window below the aot window is showing through, and a real pain. (It's caused by XRaiseWindow()ing a window that's not really at the top of the Win32 stack...) I can't reproduce it with release-59. Maybe I am doing the tests in a wrong way... Could you point it out? Yup, try with CVS :) The old behavior was to copy the current a-o-t state to a private flag in pWinPriv on a minimize, remove the a-o-t bit from the window, and on a restore set the a-o-t flag back on the Win32 window if so cached. If I put this flag and behavior back I can get things working 100% AFAICT: a-o-t windows minimized from the taskbar, the system menu, or the button disappear. Takuma, if you're reading the list, can you give some insight as to why you took out the old private flag? (I agree it should be cached in the wndproc on the WM_SIZE message, not the SC_* menu handler where it was, that's where I've got it placed presently, and it now works for all different methods of minimizing a window I can think of...) In the change I fixed window manipulation (remove, resize, minimize and maximize). My principle is to have Windows do as much work as possible; I let Windows all window operations and propagate the resulting position and size to underlying X windows through winAdjustXWindow(). Within the process I removed some cache variables including fAlwaysOnTop since they seemed unnecessary. I did basic tests so minimization of a-o-t windows should be work fine. I want to go on without fAlwaysOnTop flag if we can. However popups on a-o-t windows are surely broken, it is my fault. I built and ran on the latest CVS. It works fine with popups on a-o-t windows (it yields some BadWindow errors but they cause no actual faults.) It could be the best solution. What we should verify now are: 1) Is minimization of a-o-t windows broken on release-59? 2) Does the CVS build fix restacking problem? I appreciate anyone who gives feedbacks on item 1. Item 2 is about the problem on which Harold and I are working so Harold can verify it. I think that #2 was not touched by Earle. I'll have to check though. Harold
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
4.3.0-59 would not have this problem because it does not yet contain your recent changes to multi-window mode. This problem would only show up in the CVS builds. I can't reproduce it with release-59. Maybe I am doing the tests in a wrong way... Could you point it out? Yup, try with CVS :) I have completely misunderstood the problem :( 1) Is minimization of a-o-t windows broken on release-59? 2) Does the CVS build fix restacking problem? I think that #2 was not touched by Earle. I'll have to check though. Now it's quite clear to me, the culprit is my restacking bug. If Earle's solution fixes #2, then it is what we've sought for. Even if it doesn't fix it, he gives a nice stepping stone to the final solution. I'll look at the code for a while. Takuma Murakami
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Hi Takuma, thanks for your responses! This is in answer to your two earlier messages... Tamuka Murakami wrote... Popups on a-o-t windows are having problems and should be fixed. Did you fix it without reviving fAlwaysOnTop? I'm interested in the solution. Yes, this does not require the flag. Basically, any overridden window is now moved to the absolute top of the Z order, not just the top of the regular stack. It's a 1 line change in winmultiwindowwndproc.c. 1) Is minimization of a-o-t windows broken on release-59? 2) Does the CVS build fix restacking problem? Now it's quite clear to me, the culprit is my restacking bug. If Earle's solution fixes #2, then it is what we've sought for. Even if it doesn't fix it, he gives a nice stepping stone to the final solution. I'll look at the code for a while. I'll have to read the archives some more to understand what you mean by the restacking bug, but FWIW there's a new function called PreserveWin32Stack in winmultiwindowwm.c which just walks the Win32 window stack after a map or a raise and forces the X stack to be in the same order. It's implemented now just as a series of XRaiseWindows (it may be possible to use the X combined restacking function)... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Changes to multiwindow mode and always-on-top (ping Takuma)
Hi all, I've been hacking away fixing up the support for always-on-top mode which seems to have been broken since the upgrades Takuma did about 3 weeks ago (~v1.1.6.2? of multiwndproc, etc). Minimized always-on-top windows never disappear from in front of other X windows in all the tests I've tried. And when a non-aot window is created on top of an a-o-t one, it is popped to the top of the X window stack, even if there is an a-o-t window in Win32 space above it. It's as if a chunk of the window below the aot window is showing through, and a real pain. (It's caused by XRaiseWindow()ing a window that's not really at the top of the Win32 stack...) I've cleaned all this up in my local copy, and made Emacs/xterm menus work properly in a-o-t mode (they don't disappear!) without stepping on any of Takuma's changes. However, I can't get minimization to work without turning off the Win32 a-o-t setting on the window during the minimize... The old behavior was to copy the current a-o-t state to a private flag in pWinPriv on a minimize, remove the a-o-t bit from the window, and on a restore set the a-o-t flag back on the Win32 window if so cached. If I put this flag and behavior back I can get things working 100% AFAICT: a-o-t windows minimized from the taskbar, the system menu, or the button disappear. Takuma, if you're reading the list, can you give some insight as to why you took out the old private flag? (I agree it should be cached in the wndproc on the WM_SIZE message, not the SC_* menu handler where it was, that's where I've got it placed presently, and it now works for all different methods of minimizing a window I can think of...) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Earle, Earle F. Philhower III wrote: Hi all, I've been hacking away fixing up the support for always-on-top mode which seems to have been broken since the upgrades Takuma did about 3 weeks ago (~v1.1.6.2? of multiwndproc, etc). Minimized always-on-top windows never disappear from in front of other X windows in all the tests I've tried. And when a non-aot window is created on top of an a-o-t one, it is popped to the top of the X window stack, even if there is an a-o-t window in Win32 space above it. It's as if a chunk of the window below the aot window is showing through, and a real pain. (It's caused by XRaiseWindow()ing a window that's not really at the top of the Win32 stack...) Yup, Takuma knew there were bugs, but the new code is so much more efficient (the old code was performing lots of operations during our block and wakeup handlers, which get called hundreds of times per second) that I told him to leave it there for a few weeks until we could figure out if we could fix it and keep the performance improvement. I've cleaned all this up in my local copy, and made Emacs/xterm menus work properly in a-o-t mode (they don't disappear!) without stepping on any of Takuma's changes. However, I can't get minimization to work without turning off the Win32 a-o-t setting on the window during the minimize... Hmm... if you have it mostly fixed, then check it in... Takuma is currently burning cycles trying to fix this also but I don't think he has gotten far. I think he will appreciate having a little help :) The old behavior was to copy the current a-o-t state to a private flag in pWinPriv on a minimize, remove the a-o-t bit from the window, and on a restore set the a-o-t flag back on the Win32 window if so cached. If I put this flag and behavior back I can get things working 100% AFAICT: a-o-t windows minimized from the taskbar, the system menu, or the button disappear. That sounds good. Takuma was talking about re-adding the fRestacking flag... is that the flag you are talking about? Takuma, if you're reading the list, can you give some insight as to why you took out the old private flag? (I agree it should be cached in the wndproc on the WM_SIZE message, not the SC_* menu handler where it was, that's where I've got it placed presently, and it now works for all different methods of minimizing a window I can think of...) My guess is that he will agree... but I imagine he'll reply soon anyway. Harold
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
This just in: Takuma said go ahead and commit both fixes so he can review them. He says he will be able to respond sometime after four hours. (He is in #cygwinx on irc.freenode.net now.) Harold
Re: Changes to multiwindow mode and always-on-top (ping Takuma)
Howdy, At 02:05 AM 3/19/2004 -0500, Harold wrote: Yup, Takuma knew there were bugs, but the new code is so much more efficient (the old code was performing lots of operations during our block and wakeup handlers, which get called hundreds of times per second) that I told him to leave it there for a few weeks until we could figure out if we could fix it and keep the performance improvement. Yes, it's way faster than before with his changes, but sometimes it seems to have optimized too many screen updates. These only seem to be occasional glitches, and forcing a redraw of the window always clears things up (except for the stacking order stuff). I fixed things up the straightforward way: When a WM_RAISE or WM_MAP event filters to us, I start with the mapped window, xvert it to the HWND, and work a way through Win32 space up to the top of the Z order. Any window that's still above the HWND we just XRaise()ed, I XRaise the XWindow of that HWND. AFAICT this will only occur with AOT windows, and should result in 0 work at all if there aren't any AOTs... Hmm... if you have it mostly fixed, then check it in... Takuma is currently burning cycles trying to fix this also but I don't think he has gotten far. I think he will appreciate having a little help :) All I've really fixed, AFAIK, is the case where the X and W32 stack order aren't the same...I doubt this is what he's having trouble with, it's too simple. If I put this flag and behavior back I can get things working 100% AFAICT: a-o-t windows minimized from the taskbar, the system menu, or the button disappear. That sounds good. Takuma was talking about re-adding the fRestacking flag... is that the flag you are talking about? No, unfortunately this is just a bit for the HWND_TOPMOST state of the window when it's minimized. Without clearing the TOPMOST state in W32, the window technically stay on top of other windows since a SIZE_MINIMIZE is handled by an ignored MOVE (-32000,-32000) IIRC. Regular apps don't care since they always have a consistent view of a window's position, but in this case we have X which thinks the window is still at (x,y) and Windoze which has it as (-32k,-32k)... [5 minutes later...] This just in: Takuma said go ahead and commit both fixes so he can review them. He says he will be able to respond sometime after four hours. (He is in #cygwinx on irc.freenode.net now.) OK, it is checked in (sorry if no xorg-commit mail, I think my pdx.freedesktop.org CVS account has a real name that's not valid...) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
Hello everybody, it's some time I'm using Cygwin and XFree and I feel very satisfied with both them. Until today, I always have used the rootless mode + wmaker (which I like very much). Anyway this morning I tried to switch to the multiwindow mode. Having customized the contextual menu of wmaker, I wished to port those menu items into the XWin menu modifying .XWinrc. I have unable to do that, because most of those menu items are xterms that rlogins toward HP-UX machines, and they do not work anymore into multiwindow mode. The problem seems related to the stty speed parameter. In effect opening an xterm within rootless mode I can see from stty that the terminal speed is 38400, while opening the same terminal from multiwindow mode I see that the speed is 0 (the same does not happens for rxvt for which stty always reports 38400). Searching Google I found that Speed == 0 means hang up for some machines (e.g. Sun or HP-UX). A solution suggested by this Google search was to modify /etc/profile adding something like that: if [ -n $DISPLAY -a $TERM = xterm ] ; then stty 38400 fi In effect this modification solves the problem for rlogins launched manually by an xterm, but I does not affect at all commands inserted into .XWinrc (they look like xterm -e rlogin machine -l user). I tried several ways to put the speed to 38400 for those menu entries but I have always failed. Is there a way to do that? Ciao, Danilo -- -- Danilo Turina Alcatel Optics OND Network Management Rieti (Italy) - Phone: +39 0746 600332 -- 2 anni 10 mesi 16 giorni 1 ora 1 minuto 7 secondi
Re: MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
On Wed, 25 Feb 2004, Danilo Turina wrote: In effect this modification solves the problem for rlogins launched manually by an xterm, but I does not affect at all commands inserted into .XWinrc (they look like xterm -e rlogin machine -l user). I tried several ways to put the speed to 38400 for those menu entries but I have always failed. Is there a way to do that? A shell script could do that (which in turn does the rlogin, etc.) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
Thomas Dickey wrote: On Wed, 25 Feb 2004, Danilo Turina wrote: In effect this modification solves the problem for rlogins launched manually by an xterm, but I does not affect at all commands inserted into .XWinrc (they look like xterm -e rlogin machine -l user). I tried several ways to put the speed to 38400 for those menu entries but I have always failed. Is there a way to do that? A shell script could do that (which in turn does the rlogin, etc.) In effect I use a script to open the terminals, but if I try to put stty 38400 into that script it does not work when invoked by the XWin menu, it reports an error related to the fact that stdin is not a terminal. -- -- Danilo Turina Alcatel Optics OND Network Management Rieti (Italy) - Phone: +39 0746 600332 -- 2 anni 10 mesi 16 giorni 1 ora 55 minuti 55 secondi
Re: MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
On Wed, 25 Feb 2004, Danilo Turina wrote: Thomas Dickey wrote: On Wed, 25 Feb 2004, Danilo Turina wrote: In effect this modification solves the problem for rlogins launched manually by an xterm, but I does not affect at all commands inserted into .XWinrc (they look like xterm -e rlogin machine -l user). I tried several ways to put the speed to 38400 for those menu entries but I have always failed. Is there a way to do that? A shell script could do that (which in turn does the rlogin, etc.) In effect I use a script to open the terminals, but if I try to put stty 38400 into that script it does not work when invoked by the XWin menu, it reports an error related to the fact that stdin is not a terminal. hmm - I don't use rlogin much any more, but it sounds as if that's working around that issue. Looking at the code, it seems that if BAUD_0 is defined (e.g., in the header files), that stops xterm from setting a baud rate. You should be able to compile xterm with that turned off (by adding an #undef BAUD_0 before its first use in main.c). xterm's ttyModes resource would be a suitable place to make that configurable, but currently it's done at compile time). I made a note to check on that (it's been that way for a long time). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
On Wed, 25 Feb 2004, Danilo Turina wrote: In effect opening an xterm within rootless mode I can see from stty that the terminal speed is 38400, while opening the same terminal from multiwindow mode I see that the speed is 0 (the same does not happens for rxvt for which stty always reports 38400). I've started bash the following ways: cmd.exe : speed 38400 - xterm.exe : speed 38400 - xterm.exe : speed 38400 XWin.exe (multiwindow) - xterm.exe : speed 0 XWin.exe (no multiwindow) - xterm.exe : speed 0 - xterm.exe : speed 0 XWin.exe (build with console window) - xterm.exe : speed 0 It seems the newly started xterm inherits the speed settings from the starting program. The only solution seems to start the xterms from a windows console. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 Chemnitzer Linux-Tag 2004 - 6. und 7. März 2004 http://www.tu-chemnitz.de/linux/tag
Re: MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
Alexander Gottwald wrote: On Wed, 25 Feb 2004, Danilo Turina wrote: In effect opening an xterm within rootless mode I can see from stty that the terminal speed is 38400, while opening the same terminal from multiwindow mode I see that the speed is 0 (the same does not happens for rxvt for which stty always reports 38400). I've started bash the following ways: cmd.exe : speed 38400 - xterm.exe : speed 38400 - xterm.exe : speed 38400 XWin.exe (multiwindow) - xterm.exe : speed 0 XWin.exe (no multiwindow) - xterm.exe : speed 0 - xterm.exe : speed 0 XWin.exe (build with console window) - xterm.exe : speed 0 It seems the newly started xterm inherits the speed settings from the starting program. Yes, it's true. On the contrary replace xterm with rxvt all works properly. Another example of that is the following: XWin.exe (multiwindow) - xterm.exe : speed 0 - rxvt.exe : speed 38400 - xterm.exe : speed 38400 The only solution seems to start the xterms from a windows console. bye ago -- -- Danilo Turina Alcatel Optics OND Network Management Rieti (Italy) - Phone: +39 0746 600332 -- 2 anni 10 mesi 16 giorni 2 ore 30 minuti 8 secondi
Re: MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
On Wed, 25 Feb 2004, Alexander Gottwald wrote: On Wed, 25 Feb 2004, Danilo Turina wrote: In effect opening an xterm within rootless mode I can see from stty that the terminal speed is 38400, while opening the same terminal from multiwindow mode I see that the speed is 0 (the same does not happens for rxvt for which stty always reports 38400). I've started bash the following ways: cmd.exe : speed 38400 - xterm.exe : speed 38400 - xterm.exe : speed 38400 XWin.exe (multiwindow) - xterm.exe : speed 0 XWin.exe (no multiwindow) - xterm.exe : speed 0 - xterm.exe : speed 0 XWin.exe (build with console window) - xterm.exe : speed 0 It seems the newly started xterm inherits the speed settings from the starting program. not exactly (I've rebooted to test cygwin, see that BAUD_0 isn't defined). I think the issue is that the ioctl to set the baud rate fails. It doesn't inherit the speed settings, since xterm always sets it. Seeing why it works for rxvt would be useful, for instance. Baud rate for a terminal emulator is bogus anyway - the reason why it is set is to give ncurses a hint about padding. I changed it from 9600 to 38400 a few years ago, and rxvt followed suit. The only solution seems to start the xterms from a windows console. for now, true. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
This issue has to have something to do with the way that commands are
launched from the .XWinrc menu, since launching an xterm from another
xterm works just fine. Here is the code that launches commands
specified in the .XWinrc menus:
case CMD_EXEC:
if (fork()==0)
{
struct rlimit rl;
unsigned long i;
/* Close any open descriptors except for STD* */
getrlimit (RLIMIT_NOFILE, rl);
for (i = STDERR_FILENO+1; i rl.rlim_cur; i++)
close(i);
/* Disassociate any TTYs */
setsid();
execl (/bin/sh,
/bin/sh,
-c,
m-menuItem[j].param,
NULL);
exit (0);
}
I'm looking into it a little bit, but I think that others could shed
some light on this.
Harold
Re: MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
On Wed, 25 Feb 2004, Harold L Hunt II wrote:
This issue has to have something to do with the way that commands are
launched from the .XWinrc menu, since launching an xterm from another
xterm works just fine. Here is the code that launches commands
specified in the .XWinrc menus:
case CMD_EXEC:
if (fork()==0)
{
struct rlimit rl;
unsigned long i;
/* Close any open descriptors except for STD* */
getrlimit (RLIMIT_NOFILE, rl);
for (i = STDERR_FILENO+1; i rl.rlim_cur; i++)
close(i);
If the stdin for the menu process isn't a tty, the inherited stdin for
xterm still won't be a tty. Some stty settings can be set for non-tty's,
and some cannot. Usually the differences between xterm and rxvt in this
area are related to whether there is a real /dev/tty associated with the
process.
/* Disassociate any TTYs */
setsid();
The intent here is to prevent signals from propagating into the
subprocess.
execl (/bin/sh,
/bin/sh,
-c,
m-menuItem[j].param,
NULL);
exit (0);
}
I'm looking into it a little bit, but I think that others could shed
some light on this.
Harold
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Re: MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
Thomas Dickey wrote:
On Wed, 25 Feb 2004, Harold L Hunt II wrote:
This issue has to have something to do with the way that commands are
launched from the .XWinrc menu, since launching an xterm from another
xterm works just fine. Here is the code that launches commands
specified in the .XWinrc menus:
case CMD_EXEC:
if (fork()==0)
{
struct rlimit rl;
unsigned long i;
/* Close any open descriptors except for STD* */
getrlimit (RLIMIT_NOFILE, rl);
for (i = STDERR_FILENO+1; i rl.rlim_cur; i++)
close(i);
If the stdin for the menu process isn't a tty, the inherited stdin for
xterm still won't be a tty. Some stty settings can be set for non-tty's,
and some cannot. Usually the differences between xterm and rxvt in this
area are related to whether there is a real /dev/tty associated with the
process.
Sounds like we need to peek at rxvt to get some pointers on how to do
this... or is it your impression that it is not really possible?
/* Disassociate any TTYs */
setsid();
The intent here is to prevent signals from propagating into the
subprocess.
Okay.
Harold
Re: MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
On Wed, 25 Feb 2004, Harold L Hunt II wrote: If the stdin for the menu process isn't a tty, the inherited stdin for xterm still won't be a tty. Some stty settings can be set for non-tty's, and some cannot. Usually the differences between xterm and rxvt in this area are related to whether there is a real /dev/tty associated with the process. Sounds like we need to peek at rxvt to get some pointers on how to do this... or is it your impression that it is not really possible? It might not be possible - xterm is doing some features that rxvt doesn't, and making some checks that rxvt doesn't. It's worth comparing to see where the problem is, though - might be a feature whose failure can be worked around. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
No titlebar with -multiwindow mode?
Hi list,
Is it possible to open an x-client without title bar, when using
Cygwin/XFree86 with -multiwindow mode?
When I use -rootless mode with twm, I have 'NoTitle { xclock }' in
my .twmrc and xclock works silently in its corner of screen.
But with -multiwindow mode, xclock gets its title bar which seems
just kind of annoying. :-P
I know this is wish-list kind of thingy, but if it works then
would be great. ;-)
Thanks in advance,
Haro
=---
_ _Munehiro (haro) Matsuda
-|- /_\ |_|_| Kubota Graphics Technology Inc.
/|\ |_| |_|_| 2-8-8 Shinjuku, Shinjuku-ku Tokyo 160-0022, Japan
Tel: +81-3-3225-0767 Fax: +81-3-3225-0740
Email: [EMAIL PROTECTED]
Re: window decoration for multiwindow mode
On Sunday 04 January 2004 01:10, Kensuke Matsuzaki wrote: Hi, A new window manager XWinWM handles Motif WM Hint and Blackbox hint, and kicker has no border. XWinWM is based on Hackedbox, and Hackedbox doesn't use _NET_WM_WINDOW_TYPE atom. I have to supprot EWMH, but XWinWM has preblem on more basically window management (Move, resize, iconify etc). So now EWMH compliance's priority is not high for me. Test version is here. http://peppermint.jp/products/x/xwinwm-0.0.1.tar.gz Thanks for this info. Can't say, when I can take a look at this, but I will see probably after the kde 3.1.4 release.
window decoration for multiwindow mode
Hi, i just saw the xfree development page and recognized a missing feature in the multi window mode, which is is at least interesting for kde, but I assume also for other x applications. Currently the server does not handle modal dialogs like expected (currently modal dialogs are independed windows) and does not support windows without regular windows title border. (This could be verifyed for example with kicker, the KDE panel, which is bordered with a regular window title, while it is shown without any additional border as expected using an X-window manager like kwin. The relating standards for this topic could be found at http://www.freedesktop.org/standards/wm-spec/1.3/ar01s05.html _NET_WM_WINDOW_TYPE, ATOM[]/32 This SHOULD be set by the Client before mapping to a list of atoms indicating the functional type of the window. This property SHOULD be used by the window manager in determining the decoration, stacking position and other behavior of the window. The Client SHOULD specify window types in order of preference (the first being most preferable) but MUST include at least one of the basic window type atoms from the list below. This is to allow for extension of the list of types whilst providing default behavior for Window Managers that do not recognize the extensions. Rationale: This hint is intended to replace the MOTIF hints. One of the objections to the MOTIF hints is that they are a purely visual description of the window decoration. By describing the function of the window, the Window Manager can apply consistent decoration and behavior to windows of the same type. Possible examples of behavior include keeping dock/panels on top or allowing pinnable menus / toolbars to only be hidden when another window has focus (NextStep style). _NET_WM_WINDOW_TYPE_DESKTOP, ATOM _NET_WM_WINDOW_TYPE_DOCK, ATOM _NET_WM_WINDOW_TYPE_TOOLBAR, ATOM _NET_WM_WINDOW_TYPE_MENU, ATOM _NET_WM_WINDOW_TYPE_UTILITY, ATOM _NET_WM_WINDOW_TYPE_SPLASH, ATOM _NET_WM_WINDOW_TYPE_DIALOG, ATOM _NET_WM_WINDOW_TYPE_NORMAL, ATOM _NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a single window containing desktop icons with the same dimensions as the screen, allowing the desktop environment to have full control of the desktop, without the need for proxying root window clicks. _NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a Window Manager would keep such windows on top of all other windows. _NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and pinnable menu windows, respectively (i.e. toolbars and menus torn off from the main application). Windows of this type may set the WM_TRANSIENT_FOR hint indicating the main application window. _NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as a palette or toolbox. It is distinct from type TOOLBAR because it does not correspond to a toolbar torn off from the main application. It's distinct from type DIALOG because it isn't a transient dialog, the user will probably keep it open while they're working. Windows of this type may set the WM_TRANSIENT_FOR hint indicating the main application window. _NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen displayed as an application is starting up. _NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If _NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST be taken as this type. _NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window. Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST be taken as this type.
Re: window decoration for multiwindow mode
Ralf, I believe Kensuke's new window manager for multi-window mode does this (the one that works with miext/rootless). The code is not yet completely checked in, but check the archives for messages he has posted pointing to some test versions. You can check out the code for the server from our xorg repository on freedesktop.org, but the xwinwm code is on Kensuke's personal site until I get it checked into the xclients repository. I believe he may find this reference information useful, though. I know that he based it off of another window manager, so he should be handling most of the ICCCM specs for window decoration, etc. Harold Ralf Habacker wrote: Hi, i just saw the xfree development page and recognized a missing feature in the multi window mode, which is is at least interesting for kde, but I assume also for other x applications. Currently the server does not handle modal dialogs like expected (currently modal dialogs are independed windows) and does not support windows without regular windows title border. (This could be verifyed for example with kicker, the KDE panel, which is bordered with a regular window title, while it is shown without any additional border as expected using an X-window manager like kwin. The relating standards for this topic could be found at http://www.freedesktop.org/standards/wm-spec/1.3/ar01s05.html _NET_WM_WINDOW_TYPE, ATOM[]/32 This SHOULD be set by the Client before mapping to a list of atoms indicating the functional type of the window. This property SHOULD be used by the window manager in determining the decoration, stacking position and other behavior of the window. The Client SHOULD specify window types in order of preference (the first being most preferable) but MUST include at least one of the basic window type atoms from the list below. This is to allow for extension of the list of types whilst providing default behavior for Window Managers that do not recognize the extensions. Rationale: This hint is intended to replace the MOTIF hints. One of the objections to the MOTIF hints is that they are a purely visual description of the window decoration. By describing the function of the window, the Window Manager can apply consistent decoration and behavior to windows of the same type. Possible examples of behavior include keeping dock/panels on top or allowing pinnable menus / toolbars to only be hidden when another window has focus (NextStep style). _NET_WM_WINDOW_TYPE_DESKTOP, ATOM _NET_WM_WINDOW_TYPE_DOCK, ATOM _NET_WM_WINDOW_TYPE_TOOLBAR, ATOM _NET_WM_WINDOW_TYPE_MENU, ATOM _NET_WM_WINDOW_TYPE_UTILITY, ATOM _NET_WM_WINDOW_TYPE_SPLASH, ATOM _NET_WM_WINDOW_TYPE_DIALOG, ATOM _NET_WM_WINDOW_TYPE_NORMAL, ATOM _NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a single window containing desktop icons with the same dimensions as the screen, allowing the desktop environment to have full control of the desktop, without the need for proxying root window clicks. _NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a Window Manager would keep such windows on top of all other windows. _NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and pinnable menu windows, respectively (i.e. toolbars and menus torn off from the main application). Windows of this type may set the WM_TRANSIENT_FOR hint indicating the main application window. _NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as a palette or toolbox. It is distinct from type TOOLBAR because it does not correspond to a toolbar torn off from the main application. It's distinct from type DIALOG because it isn't a transient dialog, the user will probably keep it open while they're working. Windows of this type may set the WM_TRANSIENT_FOR hint indicating the main application window. _NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen displayed as an application is starting up. _NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If _NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST be taken as this type. _NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window. Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST be taken as this type.
Re: window decoration for multiwindow mode
Hi, A new window manager XWinWM handles Motif WM Hint and Blackbox hint, and kicker has no border. XWinWM is based on Hackedbox, and Hackedbox doesn't use _NET_WM_WINDOW_TYPE atom. I have to supprot EWMH, but XWinWM has preblem on more basically window management (Move, resize, iconify etc). So now EWMH compliance's priority is not high for me. Test version is here. http://peppermint.jp/products/x/xwinwm-0.0.1.tar.gz -- Kensuke Matsuzaki mailto:[EMAIL PROTECTED] http://peppermint.jp
Re: -multiwindow mode, clipboard primary selection window icon
Emss == Eric Masson [EMAIL PROTECTED] writes: Emss I've attached log for normal behaviour and will send a folloup Emss asa the case reappears. Done, the only difference is that the laptop is now connected to mains plug. Regards Eric Masson -- Le neuneu est à Usenet ce que le staphylocoque doré est au furoncle. Ils bénéficient tous les deux d'un système cognitif de niveau équivalent, malgré un léger avantage intellectuel au staphylocoque. -+- JdC in http://www.le-gnu.net : No Fu(tur)oncle -+- Xwin.log.Xicon Description: Binary data
-multiwindow mode, clipboard primary selection window icon
Hello, Setup : Windows 2000 SP4 XFree86 4.3.0-13 I'm facing the following problem when displaying a remote app on my laptop. When I launch XEmacs, the window upper left icon is sometimes set to XEmacs one but most of the times to the default X one. When the icon is set to XEmacs, I can't select text with mouse or keyboard (pc-select), it's automatically unselected. When the icon is set to X, text selection works fine. Has anyone seen a similar case, is there any known solution ? Eric Masson PS: xprops for each case are attached. -- Le truc c'est qu'avec MacOS l'utilisateur neuneu pouvait aussi etre administrateur neuneu, et que ca, ca sera bien fini. -+ ED in Guide du Macounet Pervers : il voit des neuneus partout -+- xemacs.XEmacs.xprop Description: Binary data xemacs.X.xprop Description: Binary data
Re: -multiwindow mode, clipboard primary selection window icon
Eric, Eric Masson wrote: Hello, Setup : Windows 2000 SP4 XFree86 4.3.0-13 I'm facing the following problem when displaying a remote app on my laptop. When I launch XEmacs, the window upper left icon is sometimes set to XEmacs one but most of the times to the default X one. Sounds to me like most of the time the MultiWindow window manager (-multiwindow) and the integrated clipboard manager (-clipboard) are failing to startup. This causes the icons to be left as the default icon, and it means that the clipboard integration between X and Windows is not present. When the icon is set to XEmacs, I can't select text with mouse or keyboard (pc-select), it's automatically unselected. In this case the clipboard integration manager and MultiWindow window manager *are* working and the behavior you are seeing with the selection becoming unselected is by design. Changing that design has been on the To-Do list for some time, but it will take roughly 40 hours to finish the work that was started on it. When the icon is set to X, text selection works fine. You need to look at /tmp/XWin.log in both of these cases. Better yet, send in the contents of /tmp/XWin.log for each instance. This will help us figure out why the window manager and clipboard integration manager are failing to startup. Also, please send in the command-line parameters that you are passing to XWin.exe. Harold
Re: -multiwindow mode, clipboard primary selection window icon
Harold == Harold L Hunt, Harold writes: Hello Harold, Harold Sounds to me like most of the time the MultiWindow window Harold manager (-multiwindow) and the integrated clipboard manager Harold (-clipboard) are failing to startup. This causes the icons to Harold be left as the default icon, and it means that the clipboard Harold integration between X and Windows is not present. Ok, but Mozilla from the same host _always_ sets the upper left icon correctly. Harold In this case the clipboard integration manager and MultiWindow Harold window manager *are* working and the behavior you are seeing Harold with the selection becoming unselected is by design. Changing Harold that design has been on the To-Do list for some time, but it Harold will take roughly 40 hours to finish the work that was started Harold on it. Ok Harold You need to look at /tmp/XWin.log in both of these cases. Harold Better yet, send in the contents of /tmp/XWin.log for each Harold instance. This will help us figure out why the window manager Harold and clipboard integration manager are failing to startup. At the moment, Murphy is here and I can't reproduce the case with default X icon :/ I've attached log for normal behaviour and will send a folloup asa the case reappears. Harold Also, please send in the command-line parameters that you are Harold passing to XWin.exe. XWin -multiwindow -clipboard Eric Masson -- BC je ne fais rire que les dinos Mais vous faites gerber tous les autres. -+-AC in http://www.le-gnu.net : Dépôt de gerbe -+- Xwin.log.XEmacs Description: Binary data
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
I found your thread on the Multiwindow/xwinclip problem with Mozilla, etc. (running on Solaris, displaying on Cygwin XFree86 on Win200). Thanks for the tip. Removing the -clipboard option stopped my crashes (I was crashing while running netscape -edit, or the Mozilla/Firebird equivalent). I also found the same crashes if I ran the standalone xwinclip application. Don't know what caused it, but I can live with the clipboard (can't live with multiwindow support!). Thanks, Jim
PATCH: Constrained sizing support in -multiwindow mode
The multiwindow manager does presently not respect the hints that apps like xterm or emacs give as to valid window sizes. This can cause xterm to have ugly leftover smudges on the right edge of the window and other minor little annoyances. The attached DIFF -U3 patch against test93 adds support to automatically validate the sizes of windows while you're sizing them, just like you find in most X11 window managers. I've tested it locally and it seems to work just fine under W2K, but I'd like to confirm that it performs properly under XP where the window decorations (which it needs to take into account) are different... -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com constrainsize.diff.bz2 Description: BZip2 compressed data
Re: PATCH: Constrained sizing support in -multiwindow mode
Earle, This is great! Just yesterday, while investigating the crashing upon copying a large amount of text, I was resizing xterm to make it really large and noticed that the window quite often got a size that chopped off the last line of text or left a gap after the last line of text. I wondered if it had something to do with hints... sure enough, it did :) Thanks for the patch, Harold Earle F. Philhower, III wrote: The multiwindow manager does presently not respect the hints that apps like xterm or emacs give as to valid window sizes. This can cause xterm to have ugly leftover smudges on the right edge of the window and other minor little annoyances. The attached DIFF -U3 patch against test93 adds support to automatically validate the sizes of windows while you're sizing them, just like you find in most X11 window managers. I've tested it locally and it seems to work just fine under W2K, but I'd like to confirm that it performs properly under XP where the window decorations (which it needs to take into account) are different...
lyx memory access error in multiwindow mode on laptop not on desktop.
Hello, Adding some info to the memory access error in mulitwindow mode. I am not a programmer so I am not sure how to diagnose the error. I installed latest xfree server and got the document processorer LyX up and running in multiwindows mode on my desktop (both multiwindow and regular mode under wmaker), but LyX keeps on crashing at start-up on my laptop, while it runs without problem in the regular non-mulitwindow mode under wmaker. AFAIK the desktop and the lap-top has the same installation of cygwin. ( I updated both lap-top and desktop this week). I also installed the latest test series 91 of the xserver but LyX keeps crashing in multiwindow mode on the lap-top. ( I have not installed the test series on the desktop). Thank for very good software (, which helps me produce my Ph.D thesis.) jorgen
Re: Generic rootless/multiwindow mode in XFree86 CVS
Harold L Hunt II wrote: Is this in the latest XF86 tarballs available from their development server? I haven't had time recently to do code hacking, but with any luck that'll change soon. I think the tarballs tend to be out of date. There are two sorts of tarballs. The regular releases and snapshots. The last regular release was 4.3.0 and is about 3 months old. The snapshots are much newer. But getting the xfree source from cvs is the recommended way. Unfortunately the rootless code was added after the 4.3.0 release, so we still don't have it in the xoncygwin repository. bye ago NP: Placebo - Burger queen -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Generic rootless/multiwindow mode in XFree86 CVS [Fwd: Re: CVS Update:xc (branch: trunk)]
Torrey Lyons, the maintainer of XDarwin, has created a generic rootless/multiwindow implementation that is intended to be a framework used by any implementation of X on top of another windowing system. The Cocoa code for XDarwin was recently converted to use this toolkit. It would be a very good idea to try to reimplement rootless/multiwindow mode using their toolkit, or at least to add a new mode that uses the toolkit. Probably the nicest feature of the toolkit is that it tells the fb layer that each window has its own framebuffer (which they do) so that expose events on windows do not result in the data being sent across the network again or re-rendered. This would really improve the performance of rootless/multiwindow mode when working with several maximized X apps. Note that their rootless is more like our multiwindow mode; that is, each X window is mapped to a Win32 window. Thus, the rootless toolkit really applies to our multiwindow mode. Thoughts, comments? Anyone interested in working on this? Harold Original Message Subject: Re: CVS Update: xc (branch: trunk) Date: Fri, 6 Jun 2003 23:18:30 -0700 From: Torrey T. Lyons [EMAIL PROTECTED] To: Harold L Hunt II [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] At 1:57 AM -0400 6/7/03, Harold L Hunt II wrote: Torrey, Log message: Rework XDarwin's Cocoa rootless implementation to use the new generic rootless code in miext/rootless. Have you written a brief email or document/webpage describing this mode? I know that you notified me of its existence before, but I was wondering if you have written an interface defintion and some of the aims or goals somewhere for me to look at. That was a fast question. :-) I haven't written up any documentation yet, although I have been meaning to. The basic idea is that any implementation that uses the generic rootless code has to provide the rootless implementation functions listed in rootless.h. (The comments in rootless.h are complete at least.) The generic rootless code takes care of the rest. I might be interested in this code... but I am not sure if rootless means the same thing in our two projects. In Cygwin/XFree86 we have a rootless mode that clips the root window out so it is essentially transparent. You can click through it to access other applications on your desktop... all X applications are essentially in one position in the Z order. We also have a MultiWindow mode that works in conjunction with an integrated window manager to create a Win32 window per each X window and handle raising/lowering/etc. for those windows. Do we have the same definition of rootless, or is miext/rootless more of a toolkit for our MultiWindow mode? I am guessing, without looking, that the miext/rootless code helps keep track of the clip list for the root window, which is used to essentially make the root window transparent, right? If not, what is its purpose? I don't know about the MultiWindow mode, but this code is a lot more then just clipping out a transparent root. The generic rootless code solves the following general problem: You want to implement an X server on top of another (capable) window server. The other window server already provides backing store for all your on screen windows. (This is the main assumption of the code.) In this case, you want to map each top-level X window to a window of your underlying window server (CoreGraphics in our case). The windows of the underlying window server are called frames to avoid confusion over the word window meaning too many things. You also want to stop all requests to draw to the root window. The generic rootless code takes care of this and all other details for you. Another way to think of it is that the standard X server view of the hardware is as a framebuffer. The generic rootless code instead converts this to viewing the hardware as a bunch of separate windows that don't damage each other. This lets you take full advantage of features of your underlying window system. For example, you can save memory because you don't need to keep a copy of the framebuffer in memory. You can instead just draw directly into the backing store provided by the underlying window server. You can also do things like window moves much more quickly by just telling the underlying window server to move this frame rather then re-rendering everything to the framebuffer with the X window in the new position and copying it all back onto the screen. I hope my explanation makes some sense. As I said, I plan to write more docs later, so let me know if you have any questions so I'll address them. If MS Windows provides backing store for its on screen windows, you will probably find the generic rootless code allows you to provide a lot of slick features very easily. If you look at Xserver/hw/darwin/quartz/cr you can see how small a typical implementation can be. --Torrey
Re: Generic rootless/multiwindow mode in XFree86 CVS [Fwd: Re: CVS Update: xc (branch: trunk)]
Howdy Harold, At 04:55 PM 6/8/2003 -0400, you wrote: Torrey Lyons, the maintainer of XDarwin, has created a generic rootless/multiwindow implementation that is intended to be a framework used by any implementation of X on top of another windowing system. The Cocoa code for XDarwin was recently converted to use this toolkit. It would be a very good idea to try to reimplement rootless/multiwindow mode using their toolkit, or at least to add a new mode that uses the toolkit. Probably the nicest feature of the toolkit is that it tells the fb layer that each window has its own framebuffer (which they do) so that expose events on windows do not result in the data being sent across the network again or re-rendered. This would really improve the performance of rootless/multiwindow mode when working with several maximized X apps. Note that their rootless is more like our multiwindow mode; that is, each X window is mapped to a Win32 window. Thus, the rootless toolkit really applies to our multiwindow mode. Thoughts, comments? Anyone interested in working on this? That's an interesting idea, but does that mode support sending the expose events back to the X apps? If not, you'll be just as performance constrained as now since you'll have to draw offscreen and do bit-blits to the active window. Windoze can and does destroy your window contents as it chooses AFAIK, if your window gets hidden, if the display mode/size changes, etc. Another neat (silly) idea would be to render the X windows as 3D textures completely in the video card. No bitblit needed, the 256-bit wide gfx engine will take care of slapping it to screen as fast as you like! That's what newer revs of the Windows UI will be doing if they keep their plans. OS X probably already has something like this. Is this in the latest XF86 tarballs available from their development server? I haven't had time recently to do code hacking, but with any luck that'll change soon. Harold Original Message Subject: Re: CVS Update: xc (branch: trunk) Date: Fri, 6 Jun 2003 23:18:30 -0700 From: Torrey T. Lyons [EMAIL PROTECTED] To: Harold L Hunt II [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] At 1:57 AM -0400 6/7/03, Harold L Hunt II wrote: Torrey, Log message: Rework XDarwin's Cocoa rootless implementation to use the new generic rootless code in miext/rootless. Have you written a brief email or document/webpage describing this mode? I know that you notified me of its existence before, but I was wondering if you have written an interface defintion and some of the aims or goals somewhere for me to look at. That was a fast question. :-) I haven't written up any documentation yet, although I have been meaning to. The basic idea is that any implementation that uses the generic rootless code has to provide the rootless implementation functions listed in rootless.h. (The comments in rootless.h are complete at least.) The generic rootless code takes care of the rest. I might be interested in this code... but I am not sure if rootless means the same thing in our two projects. In Cygwin/XFree86 we have a rootless mode that clips the root window out so it is essentially transparent. You can click through it to access other applications on your desktop... all X applications are essentially in one position in the Z order. We also have a MultiWindow mode that works in conjunction with an integrated window manager to create a Win32 window per each X window and handle raising/lowering/etc. for those windows. Do we have the same definition of rootless, or is miext/rootless more of a toolkit for our MultiWindow mode? I am guessing, without looking, that the miext/rootless code helps keep track of the clip list for the root window, which is used to essentially make the root window transparent, right? If not, what is its purpose? I don't know about the MultiWindow mode, but this code is a lot more then just clipping out a transparent root. The generic rootless code solves the following general problem: You want to implement an X server on top of another (capable) window server. The other window server already provides backing store for all your on screen windows. (This is the main assumption of the code.) In this case, you want to map each top-level X window to a window of your underlying window server (CoreGraphics in our case). The windows of the underlying window server are called frames to avoid confusion over the word window meaning too many things. You also want to stop all requests to draw to the root window. The generic rootless code takes care of this and all other details for you. Another way to think of it is that the standard X server view of the hardware is as a framebuffer. The generic rootless code instead converts this to viewing the hardware as a bunch of separate windows that don't damage each other. This lets you take full advantage of features of your underlying window system. For example
Re: Generic rootless/multiwindow mode in XFree86 CVS [Fwd: Re: CVSUpdate: xc (branch: trunk)]
Earle, Earle F. Philhower III wrote: Howdy Harold, At 04:55 PM 6/8/2003 -0400, you wrote: Torrey Lyons, the maintainer of XDarwin, has created a generic rootless/multiwindow implementation that is intended to be a framework used by any implementation of X on top of another windowing system. The Cocoa code for XDarwin was recently converted to use this toolkit. It would be a very good idea to try to reimplement rootless/multiwindow mode using their toolkit, or at least to add a new mode that uses the toolkit. Probably the nicest feature of the toolkit is that it tells the fb layer that each window has its own framebuffer (which they do) so that expose events on windows do not result in the data being sent across the network again or re-rendered. This would really improve the performance of rootless/multiwindow mode when working with several maximized X apps. Note that their rootless is more like our multiwindow mode; that is, each X window is mapped to a Win32 window. Thus, the rootless toolkit really applies to our multiwindow mode. Thoughts, comments? Anyone interested in working on this? That's an interesting idea, but does that mode support sending the expose events back to the X apps? If not, you'll be just as performance constrained as now since you'll have to draw offscreen and do bit-blits to the active window. Windoze can and does destroy your window contents as it chooses AFAIK, if your window gets hidden, if the display mode/size changes, etc. Actually, now that you mention it, I have a feeling that they are masking expose events when they can be handled by simply retransferring the data from the buffer for the window. The main difference between this system and our current system is that each window has an offscreen bitmap rather than a single offscreen bitmap for the entire screen. It is basically a double-buffering system. We could, of course, implement such a system without using the generic toolkit, but it would probably be easier to use the toolkit. Or, it would at least get us some of the benefits of improvements to the shared code. Another neat (silly) idea would be to render the X windows as 3D textures completely in the video card. No bitblit needed, the 256-bit wide gfx engine will take care of slapping it to screen as fast as you like! That's what newer revs of the Windows UI will be doing if they keep their plans. OS X probably already has something like this. We have been working on making a Native GDI engine that translates X graphics calls to GDI graphics calls. The nice thing about GDI graphics calls is that almost all of them are accelerated by graphics drivers... so a 200,000 pixel circle fill will take a couple clocks rather than the number of clocks required to transfer roughly 600,000 bytes to the graphics card. Is this in the latest XF86 tarballs available from their development server? I haven't had time recently to do code hacking, but with any luck that'll change soon. I think the tarballs tend to be out of date. The XFree86 CVS system is open to the public now (just not for public commits). I typically look at the code through cvsweb first if I just want to see what it does and how clean it is: http://cvsweb.xfree86.org/cvsweb/ Does that help? Harold Original Message Subject: Re: CVS Update: xc (branch: trunk) Date: Fri, 6 Jun 2003 23:18:30 -0700 From: Torrey T. Lyons [EMAIL PROTECTED] To: Harold L Hunt II [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] At 1:57 AM -0400 6/7/03, Harold L Hunt II wrote: Torrey, Log message: Rework XDarwin's Cocoa rootless implementation to use the new generic rootless code in miext/rootless. Have you written a brief email or document/webpage describing this mode? I know that you notified me of its existence before, but I was wondering if you have written an interface defintion and some of the aims or goals somewhere for me to look at. That was a fast question. :-) I haven't written up any documentation yet, although I have been meaning to. The basic idea is that any implementation that uses the generic rootless code has to provide the rootless implementation functions listed in rootless.h. (The comments in rootless.h are complete at least.) The generic rootless code takes care of the rest. I might be interested in this code... but I am not sure if rootless means the same thing in our two projects. In Cygwin/XFree86 we have a rootless mode that clips the root window out so it is essentially transparent. You can click through it to access other applications on your desktop... all X applications are essentially in one position in the Z order. We also have a MultiWindow mode that works in conjunction with an integrated window manager to create a Win32 window per each X window and handle raising/lowering/etc. for those windows. Do we have the same definition of rootless, or is miext/rootless more of a toolkit for our
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold, Harold L Hunt II [EMAIL PROTECTED] writes: There is a temporary release of XWin.exe available that watches our for more NULL pointer dereferences. Please try it out and report your results: That's the way I like it, JIT-fixes ;-) I had started to get crashes with the new Emacs I built today, when I was browsing through the menus. I think all the new tooltips that Emacs has in this version were the problem. The debug XWin.exe seems to fix that. so long, benny
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Benny, Okay, I will release this debug version as soon as I get a chance. Thanks for testing, Harold Benjamin Riefenstahl wrote: Hi Harold, Harold L Hunt II [EMAIL PROTECTED] writes: There is a temporary release of XWin.exe available that watches our for more NULL pointer dereferences. Please try it out and report your results: That's the way I like it, JIT-fixes ;-) I had started to get crashes with the new Emacs I built today, when I was browsing through the menus. I think all the new tooltips that Emacs has in this version were the problem. The debug XWin.exe seems to fix that. so long, benny
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold, Harold L Hunt II [EMAIL PROTECTED] writes: Okay, I will release this debug version as soon as I get a chance. Cool. BTW, I forgot to mention that the icons are *much* better now, that bit also works. so long, benny
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Rob,
Please update to XFree86-xserv-4.2.0-42.
I forget... did I already ask you to try this without using -clipboard
(you are using -clipboard, right)? If not, please try this without
using -clipboard and report your results.
Harold
Robert Pang wrote:
Hi John
This is what I see in /tmp/XWin.log from 2 consecutive tries.
GetWindowName - XA_STRING Mozilla {Build ID: 2003052723}
GetWindowName
GetWindowName - XA_STRING Getting Involved with mozilla.org - Mozilla {Build
ID: 2003052723}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
GetWindowName
GetWindowName - XA_STRING mozilla-bin
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Mon, 02 Jun 2003 21:40:56 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
I haven't got any ideas. Check /tmp/XWin.log before and after mozilla
crashes. Report any new lines that show up during this period.
Harold
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 02, 2003 6:24 PM
Subject: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi developers,
I am running XFree 86 for Cygwin (4.2.0 - 37) on Windows 2000. I am having
problem with Mozilla 1.4 beta running on Sparc Solaris 2.6 and displayed
in
my XFree 86 running in multi-window mode. Mozilla starts fine. However,
whenever I click in the address bar to enter a new URL, Mozilla aborts
with
the following error when I click in the address bar.
mozilla ./mozilla
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 17 (X_GetAtomName)
Atom id in failed request: 0xc000
Serial number of failed request: 2467
Current serial number in output stream: 2467
Mozilla running from Linux/x86 doesn't show the same problem and works
perfectly. Any clue what's wrong with Mozilla on Sparc Solaris?
Thanks.
Rob
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold
I update to XFree86-xserv-4.2.0-42 and mozilla still crashes when I click on
the address bar. But it doesn't crash if I do not use -clipboard. So, is
-clipboard the problem? How come I don't have a problem with -clipboard
if mozilla is run from Linux instead?
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Tue, 03 Jun 2003 13:32:43 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
Rob,
Please update to XFree86-xserv-4.2.0-42.
I forget... did I already ask you to try this without using -clipboard (you
are using -clipboard, right)? If not, please try this without
using -clipboard and report your results.
Harold
Robert Pang wrote:
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: Robert Pang [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 10:09 AM
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold
This is what I see in /tmp/XWin.log from 2 consecutive tries.
GetWindowName - XA_STRING Mozilla {Build ID: 2003052723}
GetWindowName
GetWindowName - XA_STRING Getting Involved with mozilla.org - Mozilla
{Build
ID: 2003052723}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
GetWindowName
GetWindowName - XA_STRING mozilla-bin
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Mon, 02 Jun 2003 21:40:56 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
I haven't got any ideas. Check /tmp/XWin.log before and after mozilla
crashes. Report any new lines that show up during this period.
Harold
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 02, 2003 6:24 PM
Subject: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi developers,
I am running XFree 86 for Cygwin (4.2.0 - 37) on Windows 2000. I am
having
problem with Mozilla 1.4 beta running on Sparc Solaris 2.6 and displayed
in
my XFree 86 running in multi-window mode. Mozilla starts fine. However,
whenever I click in the address bar to enter a new URL, Mozilla aborts
with
the following error when I click in the address bar.
mozilla ./mozilla
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 17 (X_GetAtomName)
Atom id in failed request: 0xc000
Serial number of failed request: 2467
Current serial number in output stream: 2467
Mozilla running from Linux/x86 doesn't show the same problem and works
perfectly. Any clue what's wrong with Mozilla on Sparc Solaris?
Thanks.
Rob
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Harold
BTW, I don't have the crash when -clipboard is in use when I do not use
multiwindow mode.
Rob
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 1:14 PM
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold
I update to XFree86-xserv-4.2.0-42 and mozilla still crashes when I click
on
the address bar. But it doesn't crash if I do not use -clipboard. So, is
-clipboard the problem? How come I don't have a problem with
-clipboard
if mozilla is run from Linux instead?
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Tue, 03 Jun 2003 13:32:43 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
Rob,
Please update to XFree86-xserv-4.2.0-42.
I forget... did I already ask you to try this without using -clipboard
(you
are using -clipboard, right)? If not, please try this without
using -clipboard and report your results.
Harold
Robert Pang wrote:
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: Robert Pang [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 10:09 AM
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold
This is what I see in /tmp/XWin.log from 2 consecutive tries.
GetWindowName - XA_STRING Mozilla {Build ID: 2003052723}
GetWindowName
GetWindowName - XA_STRING Getting Involved with mozilla.org - Mozilla
{Build
ID: 2003052723}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
GetWindowName
GetWindowName - XA_STRING mozilla-bin
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Mon, 02 Jun 2003 21:40:56 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
I haven't got any ideas. Check /tmp/XWin.log before and after mozilla
crashes. Report any new lines that show up during this period.
Harold
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 02, 2003 6:24 PM
Subject: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi developers,
I am running XFree 86 for Cygwin (4.2.0 - 37) on Windows 2000. I am
having
problem with Mozilla 1.4 beta running on Sparc Solaris 2.6 and
displayed
in
my XFree 86 running in multi-window mode. Mozilla starts fine.
However,
whenever I click in the address bar to enter a new URL, Mozilla aborts
with
the following error when I click in the address bar.
mozilla ./mozilla
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 17 (X_GetAtomName)
Atom id in failed request: 0xc000
Serial number of failed request: 2467
Current serial number in output stream: 2467
Mozilla running from Linux/x86 doesn't show the same problem and works
perfectly. Any clue what's wrong with Mozilla on Sparc Solaris?
Thanks.
Rob
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Rob,
Welcome to the world of threads. The clipboard manager and window
manager run in their own threads within the X Server process... there is
likely to be a bug in one of those modules or in the supporting modules.
I have no idea which module actually contains the bug at this point.
How prepared are you to help with debugging? I mean, you are in the CS
department at Stanford, so I would expect that you can help us quite a
bit, no? :)
Harold
Robert Pang wrote:
Hi Harold
I update to XFree86-xserv-4.2.0-42 and mozilla still crashes when I click on
the address bar. But it doesn't crash if I do not use -clipboard. So, is
-clipboard the problem? How come I don't have a problem with -clipboard
if mozilla is run from Linux instead?
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Tue, 03 Jun 2003 13:32:43 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
Rob,
Please update to XFree86-xserv-4.2.0-42.
I forget... did I already ask you to try this without using -clipboard (you
are using -clipboard, right)? If not, please try this without
using -clipboard and report your results.
Harold
Robert Pang wrote:
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: Robert Pang [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 10:09 AM
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold
This is what I see in /tmp/XWin.log from 2 consecutive tries.
GetWindowName - XA_STRING Mozilla {Build ID: 2003052723}
GetWindowName
GetWindowName - XA_STRING Getting Involved with mozilla.org - Mozilla
{Build
ID: 2003052723}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
winClipboardErrorHandler - ERROR:
BadWindow (invalid Window parameter)
GetWindowName
GetWindowName - XA_STRING Mozilla {Build ID: 2003051323}
GetWindowName
GetWindowName - XA_STRING Robert Pang's Web Top - Mozilla {Build ID:
2003051323}
GetWindowName
GetWindowName - XA_STRING mozilla-bin
Thanks.
Rob
- Original Message -
From: Harold L Hunt II huntharo at msu dot edu
To: cygwin-xfree at cygwin dot com
Date: Mon, 02 Jun 2003 21:40:56 -0400
Subject: Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
References: [EMAIL PROTECTED]
Reply-to: cygwin-xfree at cygwin dot com
I haven't got any ideas. Check /tmp/XWin.log before and after mozilla
crashes. Report any new lines that show up during this period.
Harold
- Original Message -
From: Robert Pang [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 02, 2003 6:24 PM
Subject: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi developers,
I am running XFree 86 for Cygwin (4.2.0 - 37) on Windows 2000. I am
having
problem with Mozilla 1.4 beta running on Sparc Solaris 2.6 and displayed
in
my XFree 86 running in multi-window mode. Mozilla starts fine. However,
whenever I click in the address bar to enter a new URL, Mozilla aborts
with
the following error when I click in the address bar.
mozilla ./mozilla
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 17 (X_GetAtomName)
Atom id in failed request: 0xc000
Serial number of failed request: 2467
Current serial number in output stream: 2467
Mozilla running from Linux/x86 doesn't show the same problem and works
perfectly. Any clue what's wrong with Mozilla on Sparc Solaris?
Thanks.
Rob
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Rob, There is a temporary release of XWin.exe available that watches our for more NULL pointer dereferences. Please try it out and report your results: http://www.msu.edu/~huntharo/xwin/shadow/XWin-Test91-DEBUG.exe.bz2 There are instructions for installing such a binary at: http://xfree86.cygwin.com/devel/shadow/ Thanks for testing, Harold
Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi developers, I am running XFree 86 for Cygwin (4.2.0 - 37) on Windows 2000. I am having problem with Mozilla 1.4 beta running on Sparc Solaris 2.6 and displayed in my XFree 86 running in multi-window mode. Mozilla starts fine. However, whenever I click in the address bar to enter a new URL, Mozilla aborts with the following error when I click in the address bar. mozilla ./mozilla X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0xc000 Serial number of failed request: 2467 Current serial number in output stream: 2467 Mozilla running from Linux/x86 doesn't show the same problem and works perfectly. Any clue what's wrong with Mozilla on Sparc Solaris? Thanks. Rob
