Created attachment 66238 [details] [review]
Preliminary revision of resizing of window

The patch combines the patches that I attached to bug 324426 and bug 95316. It also changes how resizing is done in terminal-window.c and removes some unnecessary coupling from terminal-screen.c.

With this patch, the window will resize itself when the underlying vbox emits a resize-request signal. It keeps track of the previous vbox size request (in the future, this value should probably be grabbed from the window, but there are problems with this, see gtk_window_get_size in the API) to remove unnecessary window resizes.

This seems to work very well. It cleans up the code by removing unsimilar parts of code and does a single window resize on every event that I tested (tab bar, scroll bar, and menubar addition and removal).

I feel that the code could still be cleaned slightly further, but this is a pretty good start.

Thanks.  I'll look into it.  I've not tested it yet but does it force the temrinal size to be a grid still?

Created attachment 66241 [details] [review]
Same patch with removal of g_fprintf and renaming of update_geometry

So in the last patch I forgot to remove a debugging g_fprintf that I was using. Also, I renamed terminal_window_update_geometry to update_geometry because it is now static and most static functions do not have the terminal_window prefix (I assumed that the static functions that do have the terminal_window prefix have it because they use to not be static).

> (I assumed that the static functions that do have the terminal_window prefix
> have it because they use to not be static).

Not quite.  Static methods with terminal_window_ prefix can be best thought of private methods of TerminalWindow objects, while other static functions typically are not (are convenience, etc.)

It does not "force" anything. It allows the gtk_vbox container to tell it what size it wants, and then makes the window the same size. Since the gtk_vbox container contains the TerminalNotebook that contains a gtk_hbox that contains the TerminalScreen, and the TerminalScreen always requests a size that falls on a grid boundry (it knows what grid size it wants), then the window will never force a non-grid size.

Now, there may be an exception (that I realized right now). In the case that the requested size cannot fit on the screen, then this might fall apart. However, since we provide hints to the screen size we want (which knows about our grid), then this probably still would not cause a problem.

But it was correct to update_geometry as such? I only see the init, class_init, finalize, destroy, and show being a static method and having the terminal_window prefix. The one that I think just didn't get its name changed is the terminal_window_show function.

Doesn't really matter.  I was talking generally.  In this case, just follow what the rest of code does (which is what you did I guess.)

I no longer see any further problems with the resize code after my patch. So as far as I am concerned it really isn't "preliminary."

I just changed the previous patch to your one and I can't see any problems either after a short stress test. I'll keep on using g-t with this patch for my everyday work and tell you if I face any side effects.

I found a bug...
Press Ctrl+Shift+T twice to have three tabs (the right one is the active, probably start an "mc" here) and then close the middle tab using its X button on the tab (without making it active). The terminal size shrinks a little bit, though it shouldn't do. This causes the application running here (e.g. mc) to resize to one less rows and one less columns, but a huge background-color border remains at the right side and below the bottom of mc. Switching to the other tab removes this extra space (but still the size is 1x1 smaller than it should be).

I guess this would be a good time to note that there is a race condition. The race condition exists without my patch, so there is no regression. I have been unable to understand the documentation on how to circumvent the problem (Note 1 in the API for gtk_window_get_size).

To reproduce it, open a terminal and add a tab. Set one of the tabs to be different in size in some way (scrollbar, fontsize, etc). Hold down alt then press 1 and 2 at the same time (you want to swap to the other tab, then back almost at the same time). The window should have grown or shrunk (may take a few tries).

I find the bug to be minor, but you may disagree. More GNOME applications do suffer from the same bug (e.g., Totem).

It helps to get a final patch by weekend, so we can commit it and push into the GNOME 2.15.4 devel release next week.

I can reproduce this race condition if I'm fast with pressing Alt+1 and Alt+2, but this bug does not occur if I'm slowly, comfortably waiting for g-t to finish the resize operation before pressing any key again. This is really a minor bug, I agree.

