How to kill XWin from a script
This might be well-known, in which case sorry for wasting your time.
It can be inconvenient to have one or several copies of XWin remaining after
exiting Cygwin.
You can do "kill PID" but for this you need to know what the PID is and then
type the command explicitly.
A command (or script) which will kill them all stone dead without previous
reference to ps is
kill `ps | grep XWin | awk '{print $1}'`
Put it in .bash_logout? Or wherever suits.
Fergus
Suggestions for speed
Hi all, I'd like to solicit some suggestions for making my remote KDE session faster. I currently connect to a machine running Debian stable (woody) with SSH and X11 Port Forwarding. I'm connecting across an 802.11b wireless network, which is limited to 11Mbps. I see from some previous posts that it appears I might do better with a 54 (or 108) Mbps network connection--that's definitely something to try. What else, though, would people suggest to speed things up? (Windows redraw quite slowly.) -Should I try XDMCP? Is it faster than port forwarding with SSH? -Should I add more RAM to the Linux box? (It has 128MB with a PIII at 667 MHz.) -Does the amount video memory on the Linux box matter? How about on the Windows machine (hard to change because it's a laptop...)? I've tried ssh -C, but don't notice much of an improvement. Thanks for any suggestions.
Keyboard
Hi all, I'm having an odd problem. I'm connecting from my Windows 2000 Pro laptop to a remote machine running Debian stable (woody). I connect using startxwin.bat, and connect with SSH, enabling X11 Port Forwarding. I get to a bash shell on the remote machine, and all is well. I can type commands fine, and I start kde with startkde. KDE works as expected (except for a question about speed, which I'll address in a separate post), except that it doesn't accept keyboard input. I can use the mouse and run apps, but I can't type anything. I'm not using a non-US keyboard or anything, so this is a bit mystifying. Is there something I'm missing to get the graphical session to recognize keystrokes? Thanks.
Re: Minimising window with "Always on top" attribute leaves contents in underlying window
Howdy Harold, I thought you were taking it easy for a while! At 11:37 PM 1/25/2004 -0500, you wrote: Any reason for the following in your patch: @@ -893,7 +909,7 @@ if (s_pScreenPriv != NULL) s_pScreenPriv->fWindowOrderChanged = TRUE; } - return 0; + break; The thing that strikes me as odd is that you have to return from the WM_WINDOWPOSCHANGED message without calling DefWindowProc (which will get called if you change that return to a break) in order to prevent Windows from breaking that message down into a WM_SIZE and WM_MOVE message and sending those in addition. My worry is that you may have essentially found a bug in the WM_WINDOWPOSCHANGED handling that was fixed by allowing the WM_SIZE and WM_MOVE messages to be generated and handled, when we should really fix such a bug instead of accidentally masking its existance. I'm not comfortable removing this change from your patch since it will then need to be tested again to verify that things work as expected. Since you have already been testing it, I figured it would be easier for you to do the testing :) I did extensive testing without that change, actually, because it took me a while to figure out why the minimize button and sysmenus worked but the taskbar left-click 2x didn't. ;) You can remove it, but minimizing the window by 2x-clicking on the Windows taskbar won't propagate the Z order change w/the same messages as if you were to use the system menu or the minimize button. Why? AFAICT the minimize button or menu item send a wm-move, even if you don't let DefWindowProc() do its thing. I suspect Explorer sends its own messages when you click on the taskbar, and they are not the same as the frame WndProc()'s. FWIW I can't really see any reason not to allow DefWindowProc to have a shot at the WM_WINDOWPOSCHANGED message, but I'll admit that I've not gone through all of Kensuke's code... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Minimising window with "Always on top" attribute leaves contents in underlying window
Earle, Any reason for the following in your patch: @@ -893,7 +909,7 @@ if (s_pScreenPriv != NULL) s_pScreenPriv->fWindowOrderChanged = TRUE; } - return 0; + break; The thing that strikes me as odd is that you have to return from the WM_WINDOWPOSCHANGED message without calling DefWindowProc (which will get called if you change that return to a break) in order to prevent Windows from breaking that message down into a WM_SIZE and WM_MOVE message and sending those in addition. My worry is that you may have essentially found a bug in the WM_WINDOWPOSCHANGED handling that was fixed by allowing the WM_SIZE and WM_MOVE messages to be generated and handled, when we should really fix such a bug instead of accidentally masking its existance. I'm not comfortable removing this change from your patch since it will then need to be tested again to verify that things work as expected. Since you have already been testing it, I figured it would be easier for you to do the testing :) Let me know what to do with your patch, Harold
Re: Minimising window with "Always on top" attribute leaves contents in underlying window
Hi Mike... At 08:29 AM 1/25/2004 +, Mike wrote: I'm using 4.3.0-42 and have noticed that the following minor bug in multi-window operation when running on Win2K and WinXPPro: Two windows (terminal or otherwise) are overlapped and the topmost one has it's "Always on top" attribute set (by right-clicking on the windows title bar). The topmost window is then minimised, leaving a copy of its contents on the desktop, viewable by moving the remaining window over the portion of the desktop previously occupied by the other window. It's been a while since I submitted a patch, but since this problem is due to my code I'll be nice and fix it. Basically, whenever we get a WM_SYSCOMMAND:SC_MINIMIZE we need to disable the HWND_TOPMOST attribute and let the X system recognize it. On a WM_SYSCOMMAND:SC_RESTORE we just need to reset that attribute to what it was before. I'm attaching a patch *against the CVS -r CYGWIN tree* because I cannot get the XWin-4.3.0-42 source available on http://xfree86.cygwin.com/devel/server/changelog.html to compile properly, whereas the freedesktop CVS goes thru without a hitch. It adds a boolean fAlwaysOnTop to the window privates; caches the AOT value on a WM_SYSCOMMAND:SC_MINIMIZE and removes top-z attributes from the window; restores the AOT value on a WM_SYSCOMMAND:SC_RESTORE; and changes the WM_WINDOWPOSCHANGED event handler to always allow the Windoze DefWindowProc() to be called (necessary for the changes I did, and doesn't seem to have any negative effects). -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com fixaot.patch Description: Binary data
Re: Minimising window with "Always on top" attribute leaves contents in underlying window
This is probably related: using multi-window mode, open an emacs over ssh. Click on a menu (e.g, "File"), leave it droppped down, and minimize the emacs window. Result: emacs gets minimized, but the dropped down menu stays behind. -JT
Re: Minimising window with "Always on top" attribute leaves contents in underlying window
Mike Parker wrote: I'm using 4.3.0-42 and have noticed that the following minor bug in multi-window operation when running on Win2K and WinXPPro: Two windows (terminal or otherwise) are overlapped and the topmost one has it's "Always on top" attribute set (by right-clicking on the windows title bar). The topmost window is then minimised, leaving a copy of its contents on the desktop, viewable by moving the remaining window over the portion of the desktop previously occupied by the other window. Confirmed. Does anyone know how other window managers usually handle the always-on-top-then-minimized use case? -JT
Re: Trying to compile XWin, error in winwindow.c
Oyvind Harboe wrote: > $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co xc you missed the -r CYGWIN option. The latest cygwin development is not in the main branch of the repository. bye ago NP: Diary Of Dreams - Retaliation -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Trying to compile XWin, error in winwindow.c
I'm trying to compile XWin, which I've successfully done before, but I get compilation errors(below). To fetch source I did: $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co xc Then I followed these instructions to create a debug build: http://xfree86.cygwin.com/docs/cg/prog-build-native.html In World.log I find the error message below. $ make rm -f winwindow.o gcc -c -O2 -fno-strength-reduce -Wall -Wpointer-arith -I. -I../../../../expo rts/include/X11 -I../../../../include/fonts -I../../../../programs/Xserve r/fb -I../../../../programs/Xserver/mi -I../../../../programs/Xserver/miext/ shadow -I../../../../programs/Xserver/miext/layer -I../../../../program s/Xserver/include -I../../../../programs/Xserver/os -I../../../../in clude/extensions -I../../../../exports/include/X11 -I../../../../program s/Xserver/render -I../../../../programs/Xserver/randr -I../../../.. -I../../../ ../exports/include -D__i386__ -DWIN32_LEAN_AND_MEAN -DX_LOCALE -D_X86_ -D__CYGWIN__ -D_XOPEN_SOURCE -D_POSIX_C_SOURCE=199309 L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DS HAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DPIXPRIV-DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXvExtension -DXFree 86Server -DXvMCEx tension -DXResE xtension-DX_BYTE_ORDER=X_LITTLE_ENDIAN -DINCLUD E_ALLOCA_H -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH-DXvExtension -DXFree 86Server -DXvMCEx tension -DXResE xtension-DX_BYTE_ORDER=X_LITTLE_ENDIAN -DDDXTIM E -DFD_SETSIZE=256 -DDDXOSINIT -DDDXOSVERRORF -DDDXOSFA TALERROR -DHAS_SHM -DHAS_MMAP -UXFree86LOADER -UXF86DRI -DPROJECTROOT= "\"/usr/X11R6\"" winwindow.c winwindow.c: In function `winCopyWindowNativeGDI': winwindow.c:101: warning: unused variable `pBoxSrc' winwindow.c: In function `winReshapePRootless': winwindow.c:499: error: `pScreen' undeclared (first use in this function) winwindow.c:499: error: (Each undeclared identifier is reported only once winwindow.c:499: error: for each function it appears in.) winwindow.c:500: warning: left-hand operand of comma expression has no effect winwindow.c:502: warning: left-hand operand of comma expression has no effect make: *** [winwindow.o] Error 1
Minimising window with "Always on top" attribute leaves contents in underlying window
I'm using 4.3.0-42 and have noticed that the following minor bug in multi-window operation when running on Win2K and WinXPPro: Two windows (terminal or otherwise) are overlapped and the topmost one has it's "Always on top" attribute set (by right-clicking on the windows title bar). The topmost window is then minimised, leaving a copy of its contents on the desktop, viewable by moving the remaining window over the portion of the desktop previously occupied by the other window. Regards, Mike
