ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RP] About redrawing/resizing/positioning


From: Florian Cramer
Subject: Re: [RP] About redrawing/resizing/positioning
Date: Fri, 12 Aug 2005 13:31:34 +0200

Am Freitag, 12. August 2005 um 12:38:17 Uhr (+0200) schrieb Daniel Link:
 
> 1. Terminal programs should once be redrawn (C-t C-l) automatically
> after startup and after assigning them to a new frame.

To work around this xterm bug, you could simply write a shell script:

#!/bin/sh

ratpoison -c exec xterm
ratpoison -c redisplay

...call it "ratterm", for example, and map it to C-t C-l in your
.ratpoisonrc:

bind l exec ratterm


> 3. Has there been any news about the Ncurses issue? I'm not sure whether
> I got the list archives right. Was it only about Ncurses from within
> screen? If so, my problem's new. Try centericq or mp3blaster and resize
> the frame -> parts of the window aren't used or become and stay black.
> Do these programs handle redrawing insufficiently? Can you think of a
> workaround?

I tested it with centericq and could reproduce the problem identically.
It is clearly a bug in centericq because it occurs identically when
you run it within GNU screen and split frames there. The author of
centericq should be bugged to either implement better redrawing routines
or enable a manual redraw with Ctrl-l [as it is the standard in other
terminal programs, mutt, lynx/links/elinks and slrn, for example]. 

> 4. Could all the transient windows of one application be placed not on
> top but next to each other?

That would contradict ratpoison's philosophy of one application in one
frame and not do any automatic frame layouts by itself. But this is
feature which could be externally scripted, similar to expose.pl.

> 5. Ever tried xine and opened the context menu? Yuck.

Yes, I know. A workaround is to use another xine gui frontend, for
example gxine, totem or kaffeine. It's not so nice though because these
frontends need more time to boot and, thanks to their heavy KDE/Gnome
dependencies, suck a lot of precious resources.

-F

-- 
http://cramer.netzliteratur.net




reply via email to

[Prev in Thread] Current Thread [Next in Thread]