In my previous comment, however, I can't see the "race" part: you don't have to be fast to see that bug. This can easily occur during average usage. (I also faced this when closing the active tab, but I can't reproduce it right now.)

Okay, here is one possible way to reproduce it (with an arbitrary amount of waiting between the steps):
- launch g-t
- start mc inside it
- open a second tab (Ctrl-Alt-T)
- open a third tab (same keys)
- go to the middle tab (Alt-2)
- exit here (Ctrl-D)
- g-t switches to the 1st tab where mc becomes smaller with an ugly large border.

(btw I'm using gnome-2.14.2, hence vte-0.12.2 and g-t-2.14.2.)

I am able to reproduce resize bug. I will look at it and try to figure out why it happens.

I was not meaning that your bug was a race condition, I just happened to be posting at the same time.

Oh, I see :-))

I found the bug. It is on line 1741 of terminal-window.c:

  /* Called from terminal_notebook_move_tab() */
  if (find_screen (window, screen) != NULL) {
    g_assert (terminal_screen_get_window (screen) == window);
  
    window->priv->terms = g_list_remove (window->priv->terms, screen);
    terminal_screen_set_window (screen, NULL);
  }

When I comment out this block, the bug is gone. The terminal_screen_set_window is what is probably messing it up. I will look into this and see if terminal_screen_set_window is needed.

I was wrong about that block of code. What actually happened was I was moving too fast. I must wait for the terminal to completely load before changing to the second tab. If I remain on the third tab or change to the first tab, the bug does not occur. If I make four tabs, then only the second tab causes the bug to occur (then also the third tab once it becomes the second tab because the second tab closed). So it looks like there is a bug with only the second tab!

Yes, I didn't realize it, but you're right: it's always the second tab that has something wrong with it.
But if you reorder the tabs (with drag-n-drop) then it's not the new second that will trigger the bug, it is the one that was originally created as the second. So the bug seems to be somewhere at tab creation, not at tab removal. Perhaps some field telling the size of this tab is not initialized correctly, it doesn't take the few extra pixels caused by the notebook widget in account. (Just a guess without any knowledge about the code.)

Created attachment 68640 [details] [review]
Incremental cleanup

This patch cleans up a few more things in the resize code (some introduced by my previous patch). It requires my previous patch.

Well, the bug goes further. One tab is always the broken tab. It starts as the second tab. After you remove that tab, when you add a new tab, the new tab is broken, however, only if you remove the second tab. That type of behavior is repeatable with the new broken tab.

I have discovered that my resize code is not being called. I cannot find any other resize code, so I have no idea why it is being resized.

Egmont, I already had looked into your theory. The notebook is still requesting the correct size when the window is incorrectly being resized, so this is probably not the problem.

Created attachment 68641 [details] [review]
Workaround: force-fix

This workaround "fixes" the bug. It does a resize on every re-size request. I cannot predict when the bug is going to happen, so this workaround works as if the bug will happen every time.

Created attachment 68642 [details] [review]
Workaround: diagnostic-fix

This workaround also "fixes" the bug. This one realizes when the bug occured, but only after it resized the window. This workaround thus suffers from the window being resized (when the bug occurs) twice and is visible to the user. As opposed to the previous workaround, this workaround does not resize needlessly.

Both of these workarounds are mainly intended for other people to pick up where I left off. I am unsure if I will be able to fix this bug, I just am out of ideas on where the bug is located (or where the resize occurs even).

> This workaround thus suffers from the window being resized (when the bug occurs) twice and is visible to the user.

I haven't tested your new patches (will do tomorrow) but this sounds quite bad. See bug 336325 for a similar case. In addition to the visual flickers, some applications (e.g. mc) fail to resize themselves correctly if they receive two window size change events in a short time. So you may end up having a g-t with the correct size, but mc inside it is not okay. Sure it's a bug in mc and all these kind of applications, but on the other hand, a terminal emulator should not send superfluous resize events.

Anyone working on this bug?

I'll probably take a look at it if time permits. And I hope Eric didn't give up either :-) Eric's patch in comment 3 is nearly perfect except for the second tab. I'd try to catch what's wrong with the second tab, instead of creating workarounds that probably introduce other side effects. Unfortunately I don't know when I'll have time to do it, and I have no experience at all in gtk+ programming.

