On Wed, Feb 26, 2003 at 12:16:29PM +0100, Dominik Vogt wrote: > On Wed, Feb 26, 2003 at 11:57:27AM +0100, Olivier Chapuis wrote: > > Hello, > > > > A JToolBar is a tool bar that you can extract from the main java Frame > > and can become an independent window (and you can put it back). With > > my SUN Java 1.3.1 when I extract such a JToolBar, I get a 1x1 > > window. The explanation is simple, xprop gives: > > > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > program specified location: 70, 641 > > program specified size: 250 by 23 > > program specified minimum size: 1 by 1 > > program specified maximum size: 1 by 1 > > window gravity: NorthWest > > > > This is exactly bug #707 (and #654, the first part of #863 and #714 > > are maybe caused by such broken hints). ResizeHintOverride fixes this > > problem. However, as the size hints are clearly broken we may want to > > ignore these hints (and generate a broken size hints msg) and use the > > the size given by XGetWindowAttributes. > > > > Is this a good idea? > > You can't rely on XGetWindowAttributes to have the correct values.
Hum. Why? Do you mean that in AddWindow (add_window.c) the initial size we get can be broken vs the size hints and after that the application send a configure request which fixes the size of the window relatively to these hints? > But we could completely ignore the the max_... size hints if > > * A maximum size of 1x1 was specified > What about being a bit more aggressive (see bug report #863): If max size "<" requested size and the requested size is reasonable, say "=<" the screen size then ignore the max size hints? Or "* A maximum sizeof BROKEN_MAXSIZE_SIZExBROKEN_MAXSIZE_SIZE was specified" with BROKEN_MAXSIZE_SIZE ~ 50. > AND > > * The requested size is larger than that. > Olivier -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
