Subject: very strange resizing bug only with fvwm

From: Neil Zanella <[email-masked]>
Date: Wed, 26 Jun 2002 23:10:34 -0230 (NDT)

Hello,

Sorry to bother you but I think I found a very strange bug which does not
show up under twm, mwm, sawfish, or window maker. The bug can be seen as
follows: compile the following code under Red Hat 7.3 in a directory 
called main by typing qmake -project; qmake; make; ./main
Then grab one of the edges of the window and resize it
so it becomes really small and then quickly large many
times. Upon releasing the mouse the window will resize
itself to an unappropriate or state and/or may exhibit
some strange resizing behavior which does not show up 
under the four window managers described above.
Here is the code:

Thanks for your replies,

Neil

--- main.cpp ---

#include <qapplication.h>
#include <qpopupmenu.h>
#include <qmenubar.h>
#include <qpainter.h>
#include <qvbox.h>

#define H 40
#define W 60

class Foo: public QVBox {
  public:
    Foo(QWidget *parent = 0): QVBox(parent) {
      bar = new QMenuBar(this);
      one = new QPopupMenu(bar);
      two = new QPopupMenu(bar);
      thr = new QPopupMenu(bar);
      bar->insertItem("The              ", one);
      bar->insertItem("Menu             ", two);
      bar->insertItem("Bar              ", thr);
      setSizeIncrement(W, H);
      resize(10 * W, 10 * H + bar->height());
      resize(10 * W, 10 * H + bar->height());
    }
  protected:
    void paintEvent(QPaintEvent *);
  private:
    QMenuBar *bar;
    QPopupMenu *one;
    QPopupMenu *two;
    QPopupMenu *thr;
};

void Foo::paintEvent(QPaintEvent *) {
  int contentHeight = height() - bar->height();
  if (contentHeight % H != 0) {
    setBaseSize(W, bar->height() + H);
    resize(width(), height() - contentHeight % H);
  }
  QPainter p(this); int i, j;
  for (i = 0; i < height() / H; i++)
    for (j = 0; j < width() / W; j++)
      p.drawRect(j * W, i * H + bar->height(), W, H);
}

int main(int argc, char **argv) {
  QApplication app(argc, argv);
  Foo foo;
  app.setMainWidget(&foo);
  foo.show();
  return app.exec();
}

// end of main.cpp

--
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: Dominik Vogt <[email-masked]>
Date: Sun, 30 Jun 2002 02:58:48 +0200

> called main by typing qmake -project; qmake; make; ./main

If someone else wants to try: just type

  $ g++ -I /usr/lib/qt-2.3.0/include/ -c main.cpp 
  $ g++ -o main main.o -L /usr/lib/qt2/lib -lqt

(change the paths if necessary).

> under the four window managers described above.

Do you mean the effect that the interior of the window does not
match the frame size?  For example, instead of

  +-------------------+
  | The  Menu  Bar    |
  +---+---+---+---+---+
  |   |   |   |   |   |
  |   |   |   |   |   |
  |   |   |   |   |   |
  +---+---+---+---+---+
  |   |   |   |   |   |
  |   |   |   |   |   |
  |   |   |   |   |   |
  +---+---+---+---+---+
  |   |   |   |   |   |
  |   |   |   |   |   |
  |   |   |   |   |   |
  +---+---+---+---+---+

you get

  +-------------------+
  | The  Menu  Bar    |
  +---+---+---+---+---+
  |   |   |   |   |   |
  |   |   |   |   |   |
  +---+---+---+---+---+
  |   |   |   |   |   |
  |   |   |   |   |   |
  +---+---+---+---+---+
  |   |   |   |   |   |
  |   |   |   |   |   |
  +---+---+---+---+---+
  |                   |
  |                   |
  +-------------------+