Still playing without your recent patches, only with the patch from comment 3.
An additional piece of information, which I've just discovered and might help catching the real cause of the bug: when g-t behaves buggy (after the removal of the 2nd tab, when there's an extra border), the actual terminal size and the size reported by metacity differ. For example if I work with the standard 80x24 size, open two tabs and close the middle one, the size of the vte widget shrinks to 79x23 (as also reported by "stty size"), but if I grab the corner of the window, metacity says its size is 82x27. I can resize the window now, this constant offset remains as well as the extra border. When I switch tabs, the border disappears, and so does this size offset.

There's another bug I've just found. This might be completely irrelevant to those discussed above, I don't know. Have two tabs, mc running in the left one. Play the following: switch to the right tab, enlarge the window, switch back to the left one. You see mc resizing correctly there. Now switch to the right tab, enlarge it, and then close it. mc's screen will not be okay. If you run "trap 'stty size' winch" instead of "mc", you see that exactly one resize event is sent, so it is fine. I logged mc's output (using the "script" utility) in the two cases and it's exactly the same (if mc's hints are disabled). I guess the problem might be that mc receives sigwinch earlier than vte is actually fully resized to the new larger size. (It's strange however that there seems to be no problem if the number or rows remains the same or gets smaller during the resize.)

Now I applied your "Incremental cleanup" and "Workaround: force-fix", they seem to be okay, the "second tab" bug is gone.

A note to my previous mc resize bugreport: it also occurs very often (not always) if you drag-n-drop a tab running mc into a larger g-t.

> Now I applied your "Incremental cleanup" and "Workaround: force-fix", they
> seem to be okay, the "second tab" bug is gone.
Oh, they're not okay, a new bug introduced: launch mc, resize the window, change directory or go to the other panel in mc => the window is automatically resized to its old size. Brrrrr... :-)

I found another such bug: Open up gt, make a new tab, resize the tab, click down on the closing 'x' for the tab, notice the window is resized before the mouse is even lifted up.

I had been wondering if these bugs may be caused by GtkNotebook, and this one almost has to be (right?). This bug is pretty similar to the last bug Egmont found. I will look into them and see what I can find out.

Another bug introduced by this patch: the size specified by --geometry is ignored. Launch "gnome-terminal --geometry=132x40+50+50". The upper left corner is at (50,50), but the size is 80x24.

Created attachment 71028 [details] [review]
Incremental bug fix, cleanup, and partial workaround

This patch applies after the "Incremental cleanup" patch (so without the workaround patches).

The patch fixes all the currently known bugs. The problem seems like it is in vte-terminal (although previous posts make it obvious that I am probably wrong). I added gtk_widget_queue_resize_no_redraw at particular places and it fixed the problems. This is not the correct fix. I will need to find out what part of gtk_widget_queue_resize_no_redraw is causing everything to work correctly so that I can fix the buggy code "the right way."

The bug with --geometry was just resizing after the default size was set. I now do not resize if the window is not yet mapped.

The patch amplifies a bug when resizing the window to smaller than the command prompt (i.e., smaller than "user@host ~/folder/sub folder/folder again/") so that the prompt it is forced to wrap. I hope to see this problem disappear once I replace gtk_widget_queue_resize_no_redraw.

The patch also includes minor code cleanup.

Can you attach a single patch against current HEAD?

Now I have vte-0.12.2 and g-t-2.14.2 with the patches from comments 3, 20 and 31.

Removing the second tab is still not okay: the remaining tabs are resized to one less row and one less column. But at least they're now correctly resized to grid positions (no black border, no different sizes reported by stty and metacity).

The other bugs seem to be resolved.

Just a side note: I tried xfce-terminal (which is based on vte, too). If you have multiple tabs and resize the window, xfce-t immediately sends the resize events the all the tabs, as opposed to g-t, which only sends it when switching to that tab. I don't know but probably xfce-t's approach might be simpler to cleanly implement. Both approaches have pros and cons anyways...

Sorry for me not being as quick with replies, I have been quite busy.

