GNOME Bugzilla – Bug 350618
start rubber banding on "white space"
Last modified: 2018-02-10 03:38:30 UTC
it would be nice if you could start the rubber band selection on space that is neither a directory or a file in the treeview but free space below the content of the currently shown folder. Other information:
YES, it is confirmed by http://brainstorm.ubuntu.com/idea/7009/ and http://mail.gnome.org/archives/gtk-devel-list/2008-April/msg00036.html someone pls fix this
*** Bug 602447 has been marked as a duplicate of this bug. ***
As discussed in the mailing list thread, this might be fixed easiest by first pushing some of the refactorings I have done in the past to git master. I will try to dive up these patches as soon as I get the time in the near future. (I don't remember off head where I've stored these patches). Then they need to be cleaned up, tested and committed. One of the problems I had with these patches at the time was that a unit test suite for tree view didn't exist. As things look like now, we won't have unit testing for layouting code anytime soon, so we can better put the patches in the development tree, get them tested by real people and hope for the best.
This bug is blocking bug 94618, it should be set so.
Created attachment 148418 [details] Area that should be treated as "blank area" My suggestion is that the area painted in red should be treated as "blank area" by treeview.
(In reply to comment #5) > Created an attachment (id=148418) [details] > Area that should be treated as "blank area" > > My suggestion is that the area painted in red should be treated as "blank area" > by treeview. I'd say that would be a good default behavior. But based on my experiences with Windows, Mac OS X, and Gnome, I think it should be possible for entire columns to be marked by the programmer as "blank area" as well. So in attachment 148418 [details], for example, Nautilus could potentially also designate the file size, type and date columns (Tamanho, Tipo, Data de modificação) as "blank area". It's worth noting that this is useful not only for right click and rubber-banding selections, but also for drop targets (else, in Nautilus, it's impossible to drag-drop a file into a list view full of folders and/or executable files).
(In reply to comment #5) > Created an attachment (id=148418) [details] > Area that should be treated as "blank area" > > My suggestion is that the area painted in red should be treated as "blank area" > by treeview. i think the red areas in the "name" column are good to be used as whitespace but i'd even go further and color all the other columns completely red as they are only information for that row but not directly represent the item in that row.
(In reply to comment #5) > Created an attachment (id=148418) [details] > Area that should be treated as "blank area" > > My suggestion is that the area painted in red should be treated as "blank area" > by treeview. This seems reasonable to start with. I would also include the blank area where the expander would be, in case there is no expander for that row. (In reply to comment #7) > (In reply to comment #5) > > Created an attachment (id=148418) [details] [details] > > Area that should be treated as "blank area" > > > > My suggestion is that the area painted in red should be treated as "blank area" > > by treeview. > > i think the red areas in the "name" column are good to be used as whitespace > but i'd even go further and color all the other columns completely red as they > are only information for that row but not directly represent the item in that > row. This is what is being discussed in the mailing list thread referred to in comment 1 as the idea of a "selection column". Like Windows explorer, only a given (in this case the name column) would be drawn as selected. The main problem is that this is very different from the behavioral patterns the tree view was designed for.
> This is what is being discussed in the mailing list thread referred to in > comment 1 as the idea of a "selection column". Like Windows explorer, only a > given (in this case the name column) would be drawn as selected. The main > problem is that this is very different from the behavioral patterns the tree > view was designed for. Windows 7 Explorer have a different behavior from previous versions: like Nautilus, all the line is selected instead of only the first column. To access background, right click must occur in a blank area of a non selected item, exactly as showed in attachment (id=148418). Maybe it can be useful analyze how Windows 7 is managing this problem, so I'll attach images showing step by step how it works there.
Created attachment 148485 [details] Windows 7 Explorer - Folder clicked in left panel Until now only a folder was select on left panel
Created attachment 148486 [details] Mouse pointer is moved over file list (no click yet) When mouse pointer is over a file, all the line color is changed.
Created attachment 148487 [details] Item is clicked in file list - all line is selected There is a different color that represents when the item is selected.
Created attachment 148488 [details] The selected item is right clicked User right clicked any point in selected item. There is no "blank area" when item is selected. Context menu for that item is showed.
Created attachment 148489 [details] Blank area of a non selected item is clicked - background is reached When a blank area of a non selected item is right clicked, context menu for the current folder is showed.
Could somebody set this bug as blocking bug 94618?. Kristian, did you push some of the refactorings you have done in the past?
(In reply to comment #15) > Kristian, did you push some of the refactorings you have done in the past? Not yet, but I have at least dug them up.
In response to comment 9 - 15; for now let's go with adding support for detecting the blank area as pointed out in comment 9 and save the more complicated "selection column" stuff (as seen in earlier versions of Windows) for the future if ever. We'll add a public function for checking if a given coordinate is in a blank area as well as getting the rubber banding code to use it.
> We'll add a public function for checking if a given > coordinate is in a blank area as well as getting the rubber banding code to use > it. I think that it is the better solution. Good luck, we are looking forward for this.
FYI I have started to sort out my old refactoring patches now.
(In reply to comment #19) > FYI I have started to sort out my old refactoring patches now. The GNOME community is grateful for this effort
Happy new year! Something new about this? Kristian, how are going your old refactoring patches?
The refactorings will not be pushed into the master branch before the release of GTK+ 2.20, because GTK+ 2.20 is set to be released this month and we do not want to risk the introduction of regressions. After the new development branch for the version following GTK+ 2.20 has been opened, I will look into committing this stuff upstream.
Hi, Kristian, how are your old refactoring patches?
There is some different refactoring going on now based on new ideas. In here I have brought up this issue to see if we can also fix this bug while we are at it: http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00256.html
I can't wait to see this bug fixed. I wish you good luck!
Kristian, Is there something I can do to help gnome team in this work? Where I can find these new ideas, so that I can contribute somehow? I feel very upset about this error because I usually manage folders with large amounts of files and the inability to access the context menu of the folder in Nautilus is something that complicates my tasks. Since the Gnome team can not or has no interest in correcting the error, could allow other people to try. At this moment the best way would be to share these new ideas. Why status is "unconfirmed"?
Created attachment 176566 [details] [review] first attempt at a gtk_tree_view_is_blank_at_pos() Now that we have a refactored tree view (treeview-refactor branch required until it is merged), it is trivial to write a function along the lines of gtk_tree_view_is_blank_at_pos(). From quick testing in testtreeview it seems to work pretty well. The API is probably fine like this, so we should be able to get this in 3.0. Using the function we can actually change the rubber banding start and unselection behavior this bug is actually about.
(In reply to comment #26) > Is there something I can do to help gnome team in this work? > Where I can find these new ideas, so that I can contribute somehow? > I feel very upset about this error because I usually manage folders with large > amounts of files and the inability to access the context menu of the folder in > Nautilus is something that complicates my tasks. > Since the Gnome team can not or has no interest in correcting the error, could > allow other people to try. Remember that it is not about that the "team" does not have interest -- it is merely that there is a massive amount of bugs to be fixed and only a handful of volunteers. Others are always welcome to submit code & patches of course. > At this moment the best way would be to share these new ideas. If you mean the refactoring with these "new ideas", they were pointed out in the link to the e-mail I posted in comment 24. > Why status is "unconfirmed"? GTK+ bugs are typically always left in the unconfirmed state, we don't really use this flag.
Comment on attachment 176566 [details] [review] first attempt at a gtk_tree_view_is_blank_at_pos() I just pushed a gtk_tree_view_is_blank_at_pos() function in the GTK+ 3.0 branch. This function will allow applications (e.g. nautilus and others) to check if the tree view is "blank" at a given (x, y) coordinates. This bug will remain open to reconsider GtkTreeView's default user interactions in the future.
Ok, Kristian, good news. Thank you very much! Now I'll return to Nautilus Bug (Bug 94618).
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.