GNOME Bugzilla – Bug 80127
Rubberbanding for GtkTreeView
Last modified: 2007-02-09 18:57:36 UTC
It would be nice if the tree view supported making multiple selctions with the mouse similar to rubberbanding icons in nautilus. There are a number of apps where this would be helpful. like the file-selector, procman and of course nautilus
Reassigning bugs to new component owner. Sorry for the flood.
We're not sure about rubberbanding at the moment. Though we want to add a "drag and select" thing.
*** Bug 81842 has been marked as a duplicate of this bug. ***
I think this should change you mind ;) see these screenshots i've made in gimp: www.laapp.miesto.sk/viewaslist.png www.laapp.miesto.sk/fileselect.png www.laapp.miesto.sk/fileselectdetail.png #1 the fileselector: currently has separate windows for folders and files(which i think is useless), and only supports selecting one file at a time, rubberband selector would allow to select multiple files at once, holding down ctrl would allow to add another multiple files(by dragging a square over those files), which is much faster, more intuitive, easier and supported by other non-unix guis(best example is windows) so i think this function is vital in order to attract windows-users #2 nautilus "view-as-list"( i know this seems to be a nautilus feature request but this i realized that this issue is both gtk and nautilus/eel related) i've noticed that if you view files & folders, you cannot select them with the rubberband selector, + the view list is actually a detailed list, where a simple view-as-list would look like the "viewaslist.png" screenshot, sorting files upsidedown in several columns, folders first. + currently the difference between nautilus' "view-as-list" and file-selector is that file-selector has separate views for folders and files. My proposal: having *unified* "view-as-list" and "view-as-detailed-list" views, this concerns nautilus, fileselector, file-roller etc.(the only difference for fileselector is that it would have a *fixed* window size, see above mentioned "viewaslist.png" screenshot, and wouldn't have the icon view option) PROS: *USABILITY* 1) people migrating from windows, 2) same rule all over the place => easy to learn Marek
*** Bug 40141 has been marked as a duplicate of this bug. ***
*** Bug 85759 has been marked as a duplicate of this bug. ***
*** Bug 96208 has been marked as a duplicate of this bug. ***
Hrm. I think "rubberbanding selection" as seen in Nautilus is not suitable for GtkTreeView. I see more in a drag-selection mechanism, like GtkC{List,Tree} has. If people agree with me here, I would like to volunteer to implement this in treeview. It looks like a fun task (I know I will regret saying this later on).
*** Bug 102206 has been marked as a duplicate of this bug. ***
I support this idea of "rubberbanding" selection for mouse-only operations. A drag-selection as seen in GtkCTree would not be sufficient, especially in situations when you need drag'n'drop at the same time. Multiple rows dnd and mouse-only multiple selection go hand in hand IMHO.
*** Bug 122556 has been marked as a duplicate of this bug. ***
What is the status of this bug?
Will prolly become a 2.6 item.
I believe that rubberbanding _is_ a goog idea.. here are some examples how it is done in winxp: http://www.hut.fi/~tjaalton/rb-sel/sel1.png -it is possible to start the selection inside the name-column, and objects are selected as the box overlaps the name "by a few letters" -an object is selected (for dnd etc) by clicking on the name, and not by clicking the row, as it is currently
Just a few questions, 1) Is it possible to know if the user clicked on white space of a tree view? 2) What is the best way to draw the rubber-banded area?
On 1): Is getting the color value of the clicked pixel and comparing it with the widget bg color a good idea? regs, Chris
What about just adding a "selection area" column to the front. Dragging around in the selection area selects. Easy. like so: [ ][Name ][Size].... stuff 10 stuff2 40 ^-- dragging around in that area selects corresponding lines. Just an idea
Things to look at: 1. If one presses a button inside a cell renderer's area, can the cell renderer notify upwards that it didn't handle the event? This would let the cell renderer determine its "empty area" on its own. 2. By the same, a drag-and-drop operation should only start if you start dragging from a cell's non-empty area. 3. Drawing the rubberband area is easy; just use a stippled GC and gdk_draw_rectangle().
What does rubberbanding offer that drag and select doesn't? If I hold down the mouse on item 2, and drag to item 5, as I pass 4 and 5 they are selected... what does that not do that this rubberband idea doesn't? It is certainly more structured and easier to implement. Once the selection is made, you shoudl still be able to drag and drop the selection as a whole...
jerry: doesn't work in nautilus =) And one another reason why list-mode sucks in nautilus is that if you'd like to make a new folder you need to scroll to the bottom of the window to find whitespace where you can right-click (and it's impossible to do that if the folder has a lot of stuff in it -> no whitespace) I have no idea how difficult it is to make this happen, but I'm still hoping this will be implemented, maybe even for 2.8? ;)
Ok, I made a start with an implementation. The patch which I am about to attach is just a start and also implements row-hinting for multiple selections (looks pretty nice). Rubberbanding also works nicely, autoscroll is working too. However there are a few more things which I have to figure out: 1) Which color to use for the rubberband rectangle. Using the default selection color is not going to work here, it is almost invisible. 2) Make sure we don't clash with DnD implementations. Our behaviour right now is the following (easy but works): Drags initiated from a selected node are DnD, drags initiated from an unselected node is a rubberband operation. (Looks like this breaks nautilus...). Anyway, I would say let's get the look nailed first. And finetune the behaviour after that. Only cell renderers which implement the activate method get events and notify back whether the handled/consumed the event. The text renderer does not implement activate event, since you cannot really activate it anyway. So this will not help us for determined empty cell areas. (Comparing cell_area and background_area might help here though).
kris, any patch yet ?
Can't wait to test it.
Created attachment 58835 [details] [review] first try at a patch Here's a first try at a patch. Needs a little work still. The row-hinting for selected rows has already been committed to HEAD.
Created attachment 59402 [details] [review] updated patch (14 feb 06) Addressed some comments from Matthias. Rectangle color and DnD interaction are still outstanding issues (see comment 21).
I think the current color is ok, and the DND interaction is good enough for merging it in this form. We should probably check how other toolkits handle DND interaction. One thing I noticed is that there is a little bit of flickering when scrolling while rubberband-selecting. It looks like the black outline gets copied and is visible for a short amount of time before its overdrawn.
I'll commit this during the coming week.
Created attachment 66672 [details] [review] patch as committed Updated patch, use rubber banding instead of rubberbanding since the former is the correct spelling. Add property to enable/disable rubber banding, default is disabled. At last, use fg_gc[NORMAL] as rubber banding color.
The flicker issue might be _bin_expose not drawing fast enough (need to address this with all other cases of flicker I guess). Also the CTRL+rubber band behaviour is a little weird if you start at a non-selected node. Since starting at a selected node doesn't work. Guess we can special case CTRL now, because the user will have to enable this himself.
*** Bug 346068 has been marked as a duplicate of this bug. ***
*** Bug 349012 has been marked as a duplicate of this bug. ***
*** Bug 349369 has been marked as a duplicate of this bug. ***
*** Bug 358058 has been marked as a duplicate of this bug. ***
*** Bug 358902 has been marked as a duplicate of this bug. ***
*** Bug 406162 has been marked as a duplicate of this bug. ***