I have not yet done the patch against HEAD yet. Part of the reason was that I didn't have all the dependencies. I now have those, but have not had a spare moment.

I confirm that the one bug still exists... That is kinda disheartening. I completely wish I knew where that weird bug is.

I think that the xfce-terminal approach may be better, not because of implementation, but because vte will know the new terminal size sooner. Of course, it would also increase the cpu cost of resizing. I think that such a thing would be a separate feature request though, because it is changing the current behavior.

I have worked on trying to improve this window resizing code more then I originally intended. The other patches that fix the current resizing code seem to be working, and working well. Is it still adventagous for me to continue with this patch? If the gnome-terminal team would like to see this patch in their code base, then I would be happy to continue.

Even with this "second tab" bug, gnome-terminal is much better with this patchset than without it, so I recommend applying them. (Okay, I know, they should be ported to HEAD. I'm stuck with 2.14 too and I don't think I'll upgrade in the near future.) Then it'll be easier for others to join us and try to catch this remaining bug.

In the last few weeks I learnt some Gtk+ programming (though mostly using Glade and perl-gtk), and, amongst others, I successfully created a simple terminal application around the vte widget, including window size constraints. So at least now I feel that perhaps I might catch the resize bug. I'll try to.

Created attachment 73161 [details] [review]
fix when the second tab is removed

Got it :-)

When the 2nd tab is opened, the size_request_callback function is fully executed since the size of the vbox has changed. This causes the window geometry hints to be updated. So far it was the first (and only) vte widget providing the geometry hints, now it becomes the second one.

When subsequent tabs are opened, the size_request_callback function exits immediately since the new size is the same as the old one. Hence it doesn't call update_geometry_hints, so it is still the 2nd vte that provides the geometry hints, not the active (new) one.

And then when the 2nd tab is removed, somehow the geometry hints become invalid, or I don't know what exactly happens but it's clear that it's not okay.

My patch simply lets size_request_callback always call update_geometry so that window geometry hints are always updated at tab switch; it is always the active tab that provides the size hints.

So currently, according to my best knowledge and experiences, the best solution for the resize problems is to apply the patches from comments 3, 20, 31 and 36 on top of each other.

The bad news is that I just realized that the bug in the 2nd part of comment #26 is not yet solved, but that one is perhaps unrelated to these problems, so let's apply these patches, close this bug and then I'll open a new one for that.

Mariano, care to share your findings with us?   This bug is ridiculous and I prefer not to commit anything until we fully understand the problem and correctly solve it.

Egmont, I am ever so greatful that you are looking at this too. I will look into your post a little closer a little later when I have time.

If you look at attachment 68641 [details] [review] ("Workaround: force fix") you will see that I discovered the same solution as your patch. However, that solution I do not consider adequate (because the current code in gt is more efficient).

Behdad, I completely agree. This is not that should be commited.

Oh yes, it's really the same patch :-) At that time I tried it and it wasn't okay, see comment #28, so I reverted it and never tried again, though as we see now, together with the patch from comment #30 it's behaving correctly.

Another difference is that at that time I didn't understand hardly anything about the code, just applied the patches. Now I have a rough understanding of what's going on, and as I see this is not a workaround, this is the proper fix for the problem (for the "2.14 plus your patches" codebase), since the whole window's geometry shouldn't be based on a widget that disappears, it should always be updated to be based on the active vte. (Okay, we might have a much more complicated source in the hope of some negligible performance gain that only alters the geometry widget when it is about to be destroyed... I don't think it's worth it.)

The most important part is, however, that now I understand what exactly made the second tab behave differently than the other tabs.

Eric and Behdad, I do not agree with you. The current patchset may not be (and most likely is not) 100% perfect, but is much better than g-t without the patches. Commiting these doesn't mean that no further improvement can be made. Actually, I believe that commiting these could help fix the remaining problems (if any) and performance issues more efficiently, perhaps involving even more developer resources. And after all, a lot of people will have a better g-t sooner. It's absolutely okay if we don't fix all the resizing bugs in one step, just most of them, and continue later.

