On Wed, Mar 1, 2017 at 3:56 AM, Vincent Lefevre <[email protected]> wrote: > On 2017-02-28 22:26:45 -0700, Jaimos Skriletz wrote: >> I wrote a small patch that adds a small wait to Dominik Vogt's patch >> and so far I am not getting these warnings triggered. The patch is >> attached and you can find a .deb I built in stretch here > > Thanks. Indeed, this solves the problem. Now, I only get the following > warning when starting fvwm: > > [fvwm][GetWindowSizeHints]: <<WARNING>> reason: 2: The hints have been > ignored because the window's current size would have become invalid. The new > hints will become active when the window generates the next ConfigureRequest. > > [fvwm][GetWindowSizeHints]: <<WARNING>> The application window (id 0x1800003) > "gkrellm" has broken size hints (inconsistent with current size). > fvwm is ignoring those hints. hint override = 0, flags = 230 > min_width = 156, min_height = 736, max_width = 156, max_height = 736 > width_inc = 0, height_inc = 0 > min_aspect = 0/0, max_aspect = 0/0 > base_width = 0, base_height = 0 > win_gravity = 1 > > If you are having a problem with the application, send a bug report > with this message included to the application owner. > There is no need to notify [email protected]. > > It is started in InitFunction with: > > "I" Exec gkrellm -geometry +0-0 > > and it has the following style: > > Style "Gkrellm" WindowListSkip >
My patch won't fix other programs from triggering these warnings. These warnings are due to a fvwm thinking a window is in an bad state and informing the user. The design of these warnings (from the fvwm-workers mailing list) is to help spot windows that are misbehaving. The issue is there is inherent race conditions in the X protocol. For example, there is no way to change the window size and the requested min/max size in one atomic action, so what is happening is a window is changing sizes/hints in two separate steps triggering this warning while it is in this inconsistent state for a short period of time. I have been talking with the fvwm-workers list to try to find a reasonable fix for this so it doesn't spit out so many false positives. But outside of what I did with FvwmIconMan is a bad/temporary fix, I will be waiting to see if fvwm-workers has any better solution to keep so many false positives from triggering this warning. Until then my hope in sharing the patch with you is that you could at least use FvwmIconMan without it filling up your logs. jaimos
