Re: FvwmIconMan still sometimes triggers Hint Warnings

On Wed, Mar 1, 2017 at 9:24 AM, Dominik Vogt <[email protected]> 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 <[email protected]> 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
>> >> <[email protected]> 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