More info about the bug described in comment #26, second paragraph.

The detailed description there wasn't perfect, or the behavior has changed since then due to some new patches. The current behavior (using g-t 2.14.2 with the patches from comments 3, 20, 31 and 36) is the following:

1.) Open g-t, type >> trap 'stty size' winch << in your bash. Create a new tab. Resize the window several times. Go back to the first page, you'll see plenty of resize events here.

2.) Open g-t, type >> trap 'stty size' winch << in your bash. Create a new tab. Switch back to the 1st tab, then again back to the 2nd one. Resize the window several times. Go back to the first page, you'll see only one resize event here.

See comment #33 where I mention the different resize policy of g-t and xfce-terminal. It seems that g-t is mixing the two methods. For some strange reason in case 1 it always immediately resizes the invisible 1st vte, but in case 2 it only resizes it when it's activated. This inconsistency is definitely a bug. The question is which policy g-t should follow.

At this moment I vote for the opposite of xfce-t, that is, to only update the geometry when the page is activated. One of my reasons is that most likely this is what g-t currently wants to do, and hence case 1 above is the buggy one, not case 2. (It's probably easier to fix a bug than to leave it and fix what's not a bug :-)) Another reason is to work around mc's stupid behavior that it's unable to properly handle if it receives more resize events right after each other. This happens at nearly every resize (provided that the window manager does opaque resize, which is usually the default nowadays). You can easily face this if you don't use tabs at all, just a simple vte running mc, and resize it several times.

I'll try to catch this bug, too.

Created attachment 73234 [details] [review]
consistent resize behavior, as well as fix for tabs with different font sizes

It's gonna be a loooong comment again, sorry for that :-))

First of all I have to admit I was wrong when I said g-t resizes when switching to the desired TAB. It was how my g-t with Eric's patches worked. Mainstream g-t immediately resizes the contents of each tab, just as xfce-t.

Second, I have to tell what I hate the most in g-t: the ability to have multiple tabs with different font size or different scrollbar visibility. It might be useful to end users, but it's a nightmare for developers.

Notebook widgets normally cannot be shrinked smaller than any of the pages it contains. However, this time we want to implement something completely different using notebook: we'd like to see the whole window resizing when changing tabs.

I have no clue how the original g-t code is supposed to overcome this problem, since I haven't studied its code. All that I see is that it always "shows" (in widget terminology) all its pages, never "hides" any of them. That's why they always immediately receive notification of size changes. (Maybe it changes the font and scrollbar properties of the not active vtes? Does someone know the answer?)

Eric changed the whole concept to an (according to my really small Gtk knowledge) cleaner solution. He hides all the pages, except for the active one. When another tab is selected, the old vte widget gets hidden and the new one gets shown. This way the desired size of the whole notebook will be what the currently active vte suggests, even if other pages use different font size.

As a side effect, vte widgets only receive notification of window resizement when they are shown again, hidden widgets don't receive such events.

The bug is the following. When manually switching tab, notebook_page_selected_callback() is called, which takes care of hiding-showing if the new terminal widget is not the same as the old one, and it also calls terminal_window_set_active() which sets the active page to the new one. However, when a new page is created, terminal_app_new_terminal() calls terminal_window_set_active(), this already sets the active vte to the new one, and then later when notebook_page_selected_callback() is called, it believes that the old and the new widgets are the same, there's nothing to hide or show. In other words: when you create the second page, the first one remains "shown" in Gtk's sense. Then when you switch back to the 1st tab, and to the 2nd one again, this time the invisible vte pages are hidden in Gtk's sense.

This perfectly explains the resize behavior described in my previous post. It also describes the following bug which I've just discovered (and my patch fixes this too, though I can't see why): if you open a new tab and there switch to another profile with a smaller font, the terminal's pixel size remains the same, so the terminal rows*cols size grows. However, if you first switch to the 1st tab and back to the 2nd, and change the profile now, then the window resizes so that the terminal remains at the same rows*cols.

In the patch I simply moved the hiding-showing code to terminal_window_set_active() and seems to be okay. To summarize: a hide() call that was supposed to be called always wasn't unfortunately called in one particular situation, at new page creation.

