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 316087 - Resizing columns is chaotic
Resizing columns is chaotic
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
2.8.x
Other All
: Normal normal
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
: 318934 321942 336082 341539 342407 344567 350151 393035 457868 (view as bug list)
Depends on:
Blocks: 393035
 
 
Reported: 2005-09-12 14:25 UTC by gcocatre
Modified: 2011-02-04 16:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test file test.c (14.04 KB, text/x-csrc)
2006-03-08 09:29 UTC, Nickolay V. Shmyrev
  Details
Suggested patch (3.43 KB, patch)
2006-03-08 09:31 UTC, Nickolay V. Shmyrev
none Details | Review
just some try-out (1.31 KB, patch)
2006-09-26 23:20 UTC, Kristian Rietveld
needs-work Details | Review
better patch (4.65 KB, patch)
2007-02-16 18:39 UTC, Kristian Rietveld
none Details | Review
Kristian's patch + scrollbar fix (4.97 KB, patch)
2007-05-18 19:07 UTC, Josselin Mouette
none Details | Review
column-resizing.py (960 bytes, text/plain)
2007-06-06 16:09 UTC, Johan (not receiving bugmail) Dahlin
  Details
updated patch (8.23 KB, patch)
2007-10-04 12:20 UTC, Kristian Rietveld
none Details | Review
Patch for GTK+ 2.12.1 with content resizing fix (8.68 KB, patch)
2007-11-01 12:49 UTC, Josselin Mouette
none Details | Review
Patch for GTK+ 2.12 and more fixes (9.02 KB, patch)
2007-11-15 20:41 UTC, Josselin Mouette
none Details | Review
updated patch (18.38 KB, patch)
2008-07-10 16:19 UTC, Kristian Rietveld
committed Details | Review

Description gcocatre 2005-09-12 14:25:03 UTC
Please describe the problem:
Resizing columns of a GtkTreeView element doesn't match the mouse's actions.
Say I have two columns, A and B. If I drag the colum border between them, just a
pixel or two in any direction, column A will get larger by a lot (50, 100
pixels, depending on setup). If I drag it to the left, and keep dragging, column
A will first get much larger, then eventually shrink back to its original width.

Steps to reproduce:
1. Launch an application with a GtkTreeView component (rhythmbox for instance)
2. try resizing a column
3. drag the mouse to the left or the right while holding the mouse button


Actual results:
Columns don't get resized in a logical way.

Expected results:
dragging the border widget between two columns should do just that: move the
border to the left or right, matching the mouse's movements precisely, with a
1:1 pixel ratio (the border gets moved by one pixel when the mouse cursor moves
by one pixel).

Does this happen every time?
yes

