GNOME Bugzilla – Bug 316087
Resizing columns is chaotic
Last modified: 2011-02-04 16:11:04 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.
Most likely an application problem. Although they could be running into missing treeview features.
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.
Yes, the behaviour is not ideal.
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.
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.
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?
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).
Could someone at least confirm the bug?
*** Bug 321942 has been marked as a duplicate of this bug. ***
Has there been any progress on this?
Not yet, fixing the more critical bugs first.
Is this the same as #318934? It looks like it, and there's a patch there.
*** Bug 318934 has been marked as a duplicate of this bug. ***
Created attachment 60894 [details] test file test.c
Created attachment 60895 [details] [review] Suggested patch This patch at least solves column size jump problem, making the behavior more natural
*** Bug 336082 has been marked as a duplicate of this bug. ***
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).
*** Bug 341539 has been marked as a duplicate of this bug. ***
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?
*** Bug 342407 has been marked as a duplicate of this bug. ***
*** Bug 344567 has been marked as a duplicate of this bug. ***
Kris, any hope to get to this for 2.10.1 ?
*** Bug 350151 has been marked as a duplicate of this bug. ***
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
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.
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).
> 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?
(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.
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.
(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...
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 :)
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?
Please stop the ranting. It won't get the bug fixed any faster.
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....
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.
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.
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?)
the better patch appears to work nicely. thanks. (tested on ubuntu feisty with rhythmbox)
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.
(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?
(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.
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.
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.
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.
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.
Created attachment 88411 [details] [review] Kristian's patch + scrollbar fix This one works better for me.
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".
The patch from #46 has been in Debian unstable for a few weeks, and there has been no negative feedback so far.
(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.
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 |
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
Sounds interesting :) If there are no ABI changes, I will try it later this week
*** Bug 457868 has been marked as a duplicate of this bug. ***
(working on processing the newly brought up issues and integrating in trunk for 2.12 now)
(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.
(I think I see the problem already, the scrollbar calculation seems to be broken since the last time I looked at it).
Anything in the pipe that we should hold 2.12.0 for, Kris ?
The patch has been in Debian unstable for 4 months, without negative feedback so far.
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).
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).
*** Bug 393035 has been marked as a duplicate of this bug. ***
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.
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.
(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.
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.
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.
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...
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.
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?
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 !
Thanks a lot for all the testing work over the last months :) Committed this (finally!) to trunk in r20818. Marking as FIXED.