The patch (or actually the current patched code) should need some further testing whether other special scenarios (drag-n-drop between more terminal windows etc.) are handled correctly...

"I can't see why" revoked, it's trivial :-) It's the other (inactive, but accidentally not hidden) page that didn't let the whole window shrink to the smaller desired size.

To summarize where we are:

I have g-t 2.14.2 plus the patches from comments 3, 20, 31, 36 and 41 on the top of each other. (They apply cleanly, without even any offset or fuzziness.)

Currently there's no resizing bug or inconsistency known to be, but, oh, I know, this doesn't mean too much :-)) I'll keep on using this version and tell you if anything is wrong. (I have usually 10-20 g-t windows around during my everyday work, but I seldom use tabs, and nearly never use drag-and-drop to move tabs.)

By the way these five patches changed the resize behavior of inactive tabs. So far they all immediately received all the resize events. Now they only receive one single resize event when they become active again (and receive no event at all if the window was reverted to the same size while this page was inactive). You may or may not prefer this new behaviour.

Created attachment 73241 [details] [review]
All relevent previous patches against HEAD

Okay, I finally did it. I combined all the patches so far and made it against HEAD. I still do not like removal of the optimization that the "Force-fix" patch did, but gt does work now.

Gosh, we're still not there. I wonder why it took a whole week for me to notice this.

Things go wrong if you resize g-t to be narrower than the menubar.

If you move the right edge to the left quickly and release it when the terminal no longer shrinks, it often "hits back" (the window is resized to the size where the menubar just fits there). If you move the left edge to the right, the whole window will start moving to the right.

If you resize slowly, you'll also notice that when you reach the critical width, metacity starts reporting that the width is decreased by 2 columns each time you shrink it by one. And then metacity no longer allows the window to be shrinked when the width reported by it reaches 4; at this time the terminal contains approx. 10-15 columns (it depends on the relative width of the menubar and a character cell).

Similar phenomenon, I think it's caused by the same bug and probably we're getting closer to the bug itself. Apply only the patch from comment 3.

Make the window narrower than the menubar, click on the menu, and move the mouse horizontally on the "File" "Edit" "View" etc. menus. Suddenly the window will resize so that the full menu fits in there. The applicaton within the terminal properly receives the size change event, but somehow metacity isn't notified, it still reports the old width (which is a smaller number than the new one) and keeps this offset when resizing the window. Actually the size of the vte is not even a "normal" size that could be reachable by resizing the window; it has a black gap on its right side.

Note that I could only reproduce this auto-resizing bug once per each gnome-terminal process.

So this bug is introduced by the patch from comment 3 (this is basically your first patch here), though subsequent patches caused slightly different (even stranger) symptoms.

Created attachment 74159 [details] [review]
fix for the recent problem

The bug is caused by the one-line patch from 1st comment of bug 336325, which was then applied to HEAD. So most likely mainstream g-t-2.16 suffers from this problem as well. Someone having a Gnome 2.16 around please try it.

Eric's patches remove that whole function that contains this small modification, so there's nowhere to reverse apply it there, and actually we don't want to bring back the ugly and buggy workaround that this patch dropped.

See the patch I attach now. It seems to fix this problem both with 2.14.2 + the above mentioned one-liner, and with 2.14.2 + Eric's patches. It also applies to the newest stable 2.16.1, but I can't test it right now due to plenty of missing Gnome 2.16 dependencies.

I'm not sure if this is the right way to solve these problems, actually the whole story how a widget's size is calculated is a bit unclear to me. I just discovered it's the natural width of the menubar where bugs arise, so I asked the menubar to be 0 pixel wide. Since it doesn't fit there, it grows to the desired size if there's room for it inside the window, but it no longer tries to force this size.

I can confirm the bug for this patch set. I was not able to reproduce it for Gentoo's gt-2.16.0. I am okay with the patch and confirm that it fixes the problem. It assumes that we want to allow the user to make the window smaller than the menubar. Is this a good assumption? Using the arrow keys to get to the menus off the window provides interesting results.