Other information:
This problem has been there for as long as I can remember.
Comment 1 Matthias Clasen 2005-09-13 18:05:15 UTC
Most likely an application problem. 
Although they could be running into missing treeview features. 
Comment 2 gcocatre 2005-09-15 17:35:21 UTC
No, I'm talking about the behavior of columns that have the "expand" attribute
enabled. Use gtk+-2.8.3/tests/testtreeview to reproduce. Select "expand" and 
"resizable" for all columns (by clicking on their headers), and try to resize
any column. Watch the described behavior.
Comment 3 Matthias Clasen 2005-09-19 18:45:15 UTC
Yes, the behaviour is not ideal.
Comment 4 Kristian Rietveld 2005-09-20 15:00:07 UTC
It does not look nice, but it is not exactly trivial to fix; if there even is a
nice way of fixing it.  The behaviour seen here is exactly how expand=TRUE
columns get their widths allocated; each expand=TRUE column is given an equal
amount of the extra space.
Comment 5 gcocatre 2005-09-21 02:12:12 UTC
It not only doesn't look good, it makes resizing columns excessively difficult
for something that should be trivial to do (from a user's stand point).

The way I see it, columns with expand=TRUE should be sized on "start-up" the way
they are now (i.e., automatically sized). But when the user drags a border, only
the two columns sharing that border should have their width modified, and the
border dragging movement should have a direct, linear correlation with the
columns' width modifications: moving the border to the right by 5 pixels would
increase the left column by just as much (5 pixels) and the column to the right
would have its width reduced by the same amount (5 pixels). All other columns
should remain untouched.
Comment 6 James "Doc" Livingston 2005-09-21 06:40:49 UTC
A column being resizable and having expand=TRUE are two seperate things.

Something else that also needs to be considered in your example is when the
column to the right (which you suggest should shrink by 5 pixels) has a fixed
width. Also, what if every column to the right of the one being resized has a
fixed width?
Comment 7 gcocatre 2005-09-21 16:00:12 UTC
Then the first column to the right without fixed width should be altered. If
there is none, then the border shouldn't be allowed to be dragged to the right
(it wouldn't move to the right despite the user dragging it in that direction).
Comment 8 gcocatre 2005-10-05 07:14:44 UTC
Could someone at least confirm the bug?
Comment 9 James "Doc" Livingston 2005-11-21 02:52:21 UTC
*** Bug 321942 has been marked as a duplicate of this bug. ***
Comment 10 Chris Lord 2006-02-08 02:12:34 UTC
Has there been any progress on this?
Comment 11 Kristian Rietveld 2006-02-08 13:41:51 UTC
Not yet, fixing the more critical bugs first.
Comment 12 Joe Wreschnig 2006-03-06 20:06:44 UTC
Is this the same as #318934? It looks like it, and there's a patch there.
Comment 13 Nickolay V. Shmyrev 2006-03-08 09:28:17 UTC
*** Bug 318934 has been marked as a duplicate of this bug. ***
Comment 14 Nickolay V. Shmyrev 2006-03-08 09:29:30 UTC
Created attachment 60894 [details]
test file test.c
Comment 15 Nickolay V. Shmyrev 2006-03-08 09:31:11 UTC
Created attachment 60895 [details] [review]
Suggested patch

This patch at least solves column size jump problem, making the behavior more natural
Comment 16 Alex Lancaster 2006-03-26 16:48:22 UTC
*** Bug 336082 has been marked as a duplicate of this bug. ***
Comment 17 Alex Lancaster 2006-03-26 16:50:40 UTC
Confirming bug.  Could a gtk developer take a look at this?  Judging by the number of duplicate bug reports, it's certainly tripping up many users (especially in rhythmbox).
Comment 18 Alex Lancaster 2006-05-12 13:39:21 UTC
*** Bug 341539 has been marked as a duplicate of this bug. ***
Comment 19 Alex Lancaster 2006-05-12 13:43:51 UTC
Any progress on this?  It really trips up almost all rhythmbox users at some point and have had to file many bugs as duplicates of this one.  Can somebody at least take a look at the patch?
Comment 20 James "Doc" Livingston 2006-05-20 13:20:25 UTC
*** Bug 342407 has been marked as a duplicate of this bug. ***
Comment 21 Jonathan Matthew 2006-06-11 23:09:38 UTC
*** Bug 344567 has been marked as a duplicate of this bug. ***
Comment 22 Matthias Clasen 2006-07-17 02:31:02 UTC
Kris, any hope to get to this for 2.10.1 ?
Comment 23 James "Doc" Livingston 2006-08-06 13:33:03 UTC
*** Bug 350151 has been marked as a duplicate of this bug. ***
Comment 24 Chris Rose 2006-08-08 10:36:50 UTC
This bug needs some loving :)

It has come up again on the rhythmbox-devel mailing list, this time with a video attachment so it can be seen exactly the peculiar behaviour.

http://mail.gnome.org/archives/rhythmbox-devel/2006-August/msg00021.html
Comment 25 Kristian Rietveld 2006-09-24 20:50:58 UTC
I had a look at the patch and tried it out; but it doesn't seem to work right.  In my testcase (modified testtreeview with 1 or 2 expandable columns) the behaviour is still wrong/weird with 2 expandable columns.  With 1 expandable column you can already notice that the expandable column seems to have a minimum width, which wasn't explicitly set.

I will try to spend more time on this problem this week and hope to have it resolved soon.  I am thinking of looking for a solution by ignoring the expandable property once the column is resized; prolly need to give that some more thought in the train tomorrow.

Comment 26 Kristian Rietveld 2006-09-26 23:20:17 UTC
Created attachment 73471 [details] [review]
just some try-out

Okay, my current idea (dirty and quickly implemented by this diff) is to set the resized_width of all expandable columns to their current width (ie width + extra) and set the expand property to FALSE (maybe we should only do this when an expandable column is resized).

If the user ever changes the size of an expandable column, we shouldn't continue adding extra space because that will cause the column to have a different width than the user explicitly "told" the column.  If we don't set expand on the other columns to FALSE, we still have a weird resizing behaviour (ie the other columns  expand=TRUE will get more extra space) -- so we set the resized_width of those columns to their current values and disable expand.

At a first sight this seems to work well.  A problem might be that the columns who used to expand don't anymore after one resizing operation; also they might be much wider than required.  I'm not sure if this is a big problem, I am not seeing a different solution at this moment anyway.


Any opinions, suggestions?  (the patch should apply to 2.10 or head without issues for those who want to try out).
Comment 27 Nickolay V. Shmyrev 2006-09-27 04:23:28 UTC
> A problem might be that the columns who used to expand don't anymore after one 
resizing operation; also they might be much wider than required.

Isn't it better to look how other toolkits do resizing?
Comment 28 Kristian Rietveld 2006-09-27 09:18:57 UTC
(In reply to comment #27)
> Isn't it better to look how other toolkits do resizing?


Oh, that's actually a really good idea :)  I will look into that soon.
 

Comment 29 John Bryant 2006-12-28 05:38:48 UTC
It seems that column expansion is only used to find a good initial size.  If expansion is turned off after the columns have been created, that should fix the problem.  Resizing the view will not change the column width, but one could assume the user has set them a certain way and doesn't want them changed.

I'm working on a patch, and hope to have it ready soon.  Eventually the column widths should probably be saved somewhere, but I'll leave that to someone more experienced.  This is my first patch.
Comment 30 Kristian Rietveld 2006-12-28 11:39:08 UTC
(In reply to comment #29)
> It seems that column expansion is only used to find a good initial size.  If
> expansion is turned off after the columns have been created, that should fix

How is this different from turning off the expand flags on the columns after the first resize operation (which is what the patch in comment #26 does)?

> the problem.  Resizing the view will not change the column width, but one could
> assume the user has set them a certain way and doesn't want them changed.

Leaving the expand flag enabled until the user explicitly resizes a column might be even better, since the columns will still expand nicely after window resizings until the user explicitly sets a size.

> I'm working on a patch, and hope to have it ready soon.  Eventually the column
> widths should probably be saved somewhere, but I'll leave that to someone more
> experienced.  This is my first patch.


I think this problem is more complicated than it looks.  I've been looking a bit at other toolkits as Nickolay suggested, but still have to do some more brainstorming and a little write up on that...
Comment 31 John Bryant 2006-12-28 16:34:38 UTC
Oops, posted in the wrong area.  My idea seems to work for Rhythmbox, so I'll post a workaround there.  Like I said, this is my first try :)
Comment 32 David Tangye 2007-01-06 01:58:36 UTC
It amazes me that after 15 months and counting, this basic UI bug is still not fixed. Even 20, yes 20, years ago, Microsoft got some very basic actions like column sizing to work properly. Here we are 20 years later and this sort of crap is still a problem too big for the latest crop of developers!! Net result: a really amateur-looking interface, where when I try to see the details of a column, all columns go loopy. This really highlights the limitations of open-source development.

Obviously the toolkit is either broken here, or more likely the design of rhythmbox is bugged in that the designed behaviour of a superclass or whatever is not understood so not being used properly. It sounds like the concept behind 'expandable column' is misunderstood. Maybe, as suggested already, it should be used less, if at all. I don't know, I am not at all familiar with any of this software nor framework, technology etc. But surely it should be a priority to get such an 'in your face' bit of crap fixed? Surely there is a developer of rhythmbox  that understands the behaviour of the toolkit that its built in better than this? No?
Comment 33 Matthias Clasen 2007-01-06 02:11:54 UTC
Please stop the ranting. It won't get the bug fixed any faster.
Comment 34 Nicholas Allen 2007-01-06 12:41:41 UTC
I can understand David Tangye's frustration - and yes it does highlight a fairly common problem with open source development. Open source developers work on problems that are interesting and fun - as often this is done in their spare time as a hobby. In the commercial world such a bug would most likely never be seen by a customer if it was known about in advance. It's not as interesting to fix a bug as to work on a new feature. It amazes me though that this has not annoyed someone to such an extent that they decide to actually do something about it. Being an open source developer myself (although I am not involved with gtk development) I am starting to reach that threshold - I was hoping someone would get there before I did and fix it as I have other projects I would rather work on and the learning curve to get into gtk will be greater for me than someone familiar with it....
Comment 35 Kristian Rietveld 2007-01-06 13:08:29 UTC
Something is surely happening here, see the patch and analysis in comment 26, and the suggestion in comment 27 to look at other toolkits.  I have been looking at other toolkits meanwhile and writing a short summary of that to see whether there is a better solution than that patch.  This piece is close to being finished now (and yes it is taking a while since there are also other (more important) bugs to fix in the meantime). 

I only have a finite amount of spare time to spend on these kind of things; I wish I had more but I haven't.  And as Matthias said: please stay on topic on this bug, diverting in discussions such as these won't get the issue resolved any faster.
Comment 36 Kristian Rietveld 2007-01-15 13:49:51 UTC
New thoughts after a discussing with Tim: only take the expand flags into account when size allocation is NOT triggered by a user column resize action (basically like what JTable does).  Sounds like this might just work, will experiment with this soonish.
Comment 37 Kristian Rietveld 2007-02-16 18:39:08 UTC
Created attachment 82693 [details] [review]
better patch

This is a much better try.  As described in the last comment it does only recalculate the expand values when the tree view itself changes width, or if the number of expand columns changes.

Another side effect when turning off the expand flag on a column: the column will start using its original requested_width again, throwing away any resize actions by the user.  (I think that this does make sense somewhere; but also, who turns off the expand flag in the middle of execution?)
Comment 38 Richard Edmands 2007-04-12 03:22:12 UTC
the better patch appears to work nicely. thanks. (tested on ubuntu feisty with rhythmbox)
Comment 39 Michael Wiktowy 2007-04-16 05:37:36 UTC
Did this patch not land on the target milestone of 2.10.8?

I still witness this chaotic behaviour in Rhythmbox in Fedora 7 test releases that have gtk2-2.10.11/gnome-2.18.0 included.
Comment 40 Alex Lancaster 2007-04-16 06:04:40 UTC
(In reply to comment #39)
> Did this patch not land on the target milestone of 2.10.8?

The patch status indicates that it has not yet even been applied to CVS, let alone a release.  :-(  

Since a reporter indicates in comment #38 that it appears to work correctly, is there any reason this can't be committed?
Comment 41 Alex Lancaster 2007-04-16 06:06:28 UTC
(In reply to comment #40)

> Since a reporter indicates in comment #38 that it appears to work correctly, is
> there any reason this can't be committed?

This will also allow wider testing and feedback.

Comment 42 Richard Edmands 2007-04-16 06:33:53 UTC
for those who might be interested. for ubuntu feisty. i've uploaded patched gtk2 packages to http://mirror.randumb.org/darkmagez/repo/dists/feisty-darkmagez/core-experimental/ with this patch applied :)
don't add the repo to your sources as it is broken. just pull the packages you need and install em.

any questions should be emailed directly to me and not here.
Comment 43 Kristian Rietveld 2007-04-16 12:00:41 UTC
No, it did not get committed yet.  I actually want to get some more feedback before committing this patch, rather than after...  That said I was actually planning to commit this on trunk only anyway, since it's not exactly a trivial "bugfix".  I will read over and commit that patch to trunk soonish then.
Comment 44 Josselin Mouette 2007-05-01 17:35:24 UTC
I have tried this patch with nautilus' list view (making the first column expandable) and it is definitely an improvement. However, sometimes (say, one out of three times), the total width of the TreeView when opening it is larger than its container, which means there must be some mistake when computing the initial width of the expandable column.
Comment 45 Josselin Mouette 2007-05-18 17:35:25 UTC
This happens when the scrollbar appears after the TreeView has been displayed. In this case, width_changed is still FALSE but the expand size needs to be updated anyway.
Comment 46 Josselin Mouette 2007-05-18 19:07:41 UTC
Created attachment 88411 [details] [review]
Kristian's patch + scrollbar fix

This one works better for me.
Comment 47 Johan (not receiving bugmail) Dahlin 2007-06-06 16:09:49 UTC
Created attachment 89486 [details]
column-resizing.py

Here is another testcase, try to change the resize the middle column and it'll behave strangely, the column resizes in the "wrong direction".
Comment 48 Josselin Mouette 2007-06-09 09:04:24 UTC
The patch from #46 has been in Debian unstable for a few weeks, and there has been no negative feedback so far.
Comment 49 Kristian Rietveld 2007-06-09 09:48:24 UTC
(In reply to comment #48)
> The patch from #46 has been in Debian unstable for a few weeks, and there has
> been no negative feedback so far.

Thanks! That's good to know.  I am close to re-viewing the patch and looking at the newly raised issues.

Comment 50 Vitaliy Ischenko 2007-06-12 15:37:48 UTC
I've found One more issue
I've got this issue with rhythmbox (0.10.1) and GTK 2.10.12-2 from debian unstable
How to reproduce:
  1) Drag left expander of last column to the left until possible
  2) Drag right expander of second column to the right

Visible results:
  1) Columns to the right became too small (less than title width)
  2) From console - (rhythmbox:24268): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -10 and height 29

I also managed to reproduce the same behaviour with my app. It was harder but, here is the recipe:
  1) Create TreeView with "N" (in my case N = 6: 5 Resizeable colums and one fixed) Columns.
  2) Set Expand property on all resizeable columns
  3) Drag right expander of first resizeable column to the right -- works great
  4) Start dragging right expanders of columns to the left (until possible) in the following order: N column, N-1 column, N-2 and so on.
  5) Repeat step 3. You will mention, that columns will became smaller
  Repeat steps 3 & 4 few times. In the end you will get errors about allocating negative widths