I think that's a qt bug.  Fvwm does not directly inform the
application of its size.  X does that when the window is resized.
t seems that qt somehow loses track of its own size.  Once the
size is screwed up, qt seems to keep the same size defect even
when the window is resized, e.g. if the internal decoration is 20
pixels too short, it's also 20 pixels too short after the next
resizing step.  Another bug I noticed is that if the window gets
too thin and the menu bar is rearranged vertically, the layout of
the grid is not adapted to the reduced vertical space:

  +-------+
  | The   |
  | Menu  |
  | Bar   |
  +-+-+-+-+
  | | | | |
  | | | | |
  | | | | |
  +-+-+-+-+
  | | | | |
  | | | | |
  | | | | |
  +-+-+-+-+
  +-+-+-+-+

instead of

  +-------+
  | The   |
  | Menu  |
  | Bar   |
  +-+-+-+-+
  | | | | |
  | | | | |
  +-+-+-+-+
  | | | | |
  | | | | |
  +-+-+-+-+
  | | | | |
  | | | | |
  +-+-+-+-+

I think both problems should be reported to the qt people.

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: Neil Zanella <[email-masked]>
Date: Sun, 30 Jun 2002 02:13:13 -0230 (NDT)

Hi Dominik!

Thank you for your reply...

> match the frame size?  For example, instead of

I am running the latest stable fvwm release, 2.4.8,
and am not seeing the above problem. However I am
seeing some other things. I am also using Qt 3.0.3
instead of Qt 2.3.0...

> It seems that qt somehow loses track of its own size.  Once the
> A:
> B:

This is something I reported with an earlier code snippet.
It appears as though window managers are not checking for
whether the base size property has changed until after
the user releases the mouse button from the window
frame. Resizing once more sets the window size
correctly with the new base size. I wonder
whether the limitation lies in the X
event reporting system.

But there is another problem. When I use the code posted
to this thread with fvwm and grab the frame and move the
mouse around in circles quickly, I release the mouse on
the window when it looks like this:

   +-------------------+
   | The  Menu  Bar    |
   +---+---+---+---+---+
   |   |   |   |   |   |
   |   |   |   |   |   |
   |   |   |   |   |   |
   +---+---+---+---+---+
   |   |   |   |   |   |
   |   |   |   |   |   |
   |   |   |   |   |   |
   +---+---+---+---+---+
   |   |   |   |   |   |
   |   |   |   |   |   |
   |   |   |   |   |   |
   +---+---+---+---+---+
   |   |   |   |   |   |
   |   |   |   |   |   |
   |   |   |   |   |   |
   +---+---+---+---+---+
   |   |   |   |   |   |
   |   |   |   |   |   |
   |   |   |   |   |   |
   +---+---+---+---+---+

and end up with a window that looks like this:

   +---------------------------+
   | The  Menu  Bar            | 
   +---+---+---+---+---+---+---+
   |   |   |   |   |   |   |   |
   |   |   |   |   |   |   |   |
   |   |   |   |   |   |   |   |
   +---+---+---+---+---+---+---+
   |   |   |   |   |   |   |   |
   |   |   |   |   |   |   |   |
   |   |   |   |   |   |   |   |
   +---+---+---+---+---+---+---+

which I find really strange.

-- Best Regards,

Neil

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 30 Jun 2002 12:30:30 +0200

On Sun, Jun 30, 2002 at 02:13:13AM -0230, Neil Zanella wrote:
> seeing some other things.

What exactly do you see?  Can you try to describe it in more
detail?

> whether the limitation lies in the X event reporting system.

Neither.  It's a qt problem.  Fvwm *does* react to changes in the
base size, but the application can't seriously expect that this is
done while the window is being resized.  That might explain why
the size is screwed up too.  The events changing the base size are
queued up and processed when the user stops resizing.  Qt should
really just try to cope with the given size of the frame and not
try to override the size that the user chose.  Qt bug.

> the window when it looks like this:

Ah yes.  That's probably a problem in the X servers event
handling.  When the button is released, the X server should report
the position of the pointer at that time.  But if you're really
fast, it sometimes reports a wrong location (that lags behind the
actual position).  I've once reported this to the XFree folks but
never got an answer.

Both problems should get worse the longer a single resize step
takes.  That's probably the explanation why you don't see it with
the other WMs:  fvwm does a lot of things in the resize loop that
take considerable more time than what other window managers do.

Bye

Dominik ^_^  ^_^