Egmont, are "fix when the second tab is removed" and "consistent resize behavior, as well as fix for tabs with different font sizes" patches still needed? I thought that I included everything needed in my "All relevent previous patches against HEAD". So can they be made obsolete?

Currently I'm using six smaller patches, those five that I've mentioned earlier plus this new one. (I even played those five numbers on the lottery last weekend but I didn't win :-)))). I haven't tried your big merged and updated patch (mosly because I don't have Gnome 2.16) but as I took a quick look at it (and checked it now again) it seems that you have merged them. So I think they're now obsolete.

The behavior when the menubar is wider than the terminal is now the same as it was before, and I see no reason to change it. Yes, it behaves strange if you use the arrow keys to access invisible menus, but it works right, and it's a Gtk feature anyway. Forcing the terminal to be at least ~30 characters wide (depending on font sizes, language...) wouldn't be a nice move IMHO.

Egmont, can you attach one single patch, without ‘cleanups’?

Currently there are only two active patches. You should ignore the obsolete ones.

"All relevent previous patches against HEAD" is the big patch (as its name says) that fixes nearly everything, merges all the previous patches that are now marked as obsolete. This patch might also contain some cleanups, but I think they are integrated part of the patch and could not be eliminated. I can't create another patch for two reasons. 1st: the major part of this patch is Eric's work and I can't see which hunks are the "cleanup" ones that are perhaps not needed (but no-one knows; if you modify anything, you can start testing from the beginning), and 2nd: I'm still stuck with Gnome 2.14 so even if I could modify the patch and apply it, I couldn't test whether it still works.

The other active patch, "fix for the recent problem" is a one-liner to fix yet another problem; as far as I know these two patches don't conflict, this one doesn't depend on the previous one.

So I doubt that eliminating cleanups is a good idea. Actually, anything believed to be a cleanup here might actually be a fix. (There was even a small hunk where Eric and I didn't agree. We both see it fixes the problem but he says it's a workaround, I say it's the proper fix...) And the current patchset (ported to 2.14) has already survived 2 weeks of intensive testing from me, without any defects -- I don't know how much it means.

Merging the 2 patches isn't necessary, it's easy to apply them separately (or just cat the two patch files into one bigger if you really need one patch :-)))

*** Bug 393413 has been marked as a duplicate of this bug. ***

Can we please escalate this bug to severity major, priority urgent?  g-t 2.16.1 is so unusable with tabs that I've now taken reluctant refuge in konsole (really).

It's clear from web searching that this is a real bug even though it's still unconfirmed here at bugzilla. The Sep 22 patch below does not appear to be  applied to svn 2.16 branch. There's no indication that this problem has been fixed anywhere and the lack of recent discussion on this bug suggests that it's been forgotten. Does this bug have an owner?

Chris- Behdad suggested that I cc you and that you'd probably know the state of this blight on g-t.

Thanks,
Reece

I try to increase prio/severity, I don't know if I can do it. I tend to agree that this is a quite important bug.

On the other hand, I keep using g-t with all these patches and usually I have 5-10 terminal windows open and often resize them (but I seldom use tabs), and they seem to work correctly. So these patches seem to be okay.

Reece, could you please apply these patches to your g-t? Your feedback would be appreciated. If everything's fine for you too then probably these patches would be committed sooner. If something's not okay, we could try to fix that, too.

This bug and set of patches is a "rewrite" of the current resizing code. I thought that all bugs with the current resizing code were fixed (I don't know what version of 2.16 the last bug was closed). That is probably why it appears that this is the "real" bug.

Bug 338913 is the only resize bug that I have looked at that is still open, and I reported that it was fixed with the same patch as another bug. The patch has since been committed.

Bug 393413 I have not yet looked at, but it seems that it may have been a duplicate of a different bug (not this one) that has been fixed. I will look into it, but I expect that it is fixed in a later revision of g-t.

Although this patch set seems to be now be semi-stable, the current code is more stable since all the patches have been applied.

Created attachment 80942 [details] [review]
one patch to bind them all, wrt to svn HEAD

This undoes the change done in bug 95316, and redoes it differently...

> Reece, could you please apply these patches...

I applied Mariano Suárez-Alvarez's patch (id=80942) to the head of the 2.16 branch. The patch applied with fuzz but without failure. I compiled these on an opensuse 10.2.  An initial run appears to work without tab resizing, but I'm unsure that I've got a reliable manual test procedure.  I'll use this for a few days and post again with confirmation. Thanks.

Follow-up from previous post: I've used Patch 80942 against SVN rev 2158 (2.16 branch) for a week and it seems to have solved all of the problems I was having.  Previous posters have alluded to outstanding problems with previous patches that I expected to exist in this all-in-one patch, but I haven't had any issues at all  Thank you.

Reece, can you try SVN HEAD both for gnome-terminal and vte? g-t HEAD does not include this patch, but vte has seen quite a bit of activity...

Can the people that have been seeing this resizing bugs let me know if they can still reproduce them with either gnome-terminal HEAD or 2.17.90, and vte 0.15.2?

Following the instructions I've been having resize problems with gnome-terminal version 2.16.1 (comes with SUSE 10.2).

Problem:
When creating new tabs and moving between tabs, gnome-terminal becomes bigger. Eventually it blows up larger than the screen size.

FIX - Patching results:
Problem solved with the following patch (must be applied to SVN):
http://bugzilla.gnome.org/show_bug.cgi?id=342968 ("one patch to bind them all" at the bottom)

Tip:
For people who don't know how to get the source and apply the patch and build it, you can follow the directions I layed out in http://bugzilla.gnome.org/show_bug.cgi?id=324426.

Thanks for the patch!

[edit: ignore the phrase "Following the instruction" at top of previous post -- don't know how it got there; sorry for the spam]

(In reply to comment #58)
> Reece, can you try SVN HEAD both for gnome-terminal and vte? g-t HEAD does not
> include this patch, but vte has seen quite a bit of activity...

Mariano-
Not sure if you got my email asking for clarification, but I turned my head 90 degrees and then better understood your intent.  I've been using g-t trunk (rev 2162) linked against vte trunk (1658) without any patches for about an hour. Looks good so far; I'll continue to use this version and whine here if I find problems.
-Reece

Having worked through each of the bug recipes using HEAD g-t/vte and failing miserably to reproduce any of the bugs, I ask everyone to double check whether the issues have already been resolved.

As for the "one patch to bind them all", the essential chunk of using gtk_widget_queue_resize_no_draw(vte_term) is already in vte. The other interesting chunk is the old_widget!=widget check before resizing [but without its gtk_widget_queue_resize_no_redraw] which may save a bit of work.

Indeed, the status of this bug is «We think it is fixed but we are waiting for confirmation» since 2.17.90...

Now I have gnome 2.20-beta1 (vte 0.16.8, gnome-terminal 2.18.1), and the bug mentioned in comment #44 is not fixed. Here it is again:

Drag one of the edges of gnome-terminal's window border and start moving it close to the opposite edge, so that you resize g-t to be either much narrower or much lower.

1) If you drag the bottom and move up, g-t window starts to stupidly flicker amongst heights of 2, 3 and 4 characters.

2) If you drag the top enge and move down, similar bug occurs, but slowly the whole g-t window is moving upwards in the mean time.

3) If you drag the right edge and move to the left, when you reach the right end of the "File Edit..." menu, suddenly the size reported by metacity goes out of sync (it is decreased by 2 each time the window gets narrower by 1 cell) and when the width reaches approx. 10 columns and you keep moving the mouse to the left, the window starts flickering amongst several different widths.

4) If you drag the left edge and move it to the right, you see a beautiful combination of (2) (rotated by 90 degrees) and (3).

A while back there were many window resize issues. This bug was opened in hopes to fix the window resizing problems all at once, and make it less prone to breaking in the future. However, window resizing issues are fixed at the moment. Since there is no need for it, nor activity to fix the remaining problems with the patch, I am closing the bug.

Removed "resize" alias in order to make quicksearch for bugs containing "resize" possible.