Why ALL columns with Expand property get extra with? Maybe only first neighbour with this property should get it?
I.e you get 3 columns width expand property A, B a C
You start resizing "A" with right expander
|  A  |  B  |  C  |
|    A    |B|  C  |
|       A     |B|C|
|        A      |B|C|
If "C" doesn't have Expand property we get something like this
|  A  |  B  |  C  |
|    A    |B|  C  |
|       A     |B|  C  |
|        A      |B|  C  |
Comment 51 Baptiste Mille-Mathias 2007-06-12 16:20:39 UTC
Hey Vitaliy,

the gtk column-resizing code has been reworked in trunk version of gtk+ so, could you try to test again, with a development version of gtk+ and rhythmbox compiled against it, in order to know if the bug stil exist?

Thanks
Comment 52 Vitaliy Ischenko 2007-06-12 16:48:11 UTC
Sounds interesting :)
If there are no ABI changes, I will try it later this week
Comment 53 Jonathan Matthew 2007-07-18 10:57:23 UTC
*** Bug 457868 has been marked as a duplicate of this bug. ***
Comment 54 Kristian Rietveld 2007-08-29 09:40:49 UTC
(working on processing the newly brought up issues and integrating in trunk for 2.12 now)
Comment 55 Kristian Rietveld 2007-08-29 10:45:29 UTC
(In reply to comment #44)
> out of three times), the total width of the TreeView when opening it is larger
> than its container, which means there must be some mistake when computing the
> initial width of the expandable column.

