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 80127 - Rubberbanding for GtkTreeView
Rubberbanding for GtkTreeView
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
2.0.x
Other other
: Normal enhancement
: Medium feature
Assigned To: gtktreeview-bugs
gtktreeview-bugs
: 40141 81842 85759 96208 102206 122556 346068 349012 349369 358058 358902 406162 (view as bug list)
Depends on:
Blocks: 40141
 
 
Reported: 2002-04-28 15:25 UTC by Dave Bordoley [Not Reading Bug Mail]
Modified: 2007-02-09 18:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
first try at a patch (16.49 KB, patch)
2006-02-06 23:59 UTC, Kristian Rietveld
none Details | Review
updated patch (14 feb 06) (17.50 KB, patch)
2006-02-15 11:09 UTC, Kristian Rietveld
none Details | Review
patch as committed (23.30 KB, patch)
2006-06-02 20:38 UTC, Kristian Rietveld
committed Details | Review

Description Dave Bordoley [Not Reading Bug Mail] 2002-04-28 15:25:43 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
Comment 1 Kristian Rietveld 2002-05-02 19:40:27 UTC
Reassigning bugs to new component owner. Sorry for the flood.
Comment 2 Kristian Rietveld 2002-05-05 18:19:21 UTC
We're not sure about rubberbanding at the moment. Though we want to
add a "drag and select" thing.
Comment 3 Owen Taylor 2002-05-15 14:00:55 UTC
*** Bug 81842 has been marked as a duplicate of this bug. ***
Comment 4 Pmarj 2002-05-17 14:55:09 UTC
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
Comment 5 Dave Bordoley [Not Reading Bug Mail] 2002-06-07 19:19:46 UTC
*** Bug 40141 has been marked as a duplicate of this bug. ***
Comment 6 Dave Bordoley [Not Reading Bug Mail] 2002-06-19 15:12:06 UTC
*** Bug 85759 has been marked as a duplicate of this bug. ***
Comment 7 Dave Bordoley [Not Reading Bug Mail] 2002-10-18 22:00:48 UTC
*** Bug 96208 has been marked as a duplicate of this bug. ***
Comment 8 Kristian Rietveld 2002-11-18 20:15:14 UTC
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).
Comment 9 Kristian Rietveld 2003-01-14 15:29:19 UTC
*** Bug 102206 has been marked as a duplicate of this bug. ***
Comment 10 renaud_chaillat 2003-08-26 12:00:59 UTC
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.
Comment 11 Kristian Rietveld 2003-09-17 17:19:48 UTC
*** Bug 122556 has been marked as a duplicate of this bug. ***
Comment 12 John McCutchan 2003-09-17 17:38:58 UTC
What is the status of this bug?
Comment 13 Kristian Rietveld 2003-11-16 15:16:15 UTC
Will prolly become a 2.6 item.
Comment 14 Timo Aaltonen 2003-12-22 18:07:24 UTC
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
Comment 15 John McCutchan 2004-03-15 23:35:38 UTC
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?
Comment 16 Christian Neumair 2004-05-29 09:25:54 UTC
On 1): Is getting the color value of the clicked pixel and comparing it with the
widget bg color a good idea?

regs,
 Chris
Comment 17 danny.milo 2004-06-15 19:35:58 UTC
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
Comment 18 Federico Mena Quintero 2005-03-09 20:01:02 UTC
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().
Comment 19 Jerome Haltom 2005-03-10 01:24:17 UTC
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...
Comment 20 Timo Aaltonen 2005-03-31 16:47:16 UTC
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? ;)
Comment 21 Kristian Rietveld 2006-01-31 13:43:35 UTC
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).
Comment 22 Matthias Clasen 2006-02-03 15:41:08 UTC
kris, any patch yet ?
Comment 23 romek 2006-02-05 17:01:12 UTC
Can't wait to test it.
Comment 24 Kristian Rietveld 2006-02-06 23:59:26 UTC
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.
Comment 25 Kristian Rietveld 2006-02-15 11:09:52 UTC
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).
Comment 26 Matthias Clasen 2006-02-16 17:19:59 UTC
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.
Comment 27 Kristian Rietveld 2006-05-28 01:26:27 UTC
I'll commit this during the coming week.
Comment 28 Kristian Rietveld 2006-06-02 20:38:21 UTC
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.
Comment 29 Kristian Rietveld 2006-06-02 20:40:04 UTC
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.
Comment 30 Charles Kerr 2006-06-28 05:20:34 UTC
*** Bug 346068 has been marked as a duplicate of this bug. ***
Comment 31 Charles Kerr 2006-07-28 06:10:07 UTC
*** Bug 349012 has been marked as a duplicate of this bug. ***
Comment 32 Jeff Berman 2006-07-31 01:04:46 UTC
*** Bug 349369 has been marked as a duplicate of this bug. ***
Comment 33 Christophe Lambin 2006-09-28 17:57:22 UTC
*** Bug 358058 has been marked as a duplicate of this bug. ***
Comment 34 Jerry Segers, Jr. 2006-10-05 12:52:26 UTC
*** Bug 358902 has been marked as a duplicate of this bug. ***
Comment 35 Christophe Lambin 2007-02-09 18:57:36 UTC
*** Bug 406162 has been marked as a duplicate of this bug. ***