xterm/urxvt display problems
Hi I have a shortcut for launching ncmpcpp (mpd client). When I use it for the first time in the session, the display is fine. But when I spawn it again I get some junk display, some areas of the screen are not refreshed, staying permanently. However if I laucnh ncmpcpp from an existing *term this problem disappears. Any ideas ? My spawn command is : ((modMask, xK_F1 ), spawn "/usr/bin/urxvt -rv -name ziq -e /usr/bin/ncmpcpp") I'm not even sure it's an xmonad related problem Pascal
On Wed, 2009/01/21 15:32:04 +0100, pascal wrote:
I have a shortcut for launching ncmpcpp (mpd client). When I use it for the first time in the session, the display is fine. But when I spawn it again I get some junk display, some areas of the screen are not refreshed, staying permanently.
That sounds like a known bug in rxvt. Using a hinted layout fixes it. There are two hinted layouts (HintedGrid, HintedTile) and a layout modifier that can apply hints to any layout (LayoutHints) in xmonad-contrib 0.8.
On Wed, Jan 21, 2009 at 03:32:04PM +0100, pascal wrote:
Hi
I have a shortcut for launching ncmpcpp (mpd client). When I use it for the first time in the session, the display is fine. But when I spawn it again I get some junk display, some areas of the screen are not refreshed, staying permanently. However if I laucnh ncmpcpp from an existing *term this problem disappears. Any ideas ?
My spawn command is : ((modMask, xK_F1 ), spawn "/usr/bin/urxvt -rv -name ziq -e /usr/bin/ncmpcpp")
I'm not even sure it's an xmonad related problem
Pascal _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
I had a similar problem with mutt and other ncurses based apps. They begin drawing using the original geometry before xmonad gets any change to resize it. The reason it works the first time in a session is that the startup is slower. I worked around it by making a small delay before the app starts. Try something like this: spawn "urxvt -e '{ sleep 0.2; myApp; }'" Regards, Mads
Le Wed, 21 Jan 2009 16:28:41 +0100,
Mads N Noe
On Wed, Jan 21, 2009 at 03:32:04PM +0100, pascal wrote:
Hi
I have a shortcut for launching ncmpcpp (mpd client). When I use it for the first time in the session, the display is fine. But when I spawn it again I get some junk display, some areas of the screen are not refreshed, staying permanently. However if I laucnh ncmpcpp from an existing *term this problem disappears. Any ideas ?
My spawn command is : ((modMask, xK_F1 ), spawn "/usr/bin/urxvt -rv -name ziq -e /usr/bin/ncmpcpp")
I'm not even sure it's an xmonad related problem
Pascal _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
I had a similar problem with mutt and other ncurses based apps. They begin drawing using the original geometry before xmonad gets any change to resize it. The reason it works the first time in a session is that the startup is slower. I worked around it by making a small delay before the app starts. Try something like this:
spawn "urxvt -e '{ sleep 0.2; myApp; }'"
Regards, Mads
Thanks, display is fine now with the sleep command. Pascal
On 2009 Jan 21, at 10:28, Mads N Noe wrote:
On Wed, Jan 21, 2009 at 03:32:04PM +0100, pascal wrote:
I have a shortcut for launching ncmpcpp (mpd client). When I use it for the first time in the session, the display is fine. But when I spawn it again I get some junk display, some areas of the screen are not refreshed, staying permanently. However if I laucnh ncmpcpp from an existing *term this problem disappears. Any ideas ?
I had a similar problem with mutt and other ncurses based apps. They begin drawing using the original geometry before xmonad gets any change to resize it. The reason it works the first time in a session is that the startup is slower. I worked around it by making a small delay before the app starts. Try something like this:
spawn "urxvt -e '{ sleep 0.2; myApp; }'"
XTerm has a -wf option (or waitForMap resource) which causes it to delay starting the process until the window is mapped and the window size negotiation with the window manager is finished. It doesn't look like urxvt has anything similar; perhaps it should be requested. In the meantime, see if "xterm -wf -e myApp" works any better. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
Le Fri, 23 Jan 2009 00:34:33 -0500,
"Brandon S. Allbery KF8NH"
XTerm has a -wf option (or waitForMap resource) which causes it to delay starting the process until the window is mapped and the window size negotiation with the window manager is finished. It doesn't look like urxvt has anything similar; perhaps it should be requested. In the meantime, see if "xterm -wf -e myApp" works any better.
Nice, that works fine.
participants (4)
-
Brandon S. Allbery KF8NH -
lithis -
Mads N Noe -
pascal