Do you mean that the TreeView contents don't fully fit in the window and a scrollbar should be shown but isn't?


(In reply to comment #45)
> This happens when the scrollbar appears after the TreeView has been displayed.
> In this case, width_changed is still FALSE but the expand size needs to be
> updated anyway.

Which scrollbar?  I guess you mean the horizontal one?  If it is the vertical one, then the tree view's allocation usually changes, setting width_changed to TRUE already.
Comment 56 Kristian Rietveld 2007-08-29 11:11:56 UTC
(I think I see the problem already, the scrollbar calculation seems to be broken since the last time I looked at it).
Comment 57 Matthias Clasen 2007-09-07 20:08:32 UTC
Anything in the pipe that we should hold 2.12.0 for, Kris ?
Comment 58 Josselin Mouette 2007-09-19 08:45:32 UTC
The patch has been in Debian unstable for 4 months, without negative feedback so far.
Comment 59 Kristian Rietveld 2007-09-19 09:31:58 UTC
The patch showed a bunch of (real) issues when applied to trunk again, so we decided to skip 2.12.0 for this one so close to release.  I will be updating/reworking the patch as time permits, when that is finished we will see if it is suitable to commit to a stable branch (there is a good chance there is I think).
Comment 60 Kristian Rietveld 2007-10-04 12:20:17 UTC
Created attachment 96629 [details] [review]
updated patch

Updated patch, applies against GTK+ trunk and should apply cleanly against 2.12.0 as well.

The patch from Josselin is incorporated in this patch; albeit in a different manner.  The call to gtk_tree_view_size_allocate_columns() has been moved to before the adjustments are updated and internal sub-windows are resized.  In the current size request/allocate mechanism, the new, final sizes of the columns (and thus the final full width of the tree view) are not known until in gtk_tree_view_size_allocate_columns().  By moving this call, tree_view->priv->width will reflect the new, final width of the tree view even before the adjustments and windows are updated.  I don't think this change should be an big issue; though we should proceed with care.

I also found issues with resizing if expand=TRUE for the last column.  This has been fixed by changing the clause that decides whether a column should get the "extra_for_last" space from "else if" to "if".  Which makes complete sense, since this should be decided on independently of column->expand.


An extra round of testing would of course be appreciated.  I plan to commit this once 2.13 has been opened for development.  Because of the subtle change in size-allocate, I am not 100% sure yet I consider this 100% safe for 2-12 (though I really think we should commit it there, since as far as I can see this is improving the behavior dramatically).
Comment 61 John Bryant 2007-10-18 02:47:55 UTC
*** Bug 393035 has been marked as a duplicate of this bug. ***
Comment 62 Josselin Mouette 2007-11-01 11:00:39 UTC
Unfortunately the latest patch has the same issue as the previous one with regard to the initial size when the vertical scrollbar appears after the treeview.
Comment 63 Josselin Mouette 2007-11-01 12:49:50 UTC
Created attachment 98306 [details] [review]
Patch for GTK+ 2.12.1 with content resizing fix

OK, here is a version that seems to work.

The initial test for width_changed only checks that the size of the allocation hasn't changed. However, it doesn't check for changes in the size of the contents, which is what I have changed.

This way, it works with our patched nautilus.
Comment 64 Johan (not receiving bugmail) Dahlin 2007-11-01 12:59:58 UTC
(In reply to comment #63)
> Created an attachment (id=98306) [edit]
> Patch for GTK+ 2.12.1 with content resizing fix
> 
> OK, here is a version that seems to work.
> 
> The initial test for width_changed only checks that the size of the allocation
> hasn't changed. However, it doesn't check for changes in the size of the
> contents, which is what I have changed.
> 
> This way, it works with our patched nautilus.
> 

Did you try my test case mentioned in comment 47?
It would be nice if you could do that.
If you don't have time right now I'll do it eventually, but I'm busy at the moment.
Comment 65 Josselin Mouette 2007-11-01 13:16:37 UTC
The fix is definitely not perfect, and your testcase still shows strange behavior when resizing.

Your test case shows no difference between the patch of comment 37 and that of comment 60, if that is the question.
Comment 66 Josselin Mouette 2007-11-15 20:41:42 UTC
Created attachment 99167 [details] [review]
Patch for GTK+ 2.12 and more fixes

The change in the gtk_tree_view_size_allocate_columns API affects badly the other call in gtk_tree_view_move_column_after, causing crashes. This change makes the function return something instead of using address-passing.
Comment 67 gerben 2008-05-28 13:58:42 UTC
This bug is still alive and kicking in 2008.

In Gnome's default file browser Nautilus, for example.
This is not really nice for new Linux'ers, people trying out Ubuntu for example and noticing these kind of "primitive" errors, will probably not have much trust in that OS.

For a normal user, used to GUI's, this seems very basic and simple, and that this has not been fixed while it is known since at least 2005 doesn't look promising...
Comment 68 Kristian Rietveld 2008-06-27 21:26:06 UTC
Okay, now University is on summer break I have some time to look into this again.  I wrote a new test case especially for this issue (I used to use a modified testtreeview.c -- quite a nightmare) that I want to commit to trunk soon.  With my latest patch applied, I don't see any issues with the behavior.

The only relevant change I see in your patch (I fixed the _size_allocate_columns 'problem' by fixing the other call to this function) is:

+  if (allocation->width != old_width || tree_view->priv->width != tree_view->priv->prev_width)
+    width_changed = TRUE;

and this unfortunately appears to break the entire new column resizing behavior in a bunch of cases.  I think I managed to get a proper easily reproducible test for this in my new test case and will debug from there and try to find a solution.

Comment 69 Kristian Rietveld 2008-07-10 16:19:56 UTC
Created attachment 114323 [details] [review]
updated patch

Updated patch including the interactive test program.  This patch does also recalculate the expand values after a row has been validated (and thus probably changed size).  The issue I was seeing in the test program with the "long row" disappears with this.

Josselin, could you check if this does solve the issues you are seeing in Nautilus?
Comment 70 Josselin Mouette 2008-07-10 18:00:45 UTC
Yeah, that’s much better. It doesn’t have the scrollbar issue and it also fixes some issues with my patch that lead to the column not resizing in some cases.

Thanks !
Comment 71 Kristian Rietveld 2008-07-11 14:24:39 UTC
Thanks a lot for all the testing work over the last months :)  Committed this (finally!) to trunk in r20818.

Marking as FIXED.