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 543919 - window size changes don't always propagate
window size changes don't always propagate
Status: RESOLVED INVALID
Product: vte
Classification: Core
Component: general
0.16.x
Other All
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-07-20 22:24 UTC by Pierre Ossman
Modified: 2014-04-22 16:56 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Pierre Ossman 2008-07-20 22:24:59 UTC
Please describe the problem:
Some somewhat recent update to vte has caused it to mishandle window size alterations. The widget properly resizes and handles drawing properly, but it fails to send the proper signals to the software at the other end of the pty. The end result is that programs such as "less" send updates as if they are on a 80x24 terminal, when the terminal is 200x60. This of course causes major usability problems.

The problem is intermittent. If the problem appears, trying the resize a few more times eventually gets things synced up at the other end.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Tony Houghton 2010-12-04 17:09:09 UTC
The problem is more serious than that. GtkNotebook sometimes causes unwanted window resizes when adding and removing tabs and vte simply can't deal with them, changing its column_count and row_count to values that bear no relation either to the previous size or the new size. For example if I start with an 80x40 window and adding a tab in roxterm reduces the width slightly, instead of the geometry updating to 79x40 it changes to 57x40. Or if I alter roxterm's code slightly to try to restore the previous size instead of updating the geometry to the new one it decides it wants to be 165x60.

Other vte apps don't seem to be as badly affected as roxterm, but I have been told that they're all affected by resizing bugs to some degree.

But roxterm, for whatever reason, is severely affected, and I can't fix it. I have a choice between abandoning the project altogether, rewriting it almost from scratch and hoping that it might behave a bit better with multiple tabs, or getting rid of multitab support which will also require a major rewrite if I don't want to leave it burdened with masses of disused/slightly inappropriate code.

Is there a way to change the severity of a GNOME bug?
Comment 2 Christian Persch 2010-12-04 17:29:20 UTC
Have you tested this with gtk3 and a gtk3 build of vte master ? There have been lots of geometry handling fixes there.
Comment 3 Tony Houghton 2010-12-04 18:25:35 UTC
No.

I have found a way to prevent the unwanted resizing from GtkNotebook though, so roxterm is now at least fit for purpose if still rather flawed (more details at bug #636470) and I'm not so concerned about this problem.
Comment 4 Christian Persch 2014-04-22 16:56:27 UTC
Doesn't look like this affects gtk3, so closing. If you can repro on a gtk3 build with vte master, please reopen.