WinXP Taskbar Overlaps Maximized xterm
I have DAGS and looked at the cygwin FAQ but cannot seem to find this problem addressed, so ... When I maximize an xterm on my WinXP workstation, it gets sized so that the Windows taskbar slighty overlaps the bottom of the xterm window. This makes it very difficult to read the last line on the xterm display. Is there a fix/workaround for this? Tired-Of-Manually-Maximizing-My-xterm-Window-ly Yours, Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ -- 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: WinXP Taskbar Overlaps Maximized xterm
Larry Hall (Cygwin X) wrote: Tim Daneliuk wrote: I have DAGS and looked at the cygwin FAQ but cannot seem to find this problem addressed, so ... When I maximize an xterm on my WinXP workstation, it gets sized so that the Windows taskbar slighty overlaps the bottom of the xterm window. This makes it very difficult to read the last line on the xterm display. Is there a fix/workaround for this? How xterm maximizes is controlled by the window manager. If you're running in -multiwindow mode, you may want to consider using another window manager that can take into account the task bar (in that But doesn't -multiwindow mode effectively use the native WinXP window management system (that should know about its own task bar size)? environment). An alternative would be to hide your task bar when you're not using it (keeping it always on top probably). -- Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ -- 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: WinXP Taskbar Overlaps Maximized xterm
Tim Daneliuk wrote: Larry Hall (Cygwin X) wrote: Tim Daneliuk wrote: I have DAGS and looked at the cygwin FAQ but cannot seem to find this problem addressed, so ... When I maximize an xterm on my WinXP workstation, it gets sized so that the Windows taskbar slighty overlaps the bottom of the xterm window. This makes it very difficult to read the last line on the xterm display. Is there a fix/workaround for this? How xterm maximizes is controlled by the window manager. If you're running in -multiwindow mode, you may want to consider using another window manager that can take into account the task bar (in that But doesn't -multiwindow mode effectively use the native WinXP window management system (that should know about its own task bar size)? A bit more poking around and I discovered that this behavior is font-size sensitive. If I start xterm with either an -fn 10x20 argument or select the Huge font option once xterm has started, I get this problem of the xterm window being slightly overwritten by the taskbar when xterm is maximized. With smaller fonts, this problem disappears. I dunno if that helps figuring out what is going on or not ... -- Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ -- 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: WinXP Taskbar Overlaps Maximized xterm
Thomas Dickey wrote: On Wed, 27 Sep 2006, Larry Hall (Cygwin X) wrote: There's a similar issue with KDE and xterm on RHEL 3. So it could also be is doesn't appear to be the right tense, since RHEL 3 was released a few years ago and is not the current version. iirc, cygwin's still distributing xterm patch #202, which is more recent than RHEL 3 (mid-2005). I made improvements to the layout in the latter part of 2005, so it would for example maximize as expected. On the other hand, it still doesn't re-maximize if the font size is changed while maximized. Well, the problem I am seeing is when I initially maximize xterm with a large font already selected. (I would not expect it necessarily to work properly if I changed fonts once already maximized.) an upstream problem in xterm, if it still exits in the current version. You might want to check that out. I don't see the problem with konsole. given that konsole was developed as part of KDE, that's understandable... -- Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: New Bash Release Broken?
Larry Hall (Cygwin X) wrote: SNIP Ideas anyone? Is there a change to bash syntax and I just didn't get the memo? That's one way to put it. http://cygwin.com/ml/cygwin-announce/2006-09/msg6.html That was it all right ... guess I better subscribe to -announce ... and thanks for the prompt reply ... -- Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: xferee, cygwin, when's your birthday?
Kesrin Hanprasert wrote: Kesrin Hanprasert([EMAIL PROTECTED]), is a member of BirthdayTime.com and wants to know your birthday. Kesrin Hanprasert says: Hi !!br / I'm inviting you to enter your birthday into my calendar at BirthdayTime.br / You will help me remember it!br /Click here to enter your birthday into my list: I dunno about xfree, but I suppose cygwin might consider it's birthday to be Jan. 1, 1970 ... -- Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ -- 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/
Restore Alt-Ctl-Backspace As Server Kill
I really hate the assignment of Alt-F4 to kill a running X-server. What magic must I perform to set it back to the more traditional Alt-Ctl-Backspace combo? Thanks. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ -- 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: Restore Alt-Ctl-Backspace As Server Kill
Tim Daneliuk wrote: I really hate the assignment of Alt-F4 to kill a running X-server. What magic must I perform to set it back to the more traditional Alt-Ctl-Backspace combo? Thanks. Let me ask this more properly. I know how to use -nounixkill and -nowinkill to prevent keyboard initiated kills of the server. I use a VirtuaWin on a WinXP system to provide multiple desktops. One of them is activated via Ctrl-Alt-F4. When I do this, it kills the running instance of Cygwin/X which apparently sees this key combo as a kill server command. This is true whether or not -nounixkill and/or -nowinkill are in use. Ideas? -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ -- 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: Restore Alt-Ctl-Backspace As Server Kill
Gery Herbozo Jimenez wrote: I really hate the assignment of Alt-F4 to kill a running X-server. What magic must I perform to set it back to the more traditional Alt-Ctl-Backspace combo? Thanks. Ideas? Why don't you use just the 'exit' word on your xterm and then right click on your 'X server' icon to close/exit this application? At least works for me. This is not the central issue - the issue is that VirtuaWin may be prematurely killing the session. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ -- 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: Restore Alt-Ctl-Backspace As Server Kill
Tim Daneliuk wrote: Jon TURNEY wrote: Tim Daneliuk wrote: Tim Daneliuk wrote: I really hate the assignment of Alt-F4 to kill a running X-server. What magic must I perform to set it back to the more traditional Alt-Ctl-Backspace combo? Thanks. Let me ask this more properly. I know how to use -nounixkill and -nowinkill to prevent keyboard initiated kills of the server. I use a VirtuaWin on a WinXP system to provide multiple desktops. One of them is activated via Ctrl-Alt-F4. When I do this, it kills the running instance of Cygwin/X which apparently sees this key combo as a kill server command. This is true whether or not -nounixkill and/or -nowinkill are in use. Ideas? I'm afraid I'm not able to reproduce this. I see that the code doesn't consider the state of the control or shift keys when looking for alt-f4 to close the server (so ctrl-alt-f4 also closes it, which is possibly a bug), but this should also be disabled by -nowinkill, which is what I observe. Very strange. I start my Xserver instance like this: run XWin :$SCREEN -nowinkill -unixkill -ac +kb -clipboard -silent-dup-error -nod ecoration Then I login like this (both of these via a cygwin shell script): ssh $u...@$remote export DISPLAY=$DISPLAY;$COMMAND;logout I can bounce between VirtuaWin sessions all like via Ctl-Alt-Session # and all is well until I try Ctl-Alt-4. If I exit VirtuaWin, that key combination does not kills the session, so this hints at this being a VirtuaWin problem not one in cygwin ... OK ... I've narrowed the problem down and it is REALLY strange: In updating to VirtuaWin 4.01, I notice that I either misreported the problem and/or the bug has expanded with this new release. Now when I switch to any other virtual desktop, it randomly kills the Xsession. What is *really* interesting about this is that it seems to do this only if I launch a window manager as the $COMMAND argument above. If I just kick off an xterm, and then manually launch the wm from there, the problem disappears. IOW, this works: ssh u...@machine export DISPLAY=mymachine:9;xterm;logout But both of these have the problem: ssh u...@machine export DISPLAY=mymachine:9;startfluxbox;logout ssh u...@machine export DISPLAY=mymachine:9;exec startfluxbox;logout Now the Narrowing It Down and Really Strange part. This works just fine: ssh u...@machine export DISPLAY=mymachine:9;exec fluxbox;logout It seems that something (I have not figured out just what yet) about the default fluxbox startup script (on FreeBSD 6-STABLE in this case) is interacting with the cygwin X server and killing it. Oiy, my head ... --- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ -- 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: Restore Alt-Ctl-Backspace As Server Kill
Mark J. Reed wrote: I don't use it, but startfluxbox sounds like something that kicks of fluxbox and then exits (vs xterm which stays around). Could that be the problem? Likely true. Also, if you're using ssh, why not use ssh forwarding instead of sending the X traffic back over a separate, unencrypted connection? And you don't need to logout explicitly; terminating the shell does the same thing. ssh -Y u...@machine startfluxbox you might try ssh -nY u...@machine startfluxbox to prevent standard input from causing a problem... D'oh. That *is* a much better way to do this. I shall look into this as I am able ... Thanks! On Tue, Feb 3, 2009 at 2:48 PM, Tim Daneliuk wrote: ssh u...@machine export DISPLAY=mymachine:9;xterm;logout But both of these have the problem: ssh u...@machine export DISPLAY=mymachine:9;startfluxbox;logout ssh u...@machine export DISPLAY=mymachine:9;exec startfluxbox;logout Now the Narrowing It Down and Really Strange part. This works just fine: ssh u...@machine export DISPLAY=mymachine:9;exec fluxbox;logout It seems that something (I have not figured out just what yet) about the default fluxbox startup script (on FreeBSD 6-STABLE in this case) is interacting with the cygwin X server and killing it. Oiy, my head ... -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ -- 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: Restore Alt-Ctl-Backspace As Server Kill
Tim Daneliuk wrote: Mark J. Reed wrote: I don't use it, but startfluxbox sounds like something that kicks of fluxbox and then exits (vs xterm which stays around). Could that be the problem? Likely true. That is, indeed what it was .. at least in some form. The fix turned out to be to configure fluxbox to kickoff an xterm when *it* started. I am still unclear why this is happening. When a wm is kicked off, it has to run in background. ISTM that this should be enough to keep the X session up ... it's not for some reason. It seems that X specifically wants to be attached to some kind of terminal/pseudoterminal to stick around, notwithstanding the use of the -n option, which seemed to make no difference. Also, if you're using ssh, why not use ssh forwarding instead of sending the X traffic back over a separate, unencrypted connection? And you don't need to logout explicitly; terminating the shell does the same thing. ssh -Y u...@machine startfluxbox you might try ssh -nY u...@machine startfluxbox Neither of these solved the problem (not surprising). However, introducing X forwarding *really* slowed startup down - from about 2-3 seconds to about 10-15 seconds. It looks like this is all related to setting up the encrypted channel, because once it's setup, system interaction is at subjectively normal speed. to prevent standard input from causing a problem... D'oh. That *is* a much better way to do this. I shall look into this as I am able ... Thanks! On Tue, Feb 3, 2009 at 2:48 PM, Tim Daneliuk wrote: ssh u...@machine export DISPLAY=mymachine:9;xterm;logout But both of these have the problem: ssh u...@machine export DISPLAY=mymachine:9;startfluxbox;logout ssh u...@machine export DISPLAY=mymachine:9;exec startfluxbox;logout Now the Narrowing It Down and Really Strange part. This works just fine: ssh u...@machine export DISPLAY=mymachine:9;exec fluxbox;logout It seems that something (I have not figured out just what yet) about the default fluxbox startup script (on FreeBSD 6-STABLE in this case) is interacting with the cygwin X server and killing it. Oiy, my head ... -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ -- 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: Restore Alt-Ctl-Backspace As Server Kill
Jon TURNEY wrote: Tim Daneliuk wrote: Tim Daneliuk wrote: I really hate the assignment of Alt-F4 to kill a running X-server. What magic must I perform to set it back to the more traditional Alt-Ctl-Backspace combo? Thanks. Let me ask this more properly. I know how to use -nounixkill and -nowinkill to prevent keyboard initiated kills of the server. I use a VirtuaWin on a WinXP system to provide multiple desktops. One of them is activated via Ctrl-Alt-F4. When I do this, it kills the running instance of Cygwin/X which apparently sees this key combo as a kill server command. This is true whether or not -nounixkill and/or -nowinkill are in use. Ideas? I'm afraid I'm not able to reproduce this. I see that the code doesn't consider the state of the control or shift keys when looking for alt-f4 to close the server (so ctrl-alt-f4 also closes it, which is possibly a bug), but this should also be disabled by -nowinkill, which is what I observe. Very strange. I start my Xserver instance like this: run XWin :$SCREEN -nowinkill -unixkill -ac +kb -clipboard -silent-dup-error -nod ecoration Then I login like this (both of these via a cygwin shell script): ssh $u...@$remote export DISPLAY=$DISPLAY;$COMMAND;logout I can bounce between VirtuaWin sessions all like via Ctl-Alt-Session # and all is well until I try Ctl-Alt-4. If I exit VirtuaWin, that key combination does not kills the session, so this hints at this being a VirtuaWin problem not one in cygwin ... -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ -- 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/
