Subject: FvwmIdent drawing screwed

From: Dominik Vogt <[email-masked]>
Date: Wed, 25 Sep 2002 13:13:58 +0200

In the FvwmIdent.c ConfigureNotify handler, this code in 2.4

  /* only refresh if moved */
  if (x != Event.xconfigure.x || y != Event.xconfigure.y)
  {
    x = Event.xconfigure.x;
    y = Event.xconfigure.y;
    /* flush any expose events */
    while (XCheckTypedEvent(dpy, Expose, &Event)) ;
    XClearWindow(dpy, main_win);
    RedrawWindow();
  }

was changed to this in 2.5:
  if ((Event.xconfigure.send_event ||
     CSET_IS_TRANSPARENT_PR_PURE(colorset)) &&
    (x != Event.xconfigure.x ||
     y != Event.xconfigure.y))
  {
    x = Event.xconfigure.x;
    y = Event.xconfigure.y;
    /* flush any expose events */
    while (FCheckTypedEvent(dpy, Expose, &Event));
    if (UsePixmapDrawing)
    {
      PixmapDrawWindow(main_width, main_height);
    }
    else
    {
      UpdateBackgroundTransparency(
        dpy, main_win, main_width, main_height,
        &Colorset[(colorset)], Pdepth, gc, True);
    }
  }

So, the initial ConfigureNotify sometimes eats up the initial
Expose exent and no text is drawn into FvwmIdent at all.
Shouldn't the XClearWindow() and RedrawWindow() calls be added to
the "else" branch of the inner "if"?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 25 Sep 2002 16:55:24 +0200

> the "else" branch of the inner "if"?

The 2.5 code was "correct" before you re-add the StructureNotifyMask
(for ReparentNotify event). As StructureNotifyMask was set only with
transparent background and UpdateBackgroundTransparency generate a
full expose event (if the window has a transparent bg). I do not think
we should handle any configure event when the background is not
transparent. So, a good fix is to simply break if the bg is not
transparent. The mistake I do is to remove the StructureNotifyMask (in
the non transparent case) as we need to handle ReparentNotify for the
layer stuff.

But what about making FvwmIdent a transient window of the window it
identify? This will give a lot of features to FvwmIdent.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 25 Sep 2002 17:26:00 +0200

On Wed, Sep 25, 2002 at 04:55:24PM +0200, Olivier Chapuis wrote:
> transparent.

I suggest this:

  do_eat_events = False;
  if (UsePixmapDrawing)
  {
    PixmapDrawWindow(main_width, main_height);
    do_eat_events = True;
  }
  else if (UpdateBackgroundTransparency(
           dpy, main_win, main_width, main_height,
           &Colorset[(colorset)], Pdepth, gc, True) == True)
  {
    do_eat_events = True;
  }
  if (do_eat_events == True)
  {
    while (FCheckTypedEvent(dpy, Expose, &Event))
    {
      /* nothing */
    }
  }

UpdateBackgroundTransparency() needs to return if it did anything
(True) or not (False).

> So, a good fix is to simply break if the bg is not
 
> identify? This will give a lot of features to FvwmIdent.

What features are you thinking of?  Okay, we won't need the
"Layer" command anymore, but other than that, the only change
would be that the FvwmIdent window gets iconified along with the
identified window.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 25 Sep 2002 21:09:45 +0200

> would be that the FvwmIdent window gets iconified along with the

Placement + all the Transient styles we have?

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 26 Sep 2002 16:05:34 +0200

> Placement + all the Transient styles we have?

If you think that's better, I have no objections.  I really don't
care much about FvwmIdent because it's usually gone before I
notice it had decorations :-)

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 26 Sep 2002 23:47:51 +0200

> notice it had decorations :-)

In fact, as we have the MinimalLayer FvwmIdent option we cannot
remove the "layer" command. But I've noted something strange:

Style *  StackTransientParent, RaiseTransient

A window with layer 3, open a transient, the transient has layer 3.
Now change the layer of the transient to 4. The transient is raised,
so (above style) the window is raised and get layer 4. This seems
strange, I think that the window should be raised but the layer
should not change?

Similarly with

Style *  DontStackTransientParent, RaiseTransient

if the layer of the window become larger, the layer of the transient
become larger too (maybe it should not change).
You have a similar situation with LowerTransient.

IMHO, StackTransientParent, RaiseTransient and LowerTransient
should raise/lower accordingly to their definition but these
styles should not interfere with layer but when the Transient
is mapped? Humm... I do not know :o/
 
Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 27 Sep 2002 10:56:09 +0200

> is mapped? Humm... I do not know :o/

There is a lot of code trying to keep the main window and its
transients on the same layer.  But I am not sure if it it at all
useful.  Nobody ever reported his or her experience with that
feature, so I assume nobody uses it.

By the way, I think it is a very bad idea to raise the parent to a
higher layer when a transient is mapped on a higher layer:

  Style foo_main      Layer 4
  Style foo_transient Layer 6

 * Start app. foo.  Window is placed on layer 4.
 * Open transient.  Transient and main window are placed on layer
   6.
 * Close transient

==> main window is stuck on layer 6. Doh.

That might be acceptable when the Layer command is used, but
definitely not for the Layer style.

Bye

Dominik ^_^  ^_^