On Wed, Mar 1, 2017 at 9:24 AM, Dominik Vogt <dominik.v...@gmx.de> wrote: > On Wed, Mar 01, 2017 at 07:18:11AM -0700, Jaimos Skriletz wrote: >> On Wed, Mar 1, 2017 at 5:30 AM, Dominik Vogt <dominik.v...@gmx.de> wrote: >> > On Tue, Feb 28, 2017 at 10:22:33PM -0700, Jaimos Skriletz wrote: >> >> On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz >> >> <jaimosskril...@gmail.com> wrote: >> >> > Hello, >> >> > >> >> > FvwmIconMan still reports Hint warnings even with the patchs applied. >> >> >> >> I wrote this small patch that has FvwmIconMan wait until the window >> >> has resized to set the window hints. This is in the lines of Dominik >> >> Vogt's patch, but waits until FvwmIconMan has fully resized to run >> >> fix_manager_size() to set the window hints. My tests here no longer >> >> seem to tiger the warnings like it still sometimes did. >> >> >> >> As an additional thought, talking to Thomas Adam about the patch in >> >> #fvwm, he mentioned that the issue is more FVWM being overly cautious >> >> and the fix should be in how fvwm handles size hint warnings over >> >> working with FvwmIconMan to avoid triggering them. >> >> >> > >> > So, if it's not possible to completely fix FvwmIconMan in a decent >> > way, what do we do with the warning? I'd rather not disable it, >> > but the number of false positives is too high. One could make a >> > style that disables the warning for a certain class of windows, >> > but that would probably be used as "style * ...", disabling the >> > warning for everything. :-/ >> > >> >> FvwmIconMan isn't the only application that triggers these warnings, >> but using it in a situation where it grows/shrinks is a very regular >> way to cause the warnings and it fills up .xsession-error with mostly >> warnings. Other applications I use only trigger these warnings rarely, >> and in each case the application appears to work fine so yet more >> false positives. But FvwmIconMan is the only one that regularly >> resizes itself triggering the warning a lot. > > Of course. Flooding the log was not the intention of the patch. > >> I had two ideas on this, one is use a BugOpts option that can turn on >> these warnings for a user who wants to debug things, but they are off >> by default. This is basically your style idea and the affect will be >> almost everywhere these warnings will not appear and thus may miss out >> on programs that actually need to be reported. > > Yes, but defaulting to "off" makes the warning effectively useless. >
Yea, hence the same line as a style and then turning it off. Though if a window is misbehaving it could be turned on to see if it is triggering these warnings. But one would have to know a window is misbehaving and not able to just look in the logs to see that one is. >> Another is maybe don't have fvwm jump to conclusions that there is a >> warning. > > Let me rephrase that: Fvwm informs the user about something that > might not be possible to clean up. In such a situation the user > would see that the window did not get resized as intended and has > no clue why. At least, fvwm has told her that something strange > was going on. > >> What if there was some timer that fvwm gave the application >> to fix itself before reporting a warning, and then the warning is not >> just that the window had this inconstant state which seems to give >> false positives, but it has been inconsistent for a set amount of time >> without fixing itself. > > Too complex stuff for such a simple situation. Maybe one could > peek the event queue for an event that fixes the windows's size > and not complain if such an event is already pending? Another > option is to generate only a limited number of these warning for > each window. > > Does the attached patch improve the situation? > I have applied the patch and it doesn't seem to change the situation, FvwmIconMan is still triggering the hint size warnings every time a window is added or removed. jaimos
