After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 81059 - ugly resizing from left/top
ugly resizing from left/top
Status: RESOLVED NOTGNOME
Product: gtk+
Classification: Platform
Component: Widget: Other
2.0.x
Other Linux
: Low enhancement
: future
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2002-05-07 16:00 UTC by Akira TAGOH
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Akira TAGOH 2002-05-07 16:00:51 UTC
I received this report from Debian user:

Subject: Bug#145376: gtk2.0-examples: "Button Boxes" demo: ugly vertical
resizing
From: Laurent Bonnaud <Laurent.Bonnaud@inpg.fr>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Date: Wed, 01 May 2002 12:23:22 +0200

Hi,

in the gtk-demo "Button Boxes" demo, when I resize the window
vertically (with an "opaque resize" window manager), the motion of
buttons is not smooth at all.  


and:

Date: 02 May 2002 14:40:27 +0200


AT> First, you should indicate your machine spec, shouldn't you?

Athlon XP1600+, 256MB DDR-SDRAM, Radeon VE, so it *is* fast enough :>.

AT> You mean are you saying GTK+2.0 is heavy?

Not at all.  At least on this kind of machine.

I'm just observing a difference in behaviour between horizontal and
vertical resizing of this "Button Boxes":

 - horizontal resizing is very smooth

 - vertical resizing: buttons jump as if there were (temporary) errors
   in the buttons coordinates.
Comment 1 Owen Taylor 2002-05-07 16:45:30 UTC
My guess is that the difference is that resizing horizontally
is being done from the right while resizing vertically 
is being done from the top.

Try resizing horizontally from the left and you'll see the
same problems... the jumping comes from the window being
first moved, then resized, which means that right/bottom
aligned elements move then move back.

Trying to fix this requires cooperation from the window
manager, see:

http://mail.gnome.org/archives/wm-spec-list/1999-November/msg00088.html

And is really outside the scope of GTK+.
Comment 2 Laurent Bonnaud 2002-06-19 09:56:16 UTC
I confirm that Owen Taylor's analysis is right:

 - when I resize the window from the right or bottom border it is smooth
 - when I resize the window from the top or left border, it is jerky

Therefore I will reassign the Debian bug to kwin/kdebase...