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.
> 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?
> Anyways, for those of us who use FvwmIconMan as a growing/shrinking
> standalone module, this patch drastically reduces the amount of
> warnings, but I agree it really doesn't seem like the way to deal with
> this issue to make applications have to add these waits to deal with
> resizing both the window and the size hints.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
>From 8f74a2e6f1f0e059e9d1e073bace15a33dd2c016 Mon Sep 17 00:00:00 2001
From: Dominik Vogt <dominik.v...@gmx.de>
Date: Wed, 1 Mar 2017 17:24:13 +0100
Subject: [PATCH] Try to fix FvwmIconMan warnings.
---
fvwm/events.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/fvwm/events.c b/fvwm/events.c
index 980ccab..a7d41d0 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -3627,6 +3627,10 @@ ICON_DBG((stderr, "hpn: icon changed '%s'\n", fw->name.name));
break;
}
case XA_WM_NORMAL_HINTS:
+ {
+ int do_check;
+ XEvent dummy;
+
/* just mark wm normal hints as changed and look them up when
* the next ConfigureRequest w/ x, y, width or height set
* arrives. */
@@ -3641,8 +3645,11 @@ ICON_DBG((stderr, "hpn: icon changed '%s'\n", fw->name.name));
* Note that SET_HAS_NEW_WM_NORMAL_HINTS being set here to
* true is still valid.
*/
- GetWindowSizeHintsWithCheck(fw, 1);
+ do_check = !FCheckTypedWindowEvent(
+ dpy, FW_W(fw), ConfigureRequest, &dummy);
+ GetWindowSizeHintsWithCheck(fw, do_check);
break;
+ }
default:
if (te->xproperty.atom == _XA_WM_PROTOCOLS)
{
--
1.7.10.4
