On Wed, Dec 12, 2007 at 05:04:46PM -0800, H. S. Teoh wrote: > Something must be wrong with the way xbomb resizes itself, because > non-maximal windows are possible under ratpoison (e.g. transients in > games like freedroid-rpg, xscavenger, etc., which manage to get a > non-maximal size without being in an infinite loop fighting with the > WM).
Nothing is wrong with the way xbomb resizes itself. There is no way to mark a window as "resizeable only in fixed increments" like there is for non-resizeable windows. Ratpoison respects the latter (because it has to); it also needs to respect the former by not attempting to resize a window more than once (or, at least, not more than once within a given short time period). If an application rejects the size that ratpoison selects for it, ratpoison needs to respect that. The question really is: who knows more about an application's needs--the application itself, or the window manager? I think it's pretty obviously the application itself. If there's an X-hint of some sort I can add to xbomb to make ratpoison more willing to respect its needs, then I'm willing to do that, but further than that I'm really not willing to go. In the mean time, there are several possible workarounds: 1. Run Xnest and run xbomb under that. 2. Create a ratpoison frame of a size that xbomb will accept before launching xbomb. 3. Possibly tell ratpoison that xbomb's window should be unmanaged (note: I was not able to get this to work, but I'm not a ratpoison expert.) But my opinion is that the bug here is in ratpoison. -- Chris Waters | Pneumonoultra- osis is too long [EMAIL PROTECTED] | microscopicsilico- to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
