On Sun, Jun 30, 2002 at 02:13:13AM -0230, Neil Zanella wrote: > > Hi Dominik! > > Thank you for your reply... > > On Sun, 30 Jun 2002, Dominik Vogt wrote: > > > On Wed, Jun 26, 2002 at 11:10:34PM -0230, Neil Zanella wrote: > > > > > > 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 > > > > 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). > > > > > 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. > > > > Do you mean the effect that the interior of the window does not > > 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.
What exactly do you see? Can you try to describe it in more detail? > > It 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: > > > > A: > > > > +-------+ > > | The | > > | Menu | > > | Bar | > > +-+-+-+-+ > > | | | | | > > | | | | | > > | | | | | > > +-+-+-+-+ > > | | | | | > > | | | | | > > | | | | | > > +-+-+-+-+ > > +-+-+-+-+ > > > > instead of > > > > B: > > > > +-------+ > > | The | > > | Menu | > > | Bar | > > +-+-+-+-+ > > | | | | | > > | | | | | > > +-+-+-+-+ > > | | | | | > > | | | | | > > +-+-+-+-+ > > | | | | | > > | | | | | > > +-+-+-+-+ > > 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. 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. > 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. 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 ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